はじめに
こんにちは WESEEK でわりと何でもやっている haruhikonyan です。
今やデファクトとなりつつある kubernetes(以下k8s) ですが読者の皆様は k8s のオペレーションをする際のコンテキスト切り替えにはどういったものを使っていますでしょうか。
以下のようなものがあると思います。
- デフォルトの
kubectl config use-context
- 割と使っている人が多そうな kubectx
- そして今回紹介する kubie を入れて
kubie ctx
- すでにこれを使ってる人にはこの記事は必要ないかも
もちろん他にも選択肢はあるかと思います。
コンテキスト切り替えと言えば、本番とステージングやテスト、開発でコンテキストを分けて運用をしているシステムは多くあるのかなと思います。
その中でステージングとかの設定を変更する際に、現状の本番の設定を確認するためにコンテキストを一時的に切り替えて設定を確認した後、またステージングにコンテキストを戻して作業を続けるという経験あるのではないでしょうか。
コンテキスト切り替えで事故が起きた
- ある日とある k8s エンジニア(自分ではない)がステージング環境で時間のかかる処理を実行していた。待ち時間に別コンソールで本番の設定を確認するために本番にコンテキストを切り替えたところ、ステージングへ実行中のコマンドのコンテキストが本番に向いてしまい、本番に対してコマンドを実行してしまった。。。
皆様もこんな感じに実際にやらかしてしまったり、ヒヤリハットが起きたことあるんじゃないでしょうか。
そんな一歩間違えれば取り返しのつかないことになりうるミスを少しでも防止できるかもしれない kubie ctx
というコンテキスト切り替えコマンドの紹介です。
kubie ctx のうれしいところ
kubie ctx
はシェルの環境変数を使って切り替えるので別コンソールでコンテキストを変更した場合別のコンソールには伝搬しない- 別ターミナルでコンテキストを本番に変更してデータ見たりしてももともと作業してるターミナルには影響がない
- コマンドを実行するターミナルさえ間違わなければ予期せず別コンテキストに対してコマンドを実行することは無い
kubectl config use-context
やkubectx
は .config 内に値を直接書き込み変更するので別ターミナルを開いて作業をしていた場合でも切り替えが伝搬してしまう
- 別ターミナルでコンテキストを本番に変更してデータ見たりしてももともと作業してるターミナルには影響がない
kubie ctx
を実行したコンテキスト以外の設定が見えない状態になるので、kubeclt --context
や helmfile の context を指定してある状態など、うっかり別コンテキストへのコマンドを実行してしまったとしても安心- この状態で
kubectx
を実行した場合はkubie ctx
で切り替えたコンテキストしか表示がされないので上からコンテキストの変更が不可能
- この状態で
kubie ctx のインストール方法
- 公式 に書かれている通りにインストールを行えば何ら難しくなくコマンドを利用できるようになります
終わりに
- やらかすとまじやばいことになりうるので
kubie ctx
使ってリスクを減らそう!