contentKubernetesクラスター内のPodからkubectlを実行するkubernetesibmcloudprivateKubernetesクラスター内のPodからkubectlコマンドを実行する方法について調べたのでメモ。参考リンク以下に丁寧な回答がある。container?イメージの作成kubectlのバイナリを配置したイメージを作る。ubuntuubuntuをベースにイメージを作る。alpinealpineをベースにする場合は以下のようにする。sotoiwa540/kubectl:v1.13.0-alpineutuntuとaplineでイメージサイズはこれくらい違う。ubuntuのほうはwgetとその依存パッケージを削除していないので、削除するようにしたらもう少しだけ減る。43.6MB$ibmcom/kubectlICPだとibmcom/kubectl:v1.11.1.1というイメージが既にあり、同じようにaplineにkubectlのバイナリを配置したもののようだ。#Podの実行Podとして実行する場合、特に何もしなくてもkubectlが使える(apiserverに接続できる)。kubectlがこのようにapiserverへの接続情報を設定しているため。接続するapiserverを環境変数KUBERNETES_SERVICE_HOSTとKUBERNETES_SERVICE_PORTから取得KubernetesクラスターではapiserverはkubernetesというServiceリソースとして定義されていてクラスター内からService経由でアクセスできるアクセストークンをコンテナにマウントされている/var/run/secrets/kubernetes.io/serviceaccount/tokenから取得apiserverのサーバー証明書をコンテナにマウントされている/var/run/secrets/kubernetes.io/serviceaccount/ca.crtから取得Podとして実行してみる。kubectl-pod.yamlトークンと証明書はPodが実行されるときにKubernetesによって必ず自動的にマウントされている。default-token-cn7gt...$ただしこれだけではapiserverに接続できるものの、NamespaceのデフォルトのServiceAccountで実行しているため権限がなくPodをListすることもできない。1$新たにServiceAccountを作り、このServiceAccountに強力なClusterRoleを割り当てる。created$デフォルトで存在するcluster-adminのClusterRoleが強力なので、このClusterRoleを作成したServiceAccountにバインドする。ClusterRoleはClusterRoleBindingでバインドすることもできるし、RoleBingingでバインドすることもできるが、RoleBidingでバインドした場合は権限がNamespaceに限定されるClusterRoleBindingはじめにClusterRoleBindingを作成する。adminの指定を追加する。/dev/nullPodを再作成する。kubectl-pod.yamlkubectlでPodがリストできることを確認。4d22h$一度ClusterRoleBindingを削除する。admin-clusterrolebindingRoleBinding今度はRoleBindingを作成してみる。admin-rolebinding.yaml同じcluster-adminのClusterRoleをバインドしているにもかかわらず、自分以外のNamespaceへの権限がない。想土@sotoiwa私の投稿する内容は個人の見解であり、所属団体を代表するものではありません。プロフェッショナルサービスAWSプロフェッショナルサービスは、お客様がクラウドのイノベーティブな活用によりビジネス価値を生み出すことを支援し、加速させるための有償のコンサルティングチームです。Twitterで情報発信しています。upLoginユーザーは見つかりませんでした。