Ayude a mejorar esta página
¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.
Implementación de un clúster de Amazon EKS en AWS Outposts
En este tema, se proporciona información general sobre lo que debe tener en cuenta al ejecutar un clúster local en un Outpost. El tema también contiene instrucciones sobre cómo implementar un clúster local en un Outpost.
Consideraciones
importante
-
Estas consideraciones no se replican en la documentación relacionada de Amazon EKS. Si otros temas de la documentación de Amazon EKS entran en conflicto con las consideraciones que se presentan aquí, siga las consideraciones que se indican a continuación.
-
Estas consideraciones están sujetas a modificaciones y pueden cambiar con frecuencia. Por lo tanto, le recomendamos que revise este tema con regularidad.
-
Muchas de las consideraciones son diferentes a las consideraciones para crear un clúster en la Nube de AWS.
-
Los clústeres locales solo admiten bastidores de Outpost. Un único clúster local puede ejecutarse en varios bastidores de Outpost físicos que comprenden un único Outpost lógico. Un único clúster local no puede ejecutarse en varios Outposts lógicos. Cada Outpost lógico tiene un único ARN de Outpost.
-
Los clústeres locales ejecutan y administran el plano de control de Kubernetes en su cuenta en Outpost. No se pueden ejecutar cargas de trabajo en instancias del plano de control de Kubernetes ni modificar los componentes del plano de control de Kubernetes. Estos nodos están administrados por el servicio de Amazon EKS. Los cambios en el plano de control de Kubernetes no persisten a través de las acciones de administración automáticas de Amazon EKS, como la aplicación de parches.
-
Los clústeres locales admiten complementos autoadministrados y grupos de nodos autoadministrados de Amazon Linux. Los complementos Amazon VPC CNI plugin for Kubernetes, kube-proxy y CoreDNS se instalan automáticamente en los clústeres locales.
-
Los clústeres locales requieren el uso de Amazon EBS en Outposts. Su Outpost debe tener Amazon EBS disponible para el almacenamiento del plano de control de Kubernetes.
-
Los clústeres locales usan Amazon EBS en Outposts. Su Outpost debe tener Amazon EBS disponible para el almacenamiento del plano de control de Kubernetes. Los Outposts admiten únicamente volúmenes
gp2
de Amazon EBS. -
Los
PersistentVolumes
de Kubernetes respaldados por Amazon EBS se admiten mediante el controlador de CSI de Amazon EBS.
Requisitos previos
-
Familiaridad con las opciones de implementación de Outposts, las Selección de los tipos de instancias y los grupos de ubicación para los clústeres de Amazon EKS en AWS Outposts en función de consideraciones de capacidad y los Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts.
-
Un Outpost existente. Para obtener más información, consulte ¿Qué es AWS Outposts?
-
La herramienta de la línea de comandos de
kubectl
está instalada en la computadora o AWS CloudShell. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Por ejemplo, si la versión del clúster es1.29
, puede usar la versión1.28
,1.29
o1.30
dekubectl
con él. Para instalar o actualizarkubectl
, consulte Configuración de kubectl y eksctl. -
La versión
2.12.3
o posterior, o bien, la versión1.27.160
o posterior de la AWS Command Line Interface (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice
. Los administradores de paquetes tales comoaws --version | cut -d / -f2 | cut -d ' ' -f1
yum
,apt-get
o Homebrew para macOS suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte Instalar, actualizar y desinstalar la AWS CLI y Configuración rápida con aws configure en la Guía del usuario de AWS Command Line Interface. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte Instalar la AWS CLI en su directorio de inicio en la Guía del usuario de AWS CloudShell. -
Una entidad principal de IAM (usuario o rol) con permisos para
create
ydescribe
un clúster de Amazon EKS. Para obtener más información, consulte Crea un clúster local de Kubernetes en un Outpost y Enumeración o descripción de todos los clústeres.
Cuando se crea un clúster local de Amazon EKS, la entidad principal de IAM que crea el clúster se agrega de manera permanente. La entidad principal de IAM se agrega específicamente a la tabla de autorizaciones RBAC de Kubernetes como administrador. Esta entidad tiene permisos system:masters
. La identidad de esta entidad no está visible en la configuración del clúster. Por lo tanto, es importante anotar la entidad que creó el clúster y asegurarse de no eliminarlo nunca. Al principio, solo la entidad principal que creó el servidor puede realizar llamadas al servidor de la API de Kubernetes con kubectl
. Si usa la consola para crear el clúster, debe asegurarse de que las mismas credenciales de IAM se encuentren en la cadena de credenciales del SDK de AWS al ejecutar comandos de kubectl
en el clúster. Una vez que se crea el clúster, puede conceder acceso a su clúster a otras entidades principales de IAM.
Para crear un clúster local de Amazon EKS
Puede crear un clúster local con eksctl
, la AWS Management Console, la AWS CLI, la API de Amazon EKS, los SDK de AWS
-
Cree un clúster local.
-
Una vez creado el clúster, puede ver las instancias del plano de control de Amazon EC2 que se crearon.
aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep
my-cluster-
control-planeUn ejemplo de salida sería el siguiente.
"Name": "
my-cluster
-control-plane-id1
" "Name": "my-cluster
-control-plane-id2
" "Name": "my-cluster
-control-plane-id3
"Cada instancia tiene un taint
node-role.eks-local.amazonaws.com/control-plane
aplicado, de modo que nunca se programen cargas de trabajo en las instancias del plano de control. Para obtener más información sobre las taints, consulte Taints y toleracionesen la documentación de Kubernetes. Amazon EKS supervisa continuamente el estado de los clústeres locales. Realizamos acciones de administración automáticas, como la aplicación de parches de seguridad y la reparación de instancias en mal estado. Cuando los clústeres locales se desconectan de la nube, realizamos acciones para garantizar que el clúster vuelva a un buen estado al volver a conectarse. -
Si ha creado el clúster mediante
eksctl
, puede omitir este paso.eksctl
completa este paso. Habilitekubectl
para comunicarse con el clúster agregando un nuevo contexto al archivokubectl
config
. Para obtener instrucciones acerca de cómo crear y actualizar el archivo, consulte Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig.aws eks update-kubeconfig --region
region-code
--namemy-cluster
Un ejemplo de salida sería el siguiente.
Added new context arn:aws:eks:
region-code
:111122223333
:cluster/my-cluster
to/home/username/
.kube/config -
Para conectarse al servidor de la API de Kubernetes de su clúster local, debe tener acceso a la puerta de enlace local de la subred o conectarse desde la VPC. Para obtener más información acerca de la conexión de un bastidor de Outpost a su red en las instalaciones, consulte Cómo funcionan las puertas de enlace locales para bastidores en la Guía del usuario de AWS Outposts. Si usa el enrutamiento directo de VPC y la subred de Outpost tiene una ruta a la puerta de enlace local, las direcciones IP privadas de las instancias del plano de control de Kubernetes se transmiten automáticamente a través de la red local. El punto de conexión del servidor de la API de Kubernetes del clúster local está alojado en Amazon Route 53 (Route 53). Los servidores de DNS públicos pueden resolver el punto de conexión del servicio de API en las direcciones IP privadas de los servidores de la API de Kubernetes.
Las instancias del plano de control de Kubernetes de los clústeres locales se configuran con interfaces de red elásticas estáticas con direcciones IP privadas fijas que no cambian a lo largo del ciclo de vida del clúster. Es posible que las máquinas que interactúan con el servidor de API de Kubernetes no tengan conectividad con Route 53 durante desconexiones de red. Si este es el caso, recomendamos configurar
/etc/hosts
con las direcciones IP privadas estáticas para continuar con las operaciones. También recomendamos configurar servidores de DNS locales y conectarlos a su Outpost. Para obtener más información, consulte la Documentación de AWS Outposts. Ejecute el siguiente comando para confirmar que se ha establecido la comunicación con el clúster.kubectl get svc
Un ejemplo de salida sería el siguiente.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 28h
-
(Opcional) Pruebe la autenticación en su clúster local cuando se encuentra desconectado de la Nube de AWS. Para obtener instrucciones, consulte Preparación de los clústeres locales de Amazon EKS en AWS Outposts para las desconexiones de la red.
Recursos internos
Amazon EKS crea los siguientes recursos en su clúster. Los recursos son para uso interno de Amazon EKS. Para que el clúster funcione correctamente, no edite ni modifique estos recursos.
-
Los siguientes Pods de reflejo
: -
aws-iam-authenticator-
node-hostname
-
eks-certificates-controller-
node-hostname
-
etcd-
node-hostname
-
kube-apiserver-
node-hostname
-
kube-controller-manager-
node-hostname
-
kube-scheduler-
node-hostname
-
-
Los siguientes complementos autoadministrados:
-
kube-system/coredns
-
kube-system/
kube-proxy
(no se crean hasta que agregue su primer nodo) -
kube-system/aws-node
(no se crea hasta que agregue su primer nodo). Los clústeres locales usan el complemento Amazon VPC CNI plugin for Kubernetes para redes de clústeres. No cambie la configuración de las instancias del plano de control (pods denominadosaws-node-controlplane-*
). Hay variables de configuración que puede usar para cambiar el valor predeterminado para cuando el complemento crea interfaces de red nuevas. Para obtener más información, consulte la documentaciónen GitHub.
-
-
Los siguientes servicios:
-
default/kubernetes
-
kube-system/kube-dns
-
-
Una
PodSecurityPolicy
denominadaeks.system
-
Una
ClusterRole
denominadaeks:system:podsecuritypolicy
-
Una
ClusterRoleBinding
denominadaeks:system
-
Una PodSecurityPolicy predeterminada
-
Además del grupo de seguridad del clúster, Amazon EKS crea un grupo de seguridad en su Cuenta de AWS llamado
eks-local-internal-do-not-use-or-edit-
. Este grupo de seguridad permite que el tráfico fluya libremente entre los componentes de Kubernetes que se ejecutan en las instancias del plano de control.cluster-name
-uniqueid
Siguientes pasos recomendados:
-
Conceda acceso a las entidades de IAM al clúster. Si desea que las entidades vean los recursos de Kubernetes en la consola de Amazon EKS, conceda los Permisos necesarios a las entidades.
-
Familiarícese con lo que sucede durante las desconexiones de red.
-
Considere la posibilidad de configurar un plan de copia de seguridad para su
etcd
. Amazon EKS no admite la copia de seguridad ni la restauración automatizadas deetcd
para clústeres locales. Para obtener más información, consulte Copia de seguridad de un clústeretcd
en la documentación de Kubernetes. Las dos opciones principales son usar etcdctl
para automatizar la toma de instantáneas o usar la copia de seguridad del volumen de almacenamiento de Amazon EBS.