よく使うkubernetesのkubectlコマンド一覧
##1) podを作成
kubectl create --save-config -f [Pod定義ファイル]
または
kubectl apply -f [Pod定義ファイル]
とりあえずapplyにしておくのがベター。
applyの場合は、前回実行時とのyaml設定の差分を抽出して、
その差分を反映するらしく、createたけで作成すると差分抽出の
ための履歴情報がないため、createだけの後のapplyではエラーとなる。
ただし、create --save-configとしておけばcreateでもOK。
##2) rs(Replica Set)を作成
kubectl create --save-config -f [rs定義ファイル]
or
kubectl apply -f [rs定義ファイル]
rsを作成すると、複数のpodを一括管理できる。また、いくつpodを起動するかを規定し、podが停止すると、自動的に規定数のpodにリカバリしてくれる。
Replication Controllerは初期のオブジェクト（kind設定）で、現在はReplicaSetが代替え。
ただしほとんど機能の差分はない。
さらに、ReplicaSetのラッパー的な上位レイヤーに位置するDeployment
を利用することが推奨されている。
DeploymentはバックエンドでReplicaSetを利用し、コンテナイメージの更新時のデプロイ戦略をケアしてくれる。1 Podのデプロイでも基本的にはDeploymentの利用が推奨されている。
参考）Deployment Strategy
Deploymentオブジェクトで規定できる戦略は具体的には下記
- Recreate : 現行バージョンを終了してから新バージョンをデプロイ
- Rolling Update：Podごとに段階的に新バージョンに切り替え
Rolling Updateの場合は、一時的にReplica数を超えてPodが起動し、サービス断を回避した更新が可能。更新時に問題が発生した場合は更新は停止され、ロールバックが可能。
デフォルトではRolling Updateが有効となる。
一般的なデプロイメント手法としてその他に Blue/Green、Canary、A/B Testingなどがあるが、それらの方法を利用したい場合は、Spinnaker、istioなどのエコシステムを活用する。
##3) Serviceを作成
kubectl create -f [Service定義ファイル]
Pod（コンテナ）を外部と通信させる場合はServiceを定義する。Serviceがプロキシとなり、例えばホストアドレス:Portへのアクセスを、Podの接続先内部アドレス:Portに変換し、相互接続が可能となる。
参考）クラスタ外部からのアクセス
クラスタに外部からアクセスするサービスを提供するには、Serviceを利用する。Serviceには複数のtypeフィールドが指定できる。
- LoadBalancer : クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開する
- NodePort : 各NodeのIPにて、静的なポート(NodePort)上でServiceを公開する
- etc.
または、Ingressオブジェクトで外部向けエンドポイントを生成し、Serviceに紐づける方法もある。
##4) pod一覧を確認
kubectl get pod
例
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
jenkins-lf3br 1/1 Running 0 3d
STATUS
Running： 稼働中
Pending： Pod起動待ち
ImageNotReady: dockerイメージ取得中
PullImageError： dockerイメージ取得失敗
CreatingContainer: Pod(コンテナ)起動中
Error: エラー
etc.
-o wide
オプションで、各Podの実行ホストIPも表示できる
-o yaml [pod名]
オプションで、指定podのyamlを確認できる
-L [ラベル名]
オプションで、指定ラベルキーと値も出力
-l [ラベルフィルタ条件]
オプションで、指定ラベル条件でフィルタ可能
-n [NameSpace名]
オプションで、NameSpaceを指定して実行
-A
オプションで、全NameSpaceの結果を取得
##5) rs(Replica Set)一覧を確認
Replication Controllerの場合は
kubectl get rs
ReplicaSetの場合は
kubectl get rs
Deploymentの場合は
kubectl get deploy
##6) svc(Service)一覧を確認
kubectl get svc
##7) podを削除
kubectl delete pod [Pod名]
または
kubectl delete -f [作成時のPod定義ファイル]
強制的にすぐ削除したい場合は以下オプション
—grace-period 0 —force
##8) rs(Replica Set)を削除
kubectl delete rs [rs名]
または
kubectl delete -f [作成時のyaml定義ファイル]
※rsで作成されたpodを個別に削除しても、rsがpodを自動再生成するので、rs自体を削除する必要がある
※Replication Controllerの場合は rc
##9) svc(Service)を削除
kubectl delete svc [svc名]
または
kubectl delete -f [作成時のsvc定義ファイル]
##10) ログの確認
kubectl logs [pod名]
-fオプションで、tail -f 相当のリアルタイムフォロー出力
--since=1hオプションで、最新1時間以内を抽出
--tail=10オプションで、最新10件を抽出
--timestamps=trueオプションで、タイムスタンプ付与
##11) pod/rc/rs/svcの詳細を確認する
kubectl describe [Pod名/rc名/rs名/svc名]
##12) 起動したPodにログインする
kubectl exec -it [コンテナ名] /bin/bash
ログオフする時はexitコマンド
各種オプション
-i：コンテナへ標準入力（STDIN）を渡す
-t：標準入力（STDIN）をTTY（コンソール入力）とする
##13) Podの環境変数を確認
kubectl exec [Pod名] env
##14) Podのマウントされたボリュームを確認
kubectl exec [Pod名] ls /[Path]
##15) Pod（コンテナ）上でコマンドを実行
kubectl exec [Pod名] [コマンド]
例）
$kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 6m
$kubectl exec nginx echo "Hello"
Hello
##16) コンテナ(Pod)の複製数を変更（Scale）する
kubectl scale rs [rs名] --replicas=[数]
現状のレプリカ数が１で、上記で３を指定すると、新たに２個追加される
Replication Controllerの場合は rs → rc
deploymentの場合は rs → deployment
参考）Autoscaleの場合
kubectl autoscale deployment [deployment名] --cpu-percent=[目標CPU%] --min=[最小レプリカ数] --max=[最大レプリカ数]
##17) リソース消費量確認（top）
workerノードとpodのリソース消費量（CPU/MEMORY）を確認できる
kubectl top node
kubectl top pod
##18) workerノードを安全に切り離し
kubectl drain [ノード名]
稼働中のpodが順次evictedされた後に、切り離される
事前に下記コマンドを実行すると、該当ノードに新規Podをスケジュールさせない設定ができる
kubectl cordon [ノード名]
##19) ホストからPod内にファイルをコピー
kubectl cp ./[file] [pod NAME]:[格納先パス]
※docker cpと同じ
##20) ワンライナーでコンテナ起動
yamlを使わずにサクッと作りたい場合
①Pod
kubectl run [作成するコンテナ名] --image=[イメージ:タグ]
他にもオプションあり
--restart=[再開ルール：Always, OnFailure, Never]
--port=[ポート]
--replicas=[レプリカ数]
--schedule=[CronTab用のルール]
--limits=[CPU/Memのリソース上限]
などなど
②deployment
kubectl create deployment [名前] --image=[コンテナイメージ]
#21) ワンライナーでサービス起動
yamlを使わずにサクッと作りたい場合
kubectl expose deployment [公開対象のコンテナ(deployment)] --type=LoadBalancer
参考）オプション
ターゲットdeploymentにフォワーディングする際のFrom/ToのPortを指定
--port=80
--target-port=8080
公開対象のdeploymentにLBする外部IPをもつServiceが生成される
外部からアクセスするためのExternalIPは下記で確認可能
$kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
test-app LoadBalancer 10.0.XX.XX 35.225.XX.XX 80:30133/TCP 1m0s
##22) イメージの更新（Rolling Update）
kubectl set image deployment [デプロイメント名] [イメージ名]=[イメージ名]:[タグ]
例）
kubectl set image deployment nginx nginx=nginx:1.9.1
これで、nginxイメージを1.9.1にローリングアップデートしてくれる
ただし、yamlベースで管理するなら、kubectl apply で更新した方が良い
23）コンテナのリソース制限状態の確認
Pod単位のCPU/Memoryのリソース割り当ての制限が可能で、その設定状態の確認方法が下記。
kubectl describe nodes [ノード名]
例）
：
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
：
参考）リソース管理
リソース制限設定
- Resource Requests : Podデプロイに必要なCPU/Memory数
- Resource Limits : Podが使用可能な最大のCPU/Memory数
Pod割り当て（スケジュール）の際に、Resource Requestsで規定したリソースがない場合は、Pending状態になり、Podはデプロイされずキューイングされる。
Resource Limitsのみの設定も可能だが、その場合デフォルトでResource Requestsも同じ値に指定されてしまうため注意が必要。
24）ConfigMap/Secretの作成
複数のPodで環境変数やクレデンシャルなどのKey:Value形式の値を共有したい場合に便利なConfigMapとSecretの作り方。
ConfigMapは平文のKey:Valueなのに対してSecretはValueがBase64エンコードされる点などが異なる。
実運用では、他のオブジェクト同様にyamlファイルで管理するのが理想だが、コマンドで生成する方法。
作り方はいろいろ
※Secretの場合は下記のconfigmap を secret generic に置き換え
①ファイルから読み込み
kubectl create configmap(or cm) [コンフィグ名] --from-env-file=[ファイルパス]
ファイルはこんな感じ
[キー1]=[バリュー1]
[キー2]=[バリュー2]
：
※–from-file オプションもあるが省略
②コマンド内に指定
kubectl create configmap(or cm) [コンフィグ名] --from-literal=[キー1]=[バリュー1] --from-literal=[キー2]=[バリュー2]
参考
https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-pod-configmap/