¿Por qué no puedo ejecutar comandos kubectl en Amazon EKS?
No puedo ejecutar correctamente los comandos kubectl, como kubectl exec, kubectl logs, kubectl attach o kubectl port-forward, en Amazon Elastic Kubernetes Service (Amazon EKS).
Resolución
Normalmente, los comandos kubectl fallan en el clúster de Amazon EKS porque el servidor de la API no se comunica con el kubelet que se ejecuta en los nodos de trabajo. Los comandos más comunes de kubectl incluyen kubectl exec, kubectl logs, kubectl attach o kubectl port-forward.
Para solucionar este problema, verifique lo siguiente:
- Los pods se ejecutan en el rango secundario de enrutamiento entre dominios sin clases (CIDR).
- Los grupos de seguridad que se utilizan para el plano de control y el nodo utilizan las prácticas recomendadas para las reglas de entrada y salida.
- El ConfigMap aws-auth tiene el rol correcto de AWS Identity and Access Management (IAM) con el nombre de usuario de Kubernetes asociado al nodo.
- Se cumple el requisito de enviar un nuevo certificado.
Los pods se ejecutan en el rango secundario de enrutamiento entre dominios sin clases (CIDR)
Inmediatamente después de crear un clúster, Amazon EKS no se puede comunicar con nodos lanzados en subredes de bloques de CIDR agregados a una nube privada virtual (VPC). Un rango actualizado causado por la adición de bloques de CIDR a un clúster existente puede tardar hasta cinco horas en ser reconocido por Amazon EKS. Para obtener más información, consulte los requisitos y consideraciones sobre la VPC y las subredes de Amazon EKS.
Si los pods se ejecutan en el rango CIDR secundario, realice las siguientes acciones:
- Espere hasta cinco horas para que estos comandos empiecen a funcionar.
- Asegúrese de tener al menos cinco direcciones IP libres en cada subred para completar correctamente la automatización.
Utilice la siguiente política de ejemplo para ver las direcciones IP libres de todas las subredes de cualquier VPC:
[ec2-user@ip-172-31-51-214 ~]$ aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-078af71a874f2f068" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"' "subnet-0d89886ca3fb30074=8186" "subnet-0ee46aa228bdc9a74=8187" "subnet-0a0186a277b8b6a51=8186" "subnet-0d1fb1de0732b5766=8187" "subnet-077eff87a4e25316d=8187" "subnet-0f01c02b04708f638=8186"
Los grupos de seguridad que se utilizan para el plano de control y el nodo tienen las reglas mínimas requeridas de entrada y salida
Cuando se ejecuta en nodos de trabajo, un servidor de la API debe tener las reglas mínimas requeridas de entrada y salida para hacer una llamada a la API de kubelet. Para verificar que el plano de control y los grupos de seguridad de nodos tienen las reglas mínimas requeridas de entrada y salida, consulte Requisitos y consideraciones sobre grupos de seguridad de Amazon EKS.
El ConfigMap aws-auth tiene el rol de IAM correcto con el nombre de usuario de Kubernetes asociado al nodo
Debe aplicar el rol de IAM correcto al ConfigMap aws-auth. Asegúrese de que el rol de IAM tenga el nombre de usuario de Kubernetes asociado a su nodo. Para aplicar el ConfigMap aws-auth a su clúster, consulte Agregar roles o usuarios de IAM a su clúster de Amazon EKS.
Se cumple el requisito de enviar un nuevo certificado
Los clústeres de Amazon EKS requieren que el kubelet del nodo envíe y rote el certificado de servicio por sí mismo. Se produce un error de certificado cuando un certificado de servicio no está disponible.
1. Ejecute el siguiente comando para validar el certificado del servidor kubelet:
cd /var/lib/kubelet/pki/# use openssl command to validate kubelet server cert sudo openssl x509 -text -noout -in kubelet-server-current.pem
El resultado es similar al siguiente:
Certificate: Data: Version: 3 (0x2) Serial Number: 1e:f1:84:62:a3:39:32:c7:30:04:b5:cf:b0:91:6e:c7:bd:5d:69:fb Signature Algorithm: sha256WithRSAEncryption Issuer: CN=kubernetes Validity Not Before: Oct 11 19:03:00 2021 GMT Not After : Oct 11 19:03:00 2022 GMT Subject: O=system:nodes, CN=system:node:ip-192-168-65-123.us-east-2.compute.internal Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:7f:44:c6:95:7e:0f:1e:f8:f8:bf:2e:f8:a9:40: 6a:4f:83:0a:e8:89:7b:87:cb:d6:b8:47:4e:8d:51: 00:f4:ac:9d:ef:10:e4:97:4a:1b:69:6f:2f:86:df: e0:81:24:c6:62:d2:00:b8:c7:60:da:97:db:da:b7: c3:08:20:6e:70 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: A8:EA:CD:1A:5D:AB:DC:47:A0:93:31:59:ED:05:E8:7E:40:6D:ED:8C X509v3 Authority Key Identifier: keyid:2A:F2:F7:E8:F6:1F:55:D1:74:7D:59:94:B1:45:23:FD:A1:8C:97:9B X509v3 Subject Alternative Name: DNS:ec2-3-18-214-69.us-east-2.compute.amazonaws.com, DNS:ip-192-168-65-123.us-east-2.compute.internal, IP Address:192.168.65.123, IP Address:3.18.214.69
2. Revise los registros de kubelet en busca de errores de certificación. Si no se muestra ningún error, significa que se ha cumplido el requisito de enviar nuevos certificados.
Ejemplo de un error de certificación del registro kubelet:
kubelet[8070]: I1021 18:49:21.594143 8070 log.go:184] http: TLS handshake error from 192.168.130.116:38710: no serving certificate available for the kubelet
Nota: Para obtener registros más detallados, active los registros detallados de kubelet con la marca --v=4 y luego reinicie el kubelet en el nodo de trabajo. El registro detallado de kubelet tiene un aspecto similar al siguiente:
#kubelet verbosity can be increased by updating this file ...max verbosisty level --v=4 sudo vi /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf # Normal kubelet verbosisty is 2 by default cat /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf [Service] Environment='KUBELET_ARGS=--node-ip=192.168.65.123 --pod-infra-container-image=XXXXXXXXXX.dkr.ecr.us-east-2.amazonaws.com/eks/pause:3.1-eksbuild.1 --v=2 #to restart the demon and kubelet sudo systemctl daemon-reload sudo systemctl restart kubelet #make sure kubelet in running state sudo systemctl status kubelet # to stream logs for kubelet journalctl -u kubelet -f
3. Si aparece un error, verifique el archivo de configuración de kubelet /etc/kubernetes/kubelet/kubelet-config.json en el nodo de trabajo, y luego confirme que las marcas RotateKubeletServerCertificate y serverTLSBootstrap aparecen como verdaderas:
"featureGates": { "RotateKubeletServerCertificate": true }, "serverTLSBootstrap": true,
4. Ejecute el siguiente comando eks:node-bootstrapper para confirmar que el kubelet tiene los permisos del sistema de control de acceso basado en roles (RBAC) necesarios para enviar la solicitud de firma de certificado (CSR):
$ kubectl get clusterrole eks:node-bootstrapper -o yaml apiVersion: rbac.authorization.k8s.io/v1
El resultado es similar al siguiente:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"node"},"name":"eks:node-bootstrapper"},"rules":[{"apiGroups":["certificates.k8s.io"],"resources":["certificatesigningrequests/selfnodeserver"],"verbs":["create"]}]} creationTimestamp: "2021-11-09T10:07:42Z" labels: eks.amazonaws.com/component: node name: eks:node-bootstrapper resourceVersion: "199" uid: da268bf3-31a3-420a-9a71-414229437b7e rules: - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests/selfnodeserver verbs: - create
Los permisos de control de acceso basado en roles (RBAC) requeridos incluyen los siguientes atributos:
- apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeserver"] verbs: ["create"]
5. Ejecute el siguiente comando para verificar si el rol de clúster eks:node-bootstrapper está vinculado a system:bootstrappers y system:nodes. Esto permite al kubelet enviar y rotar el certificado de servicio por sí mismo.
$ kubectl get clusterrolebinding eks:node-bootstrapper -o yaml apiVersion: rbac.authorization.k8s.io/v1
El resultado es similar al siguiente:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"node"},"name":"eks:node-bootstrapper"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"eks:node-bootstrapper"},"subjects":[{"apiGroup":"rbac.authorization.k8s.io","kind":"Group","name":"system:bootstrappers"},{"apiGroup":"rbac.authorization.k8s.io","kind":"Group","name":"system:nodes"}]} creationTimestamp: "2021-11-09T10:07:42Z" labels: eks.amazonaws.com/component: node name: eks:node-bootstrapper resourceVersion: "198" uid: f6214fe0-8258-4571-a7b9-ff3455add7b9 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:node-bootstrapper subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:bootstrappers - apiGroup: rbac.authorization.k8s.io kind: Group name: system:nodes
Contenido relevante
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 10 meses
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 2 años