はじめに
コンテキスト事故、怖いですよねぇ...。
開発環境だと思って kubectl を叩いたが実は本番環境で冷や汗をかいた、なんて経験Kubernetesユーザーなら一度はあるのではないでしょうか。コマンドが読み取り系であればまだ良いのですが、書き込み系（apply delete など) だとしたら目も当てられません。
「Kubie」を使えば、このリスクを大幅に減らせます。
コンテキスト事故の発生する理由
まずコンテキスト事故の発生理由を考えてみたいと思います。
代表的なものとして次のようなものが考えられます。
①シェル間でコンテキストが共有されてしまう
通常、現在のコンテキスト情報はファイル (~/.kube/config)に保存されており、 kubectl コマンドの実行の度に参照されます。そのため、あるシェルで切り替えたコンテキストが別のシェルでの kubectl の実行にも即座に反映されてしまいます。
複数のシェルを起動してそれぞれ別の環境を操作していたつもりが...。私も初心者の頃やりました。
②シェル起動時にコンテキストが設定されている
これもコンテキスト情報がファイルに保存されているために発生します。
本番環境で作業をした次の日の朝、新しいシェルで何の気なしに kubectl を叩いたら実は本番環境につながっていた、みたいな状況が起こります。
③現在のコンテキストを気軽に確認できない
kubectlをインストールしただけの環境では kubectl config get-contexts コマンドを叩かなければコンテキストを確認できません。そのため、思っていたものではないコンテキストで作業をしていた、ということが起こり得ます。
Kubieを導入することで、これらの状況を回避することができます。
Kubieとそのメリット
Kubieはkubectlのコンテキストの切り替えを支援してくれるツールです。
導入方法は上記公式リポジトリのドキュメントに譲ります。Homebrewでも入りますし、ワンバイナリなので手動インストールでも簡単です。
導入し kubie ctx を実行すると、対話形式でコンテキストを選択できるようになります。
Kubieの一番の特徴として、コンテキストごとに独立したシェルが起動する という点があります。コンテキスト情報はシェル間で共有されることはありません。また、コンテキスト情報はそのシェル内でのみ保持され、シェルを終了すると破棄されます
このため、前述①のシェル間でコンテキストの共有と、②の起動時のコンテキストの問題を解消できます。
またKubieが起動するシェルのプロンプトにはコンテキスト名が表示されます。③のコンテキストが気軽に確認できない問題も解決です。ちなみにプロンプトはコンフィグでカスタマイズすることも可能です。
終わりに
簡単な紹介記事にはなりましたが、Kubieによってコンテキスト切り替え事故のリスクを大きく減らせることがご理解いただけたのではないでしょうか。
今回はコンテキスト切り替えについて重点的に話をしましたが、Kubieには他にも便利な機能があります。kubeconfigファイルをディレクトリ指定で複数読み込めたり、コンテキスト切り替えにフックしてコマンドを実行することも可能です。
Kubieを導入し、安全で快適なKubernetesライフを送りましょう！