もくじ
このあたりのコマンドをさらっと打てれば、kubernetesを知ってる風な空気をだすことができるんじゃないでしょうか。たぶん。
とてもよく使うコマンド
1.kubectl get [resource]
2.kubectl describe [resource] [name]
3.kubectl apply -f [file/directory]
デバックとかで使うコマンド
4.kubectl delete [resource] [name]
5.kubectl edit [resource] [name]
6.kubectl exec -it [pod_name] -- [command]
Podが動かないよー💦な時とかに使うコマンド
7.kubectl logs [pod_name]
8.kubectl get event | grep [pod_name]
どう使うので?
1. kubectl get [resource]
Linuxでいうlsやllくらいよく使うコマンド。
このコマンドを知っていれば、「ちなみにkubernetesって使えます？」
...もうこの質問にいちいち「はい」と答える必要はない。
「フッ...」とニヒルな笑みを湛えつつ、このコマンドを打ち込もう。
「kubectl get pod (I can fly)」と...
０.１秒以内に打つことができれば、あなたも一流のkuberneterだ！
ちなみに指定されたresourceの一覧を取得するコマンドです。
resourceの種類については別記事で。
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
tomato-45c8b9c54b-ghcxh 1/1 Running 0 6d4h
2. kubectl describe [resource] [name]
これをさらっと打てると、「こいつ、知ってる...」感を出せるコマンド。
指定した[resource]の[name]の詳細を表示する。
$ kubectl describe pod tomato-45c8b9c54b-ghcxh
Name: tomato-45c8b9c54b-ghcxh
Namespace: tomato-nouen
Priority: 0
Node: aks-nodepool1-27391652-vmss000002/172.24.xxx.xx
Start Time: Fri, 10 Jan 2020 18:11:48 +0900
・・・以下略
3. kubectl apply -f [file/directory]
yamlに書いた内容をデプロイする時に使うコマンド。
後述するeditコマンドとかでもデプロイできなくもないが、管理ができないので通常はこのコマンドでデプロイするものと思われる。
冪等性を担保するため、なるべくディレクトリごと指定する方法を推奨。
ちなみに、kind=configmapのyamlのみをデプロイしても、古い設定のままのPodが元気に動き回っている状態なので注意。
新しい設定のPodをオギャーさせるには、kind=deploymentなどのyamlを読み込むか、古いPodを後述のdeleteコマンドで削除する必要がある。
$ kubectl apply -f tomato/configmap.yaml
configmap/tomato created
$ kubectl apply -f tomato/deployment.yaml
deployment.apps/tomato created
ディレクトリごと指定する場合
$ kubectl apply -f tomato
configmap/tomato created
deployment.apps/tomato created
4. kubectl delete [resource] [name]
[resource].[name]を削除するためのコマンド。
例えばPodを指定した場合は、古いPodが削除される。
この時、該当するdeploymentのreplicas(もしくはHorizontalPodAutoscalerのminReplicas)の指定数を下回る場合は、新しいPodがオギャーする。
$ kubectl delete pod tomato-45c8b9c54b-ghcxh
pod "tomato-45c8b9c54b-ghcxh" deleted
Podにlabelをつけている場合は、下記の方法で複数のPodを一括で削除することもできる。
$ kubectl delete pod -l app=tomato
pod "tomato-45c8b9c54b-ghcxh" deleted
pod "tomato-45c8b9c54b-t6gkt" deleted
...
ただし、このコマンドでPodの再起動を行う際は注意が必要。
というのも、例えばapp=tomatoのPodを一括で削除した場合、新しいPodができるまでの間、一時的にapp=tomatoのPodが存在しなくなり、サービスダウンしてしまう。
kind=deploymentのyamlを読ませることで、勝手にローリングアップデートしてくれるため、そちらを推奨する。
5. kubectl edit [resource] [name]
直接yaml定義を編集するコマンド。
何をどう変えたかわからなくなるため、本当にちょっとしたデバック以外には使用してはいけないコマンド。
そう、冪等性の敵。
$ kubectl edit deployment tomato
viが開く
6. kubectl exec -it [pod_name] -- [command]
Pod内で[command]を打つコマンド。
例えばPodにちゃんとconfigのファイルが展開されているかとか、そもそもlistenしているかなどをデバックする時によく利用します。
ちなみに[command]の部分を/bin/bashもしくは/bin/sh等にすることによって、Podにログインして操作できるようになります。
ただしPodに直接変更したものは、Podが再起動されると変更前の値に戻るので、完全にデバック用と割り切りましょう。
$ kubectl exec -it tomato-45c8b9c54b-ghcxh -- cat /bin/tomato
tomato
oi
shii
Podに直ログイン
$ kubectl exec -it tomato-45c8b9c54b-ghcxh -- /bin/bash
/opt/tomato #
7.kubectl logs [pod_name]
CrashLoopBackOff等が起こってPodが起動しない場合には、まずこのコマンドで見てあげましょう。
標準/エラー入出力的なログが得られます。
ingressであればアクセスログ的なものが見れます。
$ kubectl logs tomato-45c8b9c54b-ghcxh
なんかlogが出る
出力が多いので、lessやtailやgrepなどでよしなにパイプしてあげると良いとおもいます。
8.kubectl get event | grep [pod_name]
eventの一覧を取得します。
$ kubectl get event | grep tomato-45c8b9c54b-ghcxh
なんかlogが出る
これまた出力が多いので、grep的なものをしないと地獄をみます。
前述のlogsと合わせれば、Podが動いていない理由は概ねわかるんじゃないでしょうかね。たぶん。
わからない場合は...頑張ってください。応援してます！！
ではまた🙋♂️
さいごに
ZEROBILLBANKでは一緒に働く仲間を募集中です。
なんとかjsとか、ブロックチェーンとか、kubernetesとかでいろんなAPIを作るお仕事。
今のところエンジニアは5人くらい。スタートアップだけど、結構ホワイトで働きやすいです。