Amazon EKS で kubectl コマンドを実行できないのはなぜですか?
Amazon Elastic Kubernetes Service (Amazon EKS) で kubectl exec、kubectl logs、kubectl attach、kubectl port-forward などの kubectl コマンドを正常に実行できません。
解決方法
API サーバーはワーカーノードで実行される kubelet と通信していないため、通常、kubectl コマンドは Amazon EKS クラスターで失敗します。一般的な kubectl コマンドには、kubectl exec、kubectl logs、kubectl attach、kubectl port-forward などがあります。
この問題をトラブルシューティングするには、次の点を確認します。
- ポッドがセカンダリ Classless Inter-Domain Routing (CIDR) 範囲で実行されていること。
- コントロールプレーンとノードに使用されるセキュリティグループがインバウンドルールとアウトバウンドルールのためのベストプラクティスを使用していること。
- aws-auth ConfigMap が、ノードに関連付けられた Kubernetes ユーザー名を持つ正しい AWS Identity and Access Management (IAM) ロールを備えていること。
- 新しい証明書を提出するための要件が満たされていること。
ポッドがセカンダリ Classless Inter-Domain Routing (CIDR) 範囲で実行されていること
クラスターを作成した直後、Amazon EKS は仮想プライベートクラウド (VPC) に追加された CIDR ブロックからサブネットで起動されたノードと通信できなくなります。CIDR ブロックを既存のクラスターに追加することによって更新された範囲が Amazon EKS で認識されるまでに、最長で 5 時間かかる場合があります。詳細については、「Amazon EKS VPC とサブネットの要件と考慮事項」を参照してください。
ポッドがセカンダリ CIDR 範囲で実行されている場合は、次のアクションを実行します。
- これらのコマンドが動作を開始するまで最長で 5 時間待機します。
- オートメーションを正常に完了するには、各サブネットに少なくとも 5 つの空き IP アドレスが確実にあるようにしてください。
VPC 内のすべてのサブネットの空き IP アドレスを表示するには、次のサンプルポリシーを使用します。
[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"
コントロールプレーンとノードに使用されるセキュリティグループが、最低限必要とされるインバウンドルールとアウトバウンドルールを備えていること
ワーカーノードで実行する場合、API サーバーには kublet への API 呼び出しを行うために必要な最低限のインバウンドルールとアウトバウンドルールが必要です。コントロールプレーンとノードのセキュリティグループに最低限必要なインバウンドルールとアウトバウンドルールがあることを確認するには、「Amazon EKS セキュリティグループの要件および考慮事項」を参照してください。
aws-auth ConfigMap が、ノードに関連付けられた Kubernetes ユーザー名を持つ正しい IAM ロールを備えていること
正しい IAM ロールを aws-auth ConfigMap に適用する必要があります。ノードに関連付けられた Kubernetes ユーザー名が IAM ロールにあることを確認してください。aws-auth ConfigMap をクラスターに適用するには、「IAM ユーザーまたはロールを Amazon EKS クラスターに追加する」を参照してください。
新しい証明書を提出するための要件が満たされていること
Amazon EKS クラスターでは、ノードの kubelet が自らのためにサービス証明書を送信およびローテーションする必要があります。証明書エラーは、サービス証明書が利用できない場合に発生します。
1. 次のコマンドを実行して kubelet サーバー証明書を検証します。
cd /var/lib/kubelet/pki/# use openssl command to validate kubelet server cert sudo openssl x509 -text -noout -in kubelet-server-current.pem
出力は次のようになります。
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. kubelet ログで証明書エラーがないか確認します。エラーが表示されない場合、新しい証明書の提出要件は満たされています。
kubelet log cert エラーの例:
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
注: より詳細なログを取得するには、フラグ --v=4 で kubelet 詳細ログをオンにしてから、ワーカーノードで kubelet を再起動します。kubelet の詳細ログは次のようになります。
#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. エラーが表示された場合は、ワーカーノードで kubelet 設定ファイル /etc/kubernetes/kubelet/kubelet-config.json を確認し、RotateKubeletServerCertificate フラグと serverTLSBootstrap フラグが true としてリストされていることを確認します。
"featureGates": { "RotateKubeletServerCertificate": true }, "serverTLSBootstrap": true,
4. 次の eks:node-bootstrapper コマンドを実行して、kubelet が証明書署名リクエスト (CSR) を送信するために必要なロールベースアクセスコントロール (RBAC) システム許可を備えていることを確認します。
$ kubectl get clusterrole eks:node-bootstrapper -o yaml apiVersion: rbac.authorization.k8s.io/v1
出力は次のようになります。
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
必要な RBAC 許可には、次の属性が含まれます。
- apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeserver"] verbs: ["create"]
5. 次のコマンドを実行して、クラスターロール eks:node-bootstrapper が system:bootstrappers および system:nodes にバインドされているかどうかを確認します。これにより、kubelet はサービス証明書を送信したり、自らのためにローテーションしたりできます。
$ kubectl get clusterrolebinding eks:node-bootstrapper -o yaml apiVersion: rbac.authorization.k8s.io/v1
出力は次のようになります。
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
関連するコンテンツ
- AWS公式更新しました 2年前
- AWS公式更新しました 10ヶ月前
- AWS公式更新しました 9ヶ月前