同僚が作成したEKS Kubernetesインスタンスでkubectl
を認証できません。私は thedocumentation に従いました:AWS CLIはaws eks
コマンドを実行でき(私はAWSの完全管理者です)、heptio認証者がパスにありますトークンを生成できます。
kubectl
を実行すると、次のエラーが発生します。
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.4",
GitCommit:"5ca598b4ba5abb89bb773071ce452e33fb66339d", GitTreeState:"clean",
BuildDate:"2018-06-06T15:22:13Z", GoVersion:"go1.9.6", Compiler:"gc",
Platform:"darwin/AMD64"}
error: You must be logged in to the server (the server has asked for the client
to provide credentials)
これが私の〜/ .kube/configファイルです。これは、同僚が正常に使用できる正確なkubeconfigです。
apiVersion: v1
clusters:
- cluster:
server: https://myinstance.sk1.us-east-1.eks.amazonaws.com
certificate-authority-data: base64_cert name: kubernetes contexts: - context: cluster: kubernetes user: aws name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
user:
exec:
apiVersion: client.authentication.k8s.io/v1alpha1
command: heptio-authenticator-aws
args:
- "token"
- "-i"
- "dev-qa"
# - "-r"
# - "<role-arn>"
IAMユーザーをConfigMapのmapUsers
セクションに追加する必要がありましたconfigmap/aws-auth
、あたり これらのAWSドキュメント 。
最初にクラスターを作成したのと同じAWSユーザーを使用してconfigmapを編集できます。
$ kubectl edit -n kube-system configmap/aws-auth
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::555555555555:role/devel-worker-nodes-NodeInstanceRole-74RF4UBDUKL6
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::555555555555:user/admin
username: admin
groups:
- system:masters
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
mapAccounts: |
- "111122223333"
残念ながら、AWSにはまだGKEの「gcloud container clusters get-credentials」のようなコマンドがないため、kubectl configが作成されます。そのため、kubectl構成ファイルを手動で作成する必要があります。
Amazon EKSのkubeconfigの作成 ドキュメントで説明したように、クラスターから2つのものを取得する必要があります。
クラスターのエンドポイントを取得します。これを、kubeconfigファイルの<endpoint-url>
に使用します。
aws eks describe-cluster --cluster-name <cluster-name> --query cluster.endpoint
クラスターのcertificateAuthority.dataを取得します。これを、kubeconfigファイルの<base64-encoded-ca-cert>
に使用します。
aws eks describe-cluster --cluster-name <cluster-name> --query cluster.certificateAuthority.data
デフォルトのkubectlフォルダーが存在しない場合は作成します。
mkdir -p ~/.kube
お気に入りのテキストエディターを開き、次のkubeconfigコードブロックを貼り付けます。
apiVersion: v1
clusters:
- cluster:
server: <endpoint-url>
certificate-authority-data: <base64-encoded-ca-cert>
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: aws
name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
user:
exec:
apiVersion: client.authentication.k8s.io/v1alpha1
command: heptio-authenticator-aws
args:
- "token"
- "-i"
- "<cluster-name>"
# - "-r"
# - "<role-arn>"
# env:
# - name: AWS_PROFILE
# value: "<aws-profile>"
<endpoint-url>
を、クラスター用に作成されたエンドポイントURLに置き換えます。 <base64-encoded-ca-cert>
を、クラスター用に作成されたcertificateAuthority.dataに置き換えます。 <cluster-name>
をクラスター名に置き換えます。
ファイル名にクラスター名を付けて、ファイルをデフォルトのkubectlフォルダーに保存します。たとえば、クラスター名がdevelの場合、ファイルを~/.kube/config-devel
に保存します。
そのファイルパスをKUBECONFIG
環境変数に追加して、kubectl
がクラスター構成の検索場所を認識できるようにします。
export KUBECONFIG=$KUBECONFIG:~/.kube/config-devel
(オプション)シェルを開いたときに構成されるように、構成をシェル初期化ファイルに追加します。
MacOSのBashシェルの場合:
echo 'export KUBECONFIG=$KUBECONFIG:~/.kube/config-devel' >> ~/.bash_profile
LinuxのBashシェルの場合:
echo 'export KUBECONFIG=$KUBECONFIG:~/.kube/config-devel' >> ~/.bashrc
構成をテストします。
kubectl get svc
出力:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 1m
注
エラー"heptio-authenticator-aws": executable file not found in $PATH
を受け取った場合、kubectl
はAmazon EKS用に設定されていません。詳細については、「 Amazon EKS用にkubectlを設定する 」を参照してください。
この問題は、作成したkubeconfigファイルのbase64エンコード証明書を修正することで解決しました。 EKSサービスのaws cliで--cluster-nameスイッチを使用すると記載されているため、ドキュメントは少し混乱しています。私にとっては--nameスイッチが機能しました。これにより、base64の値がcliに出力され、パスタを保存されたkubeconfigファイルにコピーして機能しました。
$ AWS_ACCESS_KEY_ID=[YOUR_ID_HERE] AWS_SECRET_ACCESS_KEY=[YOUR_SECRET_HERE] aws eks describe-cluster --name staging --query cluster.certificateAuthority.data
コマンドに合わせてAWS構成変数を渡します(またはグローバル変数として設定します)。
例:
AWS_PROFILE=profile_name kubectl get all
時間の経過とともに、物事は少し単純になりました。 Linux(または実際にWSL)で開始するには、次のことを行う必要があります。
aws configure
またはAWS SSOを使用してオンザフライで時間制限のある認証情報を生成します)この時点で、すでにAWSアカウントで実行中のKubernetes Clusterがあると想定して、次の1つのコマンドで$ HOME/.kube/configのkube設定を生成/更新できます。
aws eks update-kubeconfig --name test
ここで、test
は、AWSコンソール(またはaws eks list-clusters
)によるクラスター名です。
エラーなしでインスタンスkubectl get svc
を実行できるようになりました。