AKSのハッカソンで学んだことメモ
やりたいこと と 実現コマンドを対応させて書いていきます。
DockerコンテナのIPアドレスを確認したい
dockerコンテナの情報確認
docker ps
docker inspect <コンテナID> | grep IPAddress
プライベートコンテナレジストリにログインしたい
az acr login --name <レジストリ名>
もしくは
docker login <レジストリ名>.azurecr.io
Dockerイメージをプルしてきたいとき（プライベートリポジトリ）
docker pull <レジストリ名>.azurecr.io/<リポジトリ名>:<バージョン番号>
Dockerfileからイメージをビルドしたいとき
docker build -f <dockerfile名> -t "<イメージ名>" <dockerファイルの場所>
Dockerイメージからコンテナを作成したいとき
docker run [option]
参考
Dockerコンテナのイメージを表示したいとき
docker images
Dockerイメージにタグを付与したいとき（プライベートリポジトリのプッシュに向けて）
docker tag <ローカルイメージ>:<バージョン> <acrLoginServer>/<イメージ名>:<バージョン番号>
参考
Dockerイメージをプッシュしたいとき
docker push <acrLoginServer>/<イメージ名>:<バージョン番号>
wslとは
windows上でLinuxコマンドを実施するためのツール
レジストリとリポジトリの違い
レジストリはイメージと関連配布物を管理する大きなハコ
リポジトリは、その中に存在する、タグやバージョンによって管理される成果物のハコ
（xx/xx/xx:1.0とかでやった場合だと、どういう階層になるのだろうか…）
AKSクラスターに接続したいとき
az aks get-credentials --resource-group <リソースグループ名> --name <クラスター名>
上のステップを実行するには、Azure Kubernetes Service クラスター ユーザー組み込みロールが必要です。（所有者にすると関係ないが）
現在の向き先となっているAKSクラスターの確認
kubectl config get-contexts
出力結果のCURRENTに* と付いているのがカレントクラスタ
yamlからkubernetessオブジェクトを作成したいとき
kubectl apply -f <yamlファイル名>
AKSクラスター内のリソース操作
podを表示したいとき。ネームスペースはdefault以外を使っている場合。
kubectl get pod --namespace <ネームスペース名>
serviceを表示したいとき。
kubectl get services
nodeを表示したいとき。
kubectl get nodes
podに接続してシェルを実行したいとき（Linuxコマンド）
kubectl exec -i -t <ポッド名> -- /bin/bash
各種リソース(pod・services)を削除したいとき。ネームスペース名はdefault以外を使っているとき。
kubectl delete <削除リソースの種類。podとか> <リソース名> --namepsace <ネームスペース名>
podのログを確認したいとき。ネームスペースはdefault以外を使っている場合。
kubectl logs <pod名> --namepsace <名前空間>
AKSクラスタにkey vaultシークレットへのアクセスを追加したいとき。
やることとしては以下の通り。
-
シークレットストアのCSIドライバーの構成
これはポータルからも実行できる。ポータルから実行することで、マネージドIDが自動で作成される。CLIベースの時にはマネージドIDも作成が必要。
https://learn.microsoft.com/en-us/azure/aks/csi-secrets-store-driver -
key vaultの作成（＆シークレットの追加）
az keyvault create -n <keyvault-name> -g myResourceGroup -l eastus2
シークレットの追加はパスワード認証の場合
az keyvault secret set --vault-name <keyvault-name> -n ExampleSecret --value MyAKSExampleSecret
- AKSアクセスポリシーへのマネージドIDの作成・追加
シークレット・キー・証明書に応じて、以下の3つから選択をすること。
az keyvault set-policy -n $KEYVAULT_NAME --key-permissions get --spn $USER_ASSIGNED_CLIENT_ID
az keyvault set-policy -n $KEYVAULT_NAME --secret-permissions get --spn $USER_ASSIGNED_CLIENT_ID
az keyvault set-policy -n $KEYVAULT_NAME --certificate-permissions get --spn $USER_ASSIGNED_CLIENT_ID
- yamlでkey vaultを参照するように修正
podのymamlには以下の追加が必要
volumeMounts:
- name: secrets-store01-inline
mountPath: "/mnt/secrets-store"
readOnly: true
volumes:
- name: secrets-store01-inline
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "azure-kvname-podid"
その他、SecretProviderClassを使って、コンテナからキーボルトにアクセスするためのシークレット情報もyamlで記載する必要がある。詳細は以下の参考資料を確認すること。
- 環境変数に設定したいとき
参考資料
知識的なところ
ここからは、実際に操作するときのコマンドではなく、知識中心の話。
AKSリソースの接続時に権限エラーが出るとき。
クレデンシャルにキャッシュが残っているのが原因の可能性が高い。ファイル毎削除してしまうのが良い。
どこかに、.kubeフォルダがあるはず。get credentialしたときに表示されるパスである。
kubernetessのサービスの存在意義
内部ロードバランサーや、プロキシのような役割を果たす。
podに直接Ip指定でアクセスすることもできるが、コンテナという世界なので、pod自体置き換わる可能性も高いし、pod自体が複数ある場合には管理上非効率である。
そのため、なくても動作上は問題ないが、基本的には作成しておくリソースになると考えてよい。
kubernetessのサービスへのpingについて
AKSについてはpingは応答しない仕様らしい
Azure RBACとkubernetess RBACについて
前者はAzure でのロール、後者はマニフェストを書いてkuberntess上で適用するアクセス制御。
実際にAKSを作るときにどのアクセス制御方法を使うかによって、上記どれを使うかも変わってくる。
参考資料
(Azure RBACを使うように既存のクラスターをupdateするときに使った）
podは削除しても自動で立ち上がる？
レプリケートの数で指定しているから？
→ その通りっぽい。replicasパラメータに記載した数は、自動的にpodが起動されるようである。
kubernetessのLoad BalancerとIngressの用途違い
前者はL4レベル、後者はL7レベルの負荷分散になる。そのため、Ingressの場合はURLパスベースルーティング(/apiの場合はコッチ、/webの場合はコッチ）やドメイン名による振り分けが実現できる。Load Balancerの場合は、送信元IP、送信元ポート、宛先IP、宛先ポート、プロトコルの５つ（5タプルハッシュ）の条件を利用して振り分け先を決める。
Tips
portalにできないことでも、CLIベースだとできることがあるらしい。
というのも、まずはREST APIを作って、それを呼び出すCLIを作る部隊や、Portalを作る舞台が存在する。あくまでportalは代表的な操作になってしまうことも多いようだ。CLIを使えるようになりたいと思った。
Discussion
私は、pod起動/確認するときにnamespaceをつけ忘れてdefaultで起動/参照しちゃうことがあってハマりました。。
あとは「AKSクラスタにkey vaultシークレットへのアクセスを追加」は結構難しかったです。。