Kubernetes の開発環境や周辺ツールについて、Google Cloud のエンジニアである Megan O'Keefe さん (@askmeegs) による記事 "A Kubernetes Development Workflow for MacOS 💻" が非常に参考になったので和訳しました（公開にあたっては著者の許可をいただいています）。

💻 MacOS での Kubernetes 開発ワークフロー

Kubernetes 開発というのは「フリーサイズの服」ではありません。ローカルマシン上の Minikube で Kubernetes を勉強中という人もいれば、たくさんのクラスタを持つ大規模組織で働いている人もいるでしょう。クラスタはオンプレミスの実験環境かもしれませんし、クラウド上に構築されているかもしれません。

しかし、クラスタのポリシー管理をしているオペレータであれ、新規サービスをテストしているアプリケーション開発者であれ、あるいは Kubeflow を動かしているデータサイエンティストであっても、おそらくは「クラスタに接続する」、「その状態を調べる」、「リソースを作成する」、「そのリソースをデバッグする」といったことのどれかは（あるいは全部を）行っていると思います。

Kubernetes のデベロッパーリレーションズエンジニアとして、私はたくさんのデモコードやサンプル、サンドボックス用クラスタを使っています。となるとこれは把握するだけでもおもしろい（読み方:「完全なカオス」）ことにもなりかねません。そこで、この記事では私の Kubernetes ライフを快適にしてくれるツールたちをお見せしたいと思います。

この環境はどんなスタイルで Kubernetes を使っている人にとっても役に立つはずです。そして、これらのツールはすべてオープンソースコミュニティの驚異的な力のおかげで生まれたものです。

💻 ターミナル

私は iTerm2 を palenight カラースキーマで使っています。そして zsh と oh_my_zsh をデフォルトの robby-russell テーマにして使っています。

このテーマには基本的な Git サポートが付いていますが、同時にミニマルでもあります。もし現在の Kubernetes コンテキストをシェルのプロンプトに表示してみたいと思う人は、 kube-ps1 や spaceship プロンプトについて調べてみてください。

そして、重要なのは ~/.zshrc ファイルの中に次の行を入れておくことです:

source <(kubectl completion zsh)

これによって kubectl コマンドのタブ補完が可能になります。これでもうポッド名のコピペは不要です！

🛶 クラスタ間の移動

どんな日でも私は３つのクラスタを使い分けています。みなさんも同様かもしれませんね！みなさんはいつも kubeconfig を開くのが面倒ではないですか？私もそうです！そこで朗報です。その用途にぴったりな kubectx というものがあります:

kubectx を使うと、複数クラスタのコンテキストの間を簡単に移動することができます。私のお気に入りは kubectx - を実行すれば１つ前に使っていたクラスタに戻れることです。

⚡️ パワーアップした kubectl

それではクラスタにたどり着くことができたので、作業にとりかかりましょう。

みなさんは kubectl にはフラグがたくさん付いてとても長いコマンドになってしまうと感じたことがあるかもしれません。私は kubectl のタブ補完とエイリアス（コマンドのショートカット）集を組み合わせるのがとても便利だと思います。

こちらに kubectl エイリアスの素晴らしいまとめがあります。これを使うと例えば


のようなことができます。

最後に、私は kubectl のプラグインをいくつか入れています。しかし手動でこれをセットアップするのは面倒のもとです。そこで私は krew というオープンソースの kubectl 用プラグインマネージャを使っています:

krew で kubectl プラグインの検索とインストールを行えば、カスタムコマンドが使えるようになります。

📜 yaml の取り扱い

それではクラスタの準備が整いましたので、何かデプロイしてみましょう。

Kubernetes で開発を行うということはつまり、たくさんの YAML ファイルを書いて、管理して、更新して、デプロイするということです。私は自分の YAML ファイルをすべて Git で保存するようにしています。

（ローカルにファイルを保存しておくのではなく） GitOps を早めに取り入れることで、初めのうちにデバッグしていたころのリビジョン履歴がわかるようになり、後でアプリケーションのパイプライン (例: GitHub webhook による CI/CD パイプライン) を整えたくなったときに上手くいくよう備えておくことができます。

私はテキストエディタとして VSCode を Moonlight テーマで使っています。
そして、VSCode には元から素晴らしい機能がたくさんあるのですが、Red Hat の YAML Support プラグインを入れるとバリデーション・オートコンプリート・フォーマットができるようになってとても便利になります。

いまのところ、私が Kubernetes の YAML ファイルを書くときのプロセスは完全に手動です。しかし、普段プロジェクトを新規作成するとき、私はいつも同じ Kubernetes スペック - ConfigMap, Secret, Volume, Deployment, Service - を書いています。

私はこのプロセスを効率化する方法をいろいろと調べているところです。テキストエディタの拡張機能や、テンプレートエンジンや、その他のツールなど種類を問わずです。もしみなさんが YAML を書いたり管理したりするのに使っているツールがあれば、下でコメントしてください！⬇

✨ デプロイ

YAML ファイルができたので、これでリソースをデプロイできるようになりました！パワーアップした kubectl 環境を手に入れたので、手動でデプロイする誘惑にかられそうなところです。

しかしこれは危ない橋で、そうすると docker build, docker push, kubectl apply, kubectl delete pod などの同じコマンドを何度も繰り返す羽目になってしまいます。これは嫌です。

skaffold というツールでこの辛い作業を自動化することができます。skaffold は魔法のようです: skaffold はコードベースの変化を監視します。ローカルで変更が保存されると、skaffold は自動的に Docker イメージをビルドし、イメージを新規タグでプッシュし、クラスタへの再デプロイを行います。

skaffold の本当にクールなところの１つがイメージタグの自動生成です。このおかげで実際の YAML ファイルにはイメージのタグではなくリポジトリだけを書いておけば、skaffold がデプロイ時に新しいタグを埋め込んでくれます。

spec:
  containers:
  - name: helloworld
    image:  gcr.io/megangcp/helloworld
    imagePullPolicy: Always
   ports:
     - containerPort: 8080

skaffold のために唯一必要なのは (やはり YAML の) 構成ファイルです:

apiVersion: skaffold/v1beta3
kind: Config
build:
  artifacts:
  - image: gcr.io/megangcp/helloworld
deploy:
  kubectl:
    manifests:
      - kubernetes/*

この例は最小限の構成になっており、この中でイメージのリポジトリを指定しています（この場合は Google Container Registry にありますが、 DockerHub など他のレジストリでも同様に使えます）。またマニストファイルが置いてあるディレクトリもこの中で指定しています。

skaffold は非常にカスタマイズ性が高く、kubectl のほか Helm などのデプロイツールと一緒に使うことができます。

🐳 Docker イメージの調査

skaffold は Docker のビルドプロセスを抽象化してくれますが、新規にビルドされたイメージを詳しく調べたくなることもあります。例えば、イメージのサイズは前のバージョンに比べてどうか？とか、各イメージレイヤに含まれる内容はどうなっているか？といったことについてです。

dive は Docker イメージの調査に使える強力なツールです。

dive を使えば、異なるレイヤーの間でのファイルシステムの違いを調べることができます。これは Docker ビルドがどこかで失敗しているときにとても役に立ちます。

😱 デバッグ

Kubernetes 上でポッドを動作させるところまで来ました。次にやることは何でしょうか？

スペック指定やアプリケーションのコードの中で、時折（読み方:「いつも」）何かが間違っていることがあります。

私が普段 Kubernetes のデバッグをするときの流れはこんな感じです:

ポッドを表示します （エイリアスは kdpo ）。スペックが間違っている？（例: デプロイメントでマウントしようとしてるシークレットが誤って別の名前空間になっている？）そうでなければ...
ポッドのログを取得します。 skaffold dev コマンドを使うとすべてのデプロイ中のコンテナログを結合して標準出力に流すことができます。しかしポッドが２つ以上あるとき、このログフォーマットは鬱陶しい感じがします。また同様に、通常の kubectl logs コマンドでも永遠にポッド名のコピペを繰り返すことになります。

その代わりに、ログをカスタマイズして tail できる強力な手段が stern です。stern はポッドを選ぶのに正規表現を使います — そしてポッドの名前はすべてデプロイメント名で始まるので、正確なポッド名を知らなくても、あるデプロイメントに含まれるすべてのポッドのログを追うことができます。これはめちゃくちゃ便利です: ログを見ても何が悪いのか手ががりがつかめなかったら、たいてい私は...
ポッド内で Exec します （エイリアス kex とタブ補完を組み合わせます）:

おわりに

Kubernetes は大規模な設定構造を持つ大きく複雑なソフトウェア構成物です。さまざまな k8s 利用歴の方がいらっしゃると思いますが、どなたにとってもこのツール共有が多少のお役に立てば嬉しく思います。

この記事で紹介したツールやプラグインの一覧はこちらです:

✨ お読みいただきありがとうございました！ ✨

（謝辞: Ahmet Alp Balkan に感謝します）