はじめに
Kubernetes2 Advent Calendar 2017 - Qiita 1 日目です。
Kubernetes 上で動かすアプリを作ることが多くなってきていると思いますが、従来のオペレーションとは違う方法で開発やデプロイなどを行う必要があります。
Kubernetes の実行環境として GKE を例に取ると、GCP プロジェクトやその中で作った GKE クラスタ、Kubernetes ネームスペースなど、見る必要のある領域が増えるとともに今までのやり方も変わるはずです。
本記事ではその際のユースケースと、それをいい感じにしてくれるツールを紹介します。
今いるクラスタは何か
本番環境と開発環境 (Prod / Dev) でクラスタを分けることは多いと思います。
その他にもクラスタを持っていることもあるでしょう。
Continuous Delivery のプラットフォームとして Spinnaker が注目されつつあるので、Kubernetes クラスタへのデプロイはこれに置き換わる可能性はありますが、Spinnaker がサポートしていない Kubernetes リソース (例えば、PodDisruptionBudget など) については、まだ手動で kubectl apply せざるを得ません。
また、基本的なリソースに対する apply 相当のことが Spinnaker によってできるようになったとはいえ、まだまだ手動で apply を実行したい場面もあります。
そこで気をつけたいのは、今いるクラスタとネームスペースの確認です。
Spinnaker は「デプロイ先のクラスタ」と「どのイメージを撒くか (manifest file)」をセットにして内部に持っているので「意図しないクラスタに対して意図しない manifest file をデプロイしてしまう」といった誤操作は防げるのですが、これが kubectl apply による手動だと今いるクラスタと -f に渡すファイル次第で、互い違いにデプロイしてしまうなどの事故も起こしかねません。
毎回指差し確認するのも面倒ですし、そもそも確認を徹底するというのは有効打ではないので、常に見えるところに表示しておくのがおすすめです。
手前味噌ですが、現在の Kubernetes クラスタと GCP プロジェクトを表示できるコマンドを書きました。
$ ./kubeabc/cli/kube-context/kube-context
gke_tellme-tokyo/default
クラスタ名/ネームスペース名 になっています。今は長さの関係でリージョン以降は丸めています。
GCP プロジェクトも同じように表示できます。
$ ./kubeabc/cli/gcp-context/gcp-context
gcalcli-1327
普段は tmux を使っているので、ステータスバーに表示してあります。
set-option -g status-left 'tmux:[#P] #[fg=colour33](K) #(~/bin/kube-context)#[default] #[fg=colour1](G) #(~/bin/gcp-context 2>&1)#[default]'
シェルのプロンプトに表示できるプラグインも公開されています。
とはいえ、常に見えるところに表示しておく、というのもあまり効果的でもないので、apply するときに ask してくるようにしました (後述)。
クラスタ切り替え
Dev / Prod のスイッチなど一日に何回もします。
そのたびに gcloud container clusters get-credentials ~ といった長いコマンドは打っていられません。
kubectx というコンテキストの切り替えに特化した便利ツールがあるので、これを利用すると良いです。
個人的には fzf/peco を噛ませたラッパーを使うようにしました: https://github.com/b4b4r07/kubeabc/blob/master/cli/kubectx
ネームスペース切り替え
クラスタよりも切り替えることの多いのがネームスペースです。
ネームスペースはサービスごとに切ることが多いと思います。
複数のサービスを見ていると kubectl get -n ネームスペース ... とネームスペースを指定して実行するのが面倒になってくるので、先にデフォルトのネームスペースを切り替えておくとよいです。
ちなみに指定しない場合はデフォルトで default のネームスペースが使用されます。
これも、kubectx と同じく kubens というネームスペースの切り替えに特化した便利ツールがあるので、これを利用すると良いです。
また、これも fzf/peco を噛ませたラッパーを使うようにしました: https://github.com/b4b4r07/kubeabc/blob/master/cli/kubens
ログを見やすくする
kubectl logs でログは見れますが、Pod 単位ではなく、Service 単位であったり Namespace 単位で見たい場合が多いでしょう。
そんなときは以下のツールを試すと良いです。
こんな感じに、ゆるく指定することができるので wiki に関する Pod のログをまとめてみることができます。
詳しくは: kubernetes使いは全員 stern を導入すべき – Daisuke Maki – Medium
Pod などのリソースに手早くアクセス
kubectl exec -it xxx-service-dev-v185-qjkh6 bash とか長くて打てません。
kubectl get pods して Pod 名をコピペすることになると思いますが、頻繁にやっているとシンドイです。
こんなときは、Global alias を使うと便利です (zsh ユーザに限られます)。
$ kubectl exec -it P bash
キャピタルの P は kubectl get pods | fzf に展開して実行されるので、インタラクティブに Pod を選んで exec に渡すことができます。
$ kubectl get P
$ kubectl logs -f P
Pod 以外にもいろいろなリソースに対して Gloabl alias を設定しておくことで、短縮して実行することができるようになります。
詳しくは次のリンクを見てください。
https://github.com/b4b4r07/kubeabc/blob/master/scripts/alias.zsh
kubectl に関する alias についての Tips がまとまっていたのですが、個人的にこのたぐいは覚えられないので Global alias だけを使っています。
対話的にコマンド打ち込む
本番環境などに対して kubectl コマンドを大量に打ち込むことはないですが、例えば自分が立てた Kubernetes クラスタなどに対して、試験的に動作確認したりする際に便利でした。
kube 系のコマンドをまとめる
https://github.com/b4b4r07/kubeabc/blob/master/cli/kube
kubectx などもそうですが、kube*、kube-* 系の Third party コマンドやエイリアスができてくると、kubectl 系のコマンドと統一したくなります (git のサブコマンドと同じメカニズムで)。
例えば kubeql、kube-shell といったコマンドの名前の差異をいい感じに吸収して、kubectl のサブコマンドの一つとしてまとめて実行できるので便利です。
内部はほとんど kubectl のラッパーとして書いています。
また、これも git と同じように、サブコマンドやリソースのタイポを直して実行してくれるようになっています (地味に便利)。
前述したように、クラスタを表示しておくというのも確認の延長線にすぎないので、apply などの前に「このクラスタに実行しますよ」という旨を表示します。
まとめ
個人的に便利なツールを紹介しました。
EKS も発表されたことですし、ガンガン Kubernetes を利用していきましょう。