kubectl をより効果的に使用する方法: 詳細ガイド

Kubernetes を使用している場合、kubectl はおそらく最もよく使用するユーティリティの XNUMX つです。 特定のツールの使用に多くの時間を費やす場合は、そのツールをよく研究し、効果的な使用方法を学ぶことが重要です。

チーム Mail.ru の Kubernetes aaS Daniel Weibel による記事を翻訳しました。この記事では、kubectl を効果的に使用するためのヒントとコツが説明されています。 また、Kubernetes をより深く理解するのにも役立ちます。

著者によると、この記事の目標は、Kubernetes を使用した日常の作業を効率化するだけでなく、より楽しくすることです。

はじめに: kubectl とは何ですか

kubectl をより効果的に使用する方法を学ぶ前に、kubectl が何であり、どのように機能するかについて基本的な理解を得る必要があります。

ユーザーの観点から見ると、kubectl は Kubernetes 操作を実行できるコントロール パネルです。

技術的に言えば、kubectl は Kubernetes API クライアントです。

Kubernetes API は HTTP REST API です。 この API は真の Kubernetes ユーザー インターフェイスであり、これを通じて完全に制御されます。 これは、すべての Kubernetes オペレーションが API エンドポイントとして公開され、そのエンドポイントへの HTTP リクエストを使用して実行できることを意味します。

したがって、kubectl の主な仕事は、Kubernetes API に対して HTTP リクエストを行うことです。

Kubernetes は完全にリソース指向のシステムです。 これは、リソースの内部状態が維持され、すべての Kubernetes 操作が CRUD 操作であることを意味します。

これらのリソースを管理することで Kubernetes を完全に制御でき、Kubernetes はリソースの現在の状態に基づいて何をすべきかを判断します。 このため、Kubernetes API リファレンスは、リソース タイプとそれに関連する操作のリストとして構成されています。

例を見てみましょう.

ReplicaSet リソースを作成するとします。 これを行うには、ReplicaSet を名前でファイルに記述します。 replicaset.yaml、次にコマンドを実行します。

$ kubectl create -f replicaset.yaml

これにより、ReplicaSet リソースが作成されます。 しかし、舞台裏では何が起こっているのでしょうか?

Kubernetes には ReplicaSet 作成操作があります。 他の操作と同様に、これは API エンドポイントとして公開されます。 この操作の特定の API エンドポイントは次のようになります。

POST /apis/apps/v1/namespaces/{namespace}/replicasets

すべての Kubernetes 操作の API エンドポイントは、次の場所にあります。 APIリファレンス （含む 上記のエンドポイント）。 エンドポイントに実際のリクエストを行うには、まず API リファレンスにリストされているエンドポイント パスに API サーバー URL を追加する必要があります。

したがって、上記のコマンドを実行すると、kubectl は HTTP POST リクエストを上記の API エンドポイントに送信します。 ファイル内で指定した ReplicaSet 定義 replicaset.yaml、リクエストの本文で送信されます。

これは、Kubernetes クラスターと対話するすべてのコマンドに対して kubectl がどのように機能するかです。 これらのすべてのケースにおいて、kubectl は適切な Kubernetes API エンドポイントに対して HTTP リクエストを行うだけです。

次のようなユーティリティを使用して Kubernetes を完全に管理できることに注意してください。 curlHTTP リクエストを手動で Kubernetes API に送信します。 Kubectl は単に Kubernetes API の使用を容易にするだけです。

これは、kubectl とは何か、そしてそれがどのように機能するかの基本です。 ただし、Kubernetes API については、すべての kubectl ユーザーが知っておくべきことが他にもあります。 Kubernetes の内部世界を簡単に見てみましょう。

Kubernetes の内部世界

Kubernetes は、クラスター ノード上で個別のプロセスとして実行される一連の独立したコンポーネントで構成されます。 一部のコンポーネントはマスター ノードで実行され、その他のコンポーネントはワーカー ノードで実行され、各コンポーネントは独自の特定のタスクを実行します。

メイン ノードの最も重要なコンポーネントは次のとおりです。

1. 倉庫 - リソース定義を保存します (通常はetcdです).
2. APIサーバー — API を提供し、ストレージを管理します。
3. コントローラーマネージャー — リソースのステータスが仕様に準拠していることを確認します。
4. プラハ — ワーカーノード上のポッドをスケジュールします。

そして、ワーカー ノード上の最も重要なコンポーネントの XNUMX つを次に示します。

1. クベレット — 作業ノードでのコンテナの起動を管理します。

これらのコンポーネントがどのように連携して機能するかを理解するために、例を見てみましょう。

完了したばかりだと仮定しましょう kubectl create -f replicaset.yaml、その後、kubectl が HTTP POST リクエストを行った ReplicaSet API エンドポイント (ReplicaSet リソース定義を渡します)。

クラスター内で何が起こっているのでしょうか?

1. した後 kubectl create -f replicaset.yaml API サーバーは、ReplicaSet リソース定義をストレージに保存します。

   

2. 次に、ReplicaSet コントローラーがコントローラー マネージャーで起動され、ReplicaSet リソースの作成、変更、削除が処理されます。

   

3. ReplicaSet コントローラーは、(ReplicaSet 定義のポッド テンプレートに従って) 各 ReplicaSet レプリカのポッド定義を作成し、ストレージに保存します。

   

4. スケジューラが起動され、まだワーカー ノードに割り当てられていないポッドを追跡します。

   

5. スケジューラーは各ポッドに適切なワーカー ノードを選択し、この情報をストアのポッド定義に追加します。

   

6. ポッドが割り当てられているワーカー ノードで Kubelet が起動され、このノードに割り当てられたポッドを追跡します。

   

7. Kubelet はストレージからポッド定義を読み取り、Docker などのコンテナー ランタイムにノード上でコンテナーを起動するように指示します。

   

以下はこの説明のテキスト版です。

ReplicaSet 作成エンドポイントへの API リクエストは API サーバーによって処理されます。 API サーバーはリクエストを認証し、ReplicaSet リソース定義をストレージに保存します。

このイベントは、コントローラー マネージャーのサブプロセスである ReplicaSet コントローラーを開始します。 ReplicaSet コントローラーは、ストア内の ReplicaSet リソースの作成、更新、削除を監視し、これが発生するとイベント通知を受け取ります。

ReplicaSet コントローラーの仕事は、必要な数の ReplicaSet ポッドが存在することを確認することです。 この例では、まだポッドが存在しないため、ReplicaSet コントローラーはこれらのポッド定義を (ReplicaSet 定義のポッド テンプレートに従って) 作成し、ストレージに保存します。

新しいポッドの作成は、ワーカー ノードに対してまだスケジュールされていないポッド定義を追跡するスケジューラーによってトリガーされます。 スケジューラは、各ポッドに適切なワーカー ノードを選択し、リポジトリ内のポッド定義を更新します。

この時点まで、クラスター内のどこにもワークロード コードが実行されていなかったことに注意してください。 これまでに行われたすべてのこと - これは、マスター ノード上のリポジトリ内のリソースの作成と更新です。

最後のイベントは Kubelet をトリガーし、ワーカー ノードにスケジュールされたポッドを監視します。 ReplicaSet ポッドがインストールされているワーカー ノードの Kubelet は、Docker などのコンテナ ランタイムに、必要なコンテナ イメージをダウンロードして実行するように指示する必要があります。

この時点で、ReplicaSet アプリケーションがついに実行されます。

Kubernetes API の役割

前の例で見たように、Kubernetes コンポーネント (API サーバーとストレージを除く) は、ストレージ内のリソースへの変更を監視し、ストレージ内のリソースに関する情報を変更します。

もちろん、これらのコンポーネントはストレージと直接やり取りするのではなく、Kubernetes API を通じてのみやり取りします。

次の例を考えてみましょう:

1. ReplicaSet コントローラーは API エンドポイントを使用します ReplicaSet のリストを表示する パラメータ付き watch ReplicaSet リソースへの変更を監視します。
2. ReplicaSet コントローラーは API エンドポイントを使用します ポッドを作成する (ポッドの作成) ポッドを作成します。
3. スケジューラは API エンドポイントを使用します パッチポッド (ポッドの編集) は、選択したワーカー ノードに関する情報でポッドを更新します。

ご覧のとおり、これは kubectl がアクセスする API と同じです。 内部コンポーネントと外部ユーザーに同じ API を使用することは、Kubernetes 設計の基本的な概念です。

ここで、Kubernetes がどのように機能するかを要約できます。

1. ストレージには状態、つまり Kubernetes リソースが保存されます。
2. API サーバーは、Kubernetes API の形式でストレージへのインターフェイスを提供します。
3. 他のすべての Kubernetes コンポーネントとユーザーは、API を通じて Kubernetes 状態 (リソース) を読み取り、観察し、操作します。

これらの概念を理解すると、kubectl をより深く理解し、最大限に活用できるようになります。

次に、kubectl を使用して生産性を向上させるのに役立ついくつかの具体的なヒントとコツを見てみましょう。

1. コマンド補完による入力の高速化

kubectl でパフォーマンスを向上させるための最も便利ですが、見落とされがちなテクニックの XNUMX つは、コマンド補完です。

コマンド補完を使用すると、Tab キーを使用して kubectl コマンドの一部を自動的に補完できます。 これは、リソース名のような複雑なものを含む、サブコマンド、オプション、引数に対して機能します。

kubectl コマンド補完がどのように機能するかを確認してください。

コマンド補完は Bash シェルと Zsh シェルで機能します。

公式ガイド オートコンプリートを設定するための詳細な手順が記載されていますが、以下に短い抜粋を示します。

コマンド補完の仕組み

コマンド補完は、補完スクリプトを使用して動作するシェル機能です。 拡張スクリプトは、特定のコマンドの拡張の動作を定義するシェル スクリプトです。

Kubectl は、次のコマンドを使用して、Bash および Zsh の拡張スクリプトを自動的に生成し、出力します。

$ kubectl completion bash

Или：

$ kubectl completion zsh

理論的には、kubectl がコマンドを補完できるように、これらのコマンドの出力を適切なコマンド シェルに接続するだけで十分です。

実際には、Bash (Linux と MacOS の違いも含む) と Zsh では接続方法が異なります。 以下では、これらすべてのオプションを見ていきます。

Linux 上のバッシュ

Bash 完了スクリプトは bash-completion パッケージに依存しているため、最初にそれをインストールする必要があります。

$ sudo apt-get install bash-completion

Или：

$ yum install bash-completion

次のコマンドを使用して、パッケージが正常にインストールされたことをテストできます。

$ type _init_completion

これによりシェル関数コードが出力された場合は、bash-completion が正しくインストールされています。 コマンドで「見つかりません」エラーが発生した場合は、次の行をファイルに追加する必要があります。 ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

この行をファイルに追加する必要がありますか? ~ / .bashrc かどうかは、bash-completion のインストールに使用したパッケージ マネージャーによって異なります。 これは APT には必要ですが、YUM には必要ありません。

bash-completion をインストールした後、kubectl 補完スクリプトがすべてのシェル セッションで有効になるようにすべてを構成する必要があります。

これを行う XNUMX つの方法は、次の行をファイルに追加することです。 ~ / .bashrc:

source <(kubectl completion bash)

別の方法は、kubectl 拡張スクリプトをディレクトリに追加することです。 /etc/bash_completion.d (存在しない場合は作成します):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

カタログ内のすべてのアドオン スクリプト /etc/bash_completion.d bash-completion に自動的に含まれます。

どちらのオプションも同様に適用できます。

シェルを再起動すると、kubectl コマンド補完が機能するようになります。

MacOS 上の Bash

MacOS では、セットアップは少し複雑です。 実際、MacOS はデフォルトで Bash バージョン 3.2 を使用しており、kubectl オートコンプリート スクリプトには少なくとも 4.1 の Bash バージョンが必要であり、Bash 3.2 では機能しません。

MacOS で古いバージョンの Bash を使用すると、ライセンスの問題が発生します。 Bash バージョン 4 は GPLv3 に基づいてライセンスされており、Apple ではサポートされていません。

MacOS で kubectl オートコンプリートを構成するには、より新しいバージョンの Bash をインストールする必要があります。 更新された Bash をデフォルトのシェルとして設定することもできます。これにより、将来多くの問題が回避されます。 難しいことではありません。詳細は記事に記載されています。MacOS での Bash の更新'。

続行する前に、最新バージョンの Bash を使用していることを確認してください (出力を確認してください) bash --version).

Bash 補完スクリプトはプロジェクトによって異なります bash-補完, そのため、最初にインストールする必要があります。

次を使用して bash-completion をインストールできます 自作:

$ brew install bash-completion@2

それは @2 bash-completion バージョン 2 を表します。kubectl オートコンプリートには bash-completion v2 が必要で、bash-completion v2 には少なくとも Bash バージョン 4.1 が必要です。

コマンド出力 brew-install ファイルに追加する必要があるものを指定する警告セクションが含まれています ~/.bash_profile:

export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . 
"/usr/local/etc/profile.d/bash_completion.sh"

ただし、これらの行を追加しないことをお勧めします。 ~/.bash_profileとで ~/.bashrc。 この場合、オートコンプリートはメインのコマンド シェルだけでなく、子コマンド シェルでも使用できます。

コマンド シェルを再起動した後、次のコマンドを使用してインストールが正しいことを確認できます。

$ type _init_completion

出力にシェル関数が表示される場合は、すべてが正しく構成されています。

次に、kubectl オートコンプリートがすべてのセッションで有効になっていることを確認する必要があります。

XNUMX つの方法は、次の行を ~/.bashrc:

source <(kubectl completion bash)

XNUMX 番目の方法は、オートコンプリート スクリプトをフォルダーに追加することです。 /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

この方法は、Homebrew を使用して bash-completion をインストールした場合にのみ機能します。 この場合、bash-completion により、このディレクトリからすべてのスクリプトがロードされます。

インストールした場合 Homebrewを使用したkubectlの場合、オートコンプリート スクリプトが自動的にフォルダーに配置されるため、前の手順を実行する必要はありません。 /usr/local/etc/bash_completion.d インストール中。 この場合、bash-completion をインストールするとすぐに、kubectl オートコンプリートが機能し始めます。

結果として、これらのオプションはすべて同等になります。

Zsh

Zsh のオートコンプリート スクリプトには依存関係は必要ありません。 コマンド シェルをロードするときにそれらを有効にするだけです。

これを行うには、 ~/.zshrc ファイル：

source <(kubectl completion zsh)

エラーが発生した場合 not found: compdef シェルを再起動した後、組み込み関数を有効にする必要があります compdef。 ファイルの先頭に追加することで有効にできます ~/.zshrc 次のとおり

autoload -Uz compinit
compinit

2. リソース仕様を素早く表示する

YAML リソース定義を作成するときは、それらのリソースのフィールドとその意味を理解しておく必要があります。 この情報を探す場所の XNUMX つは API リファレンスです。API リファレンスには、すべてのリソースの完全な仕様が含まれています。

しかし、何かを検索する必要があるたびに Web ブラウザに切り替えるのは不便です。 したがって、kubectlは次のコマンドを提供します kubectl explain、端末内のすべてのリソースの仕様が表示されます。

コマンドの形式は次のとおりです。

$ kubectl explain resource[.field]...

このコマンドは、要求されたリソースまたはフィールドの仕様を出力します。 表示される情報は API マニュアルに記載されている情報と同じです。

Поумолчанию kubectl explain は、フィールドのネストの最初のレベルのみを示しています。

どのように見えるか見てみましょう その後、缶.

オプションを追加するとツリー全体を表示できます --recursive:

$ kubectl explain deployment.spec --recursive

どのリソースが必要なのか正確にわからない場合は、次のコマンドを使用してすべてを表示できます。

$ kubectl api-resources

このコマンドは、リソース名を複数形で表示します。 deployments 代わりに deployment。 短い名前も表示されます。たとえば、 deploy、それを持つリソースの場合。 これらの違いについては心配する必要はありません。 これらの命名オプションはすべて、kubectl と同等です。 つまり、それらのいずれかを使用できます。 kubectl explain.

次のコマンドはすべて同等です。

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. カスタム列出力形式を使用する

デフォルトのコマンド出力形式 kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

この形式は便利ですが、含まれる情報量は限られています。 完全なリソース定義形式と比較して、ここでは少数のフィールドのみが表示されます。

この場合、カスタム列出力形式を使用できます。 これにより、どのデータを出力するかを決定できます。 任意のリソース フィールドを別の列として表示できます。

カスタム形式の使用は、次のオプションを使用して決定します。

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

各出力列をペアとして定義できます。 <header>:<jsonpath>どこ <header> は列名であり、 <jsonpath> — リソースフィールドを定義する式。

簡単な例を見てみましょう。

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

出力には、ポッドの名前を含む XNUMX つの列が含まれます。

オプション式はフィールドからポッド名を選択します。 metadata.name。 これは、ポッドの名前が子名フィールドで定義されているためです。 metadata ポッドのリソースの説明にあります。 詳細については、以下を参照してください。 APIガイド またはコマンドを入力します kubectl explain pod.metadata.name.

ここで、出力に追加の列を追加したいとします。たとえば、各ポッドが実行されているノードを表示したいとします。 これを行うには、適切な列仕様をカスタム列オプションに追加するだけです。

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

式はノード名を次から選択します。 spec.nodeName — ポッドがノードに割り当てられると、その名前がフィールドに書き込まれます。 spec.nodeName ポッドリソースの仕様。 より詳細な情報は出力で確認できます。 kubectl explain pod.spec.nodeName.

Kubernetes リソースフィールドは大文字と小文字が区別されることに注意してください。

任意のリソース フィールドを列として表示できます。 リソース仕様を確認し、任意のフィールドで試してみてください。

その前に、フィールド選択式を詳しく見てみましょう。

JSONパス式

リソースフィールドを選択するための式は、以下に基づいています。 JSONパス.

JSONPath は、JSON ドキュメントからデータを取得するための言語です。 単一フィールドの選択は、JSONPath の最も単純な使用例です。 彼はたくさん持っています 大きな声、セレクター、フィルターなどが含まれます。

Kubectl Explain は、限られた数の JSONPath 機能をサポートします。 それらの使用の可能性と例を以下に説明します。

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

[] 演算子は特に重要です。 Kubernetes リソース フィールドの多くはリストであり、この演算子を使用すると、それらのリストのメンバーを選択できます。 リストのすべての要素を選択するために、[*] などのワイルドカードとともに使用されることがよくあります。

アプリケーション例

出力に任意のフィールドまたはリソース フィールドの組み合わせを表示できるため、カスタム列出力形式を使用する可能性は無限です。 ここではサンプル アプリをいくつか紹介しますが、ご自身で自由に調べて、自分に合ったアプリケーションを見つけてください。

1. ポッドのコンテナー イメージを表示します。

   $ kubectl get pods 
     -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
   
   NAME                        IMAGES
   engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
   web-ui-6db964458-8pdw4      wordpress

   このコマンドは、各ポッドのコンテナー イメージ名を表示します。

   ポッドには複数のコンテナーを含めることができることに注意してください。その場合、イメージ名はカンマで区切られて XNUMX 行に表示されます。

2. ノード アベイラビリティ ゾーンの表示:

   $ kubectl get nodes 
     -o 
   custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'
   
   NAME                          ZONE
   ip-10-0-118-34.ec2.internal   us-east-1b
   ip-10-0-36-80.ec2.internal    us-east-1a
   ip-10-0-80-67.ec2.internal    us-east-1b

   このコマンドは、クラスターがパブリック クラウドでホストされている場合に便利です。 各ノードの可用性ゾーンが表示されます。

   アベイラビリティーゾーンは、レプリケーションゾーンを地理的領域に制限するクラウドの概念です。

   各ノードのアベイラビリティーゾーンは、特別なラベルを通じて取得されます。 failure-domain.beta.kubernetes.io/zone。 クラスターがパブリック クラウドで実行されている場合、このラベルは自動的に作成され、各ノードの可用性ゾーンの名前が入力されます。

   ラベルは Kubernetes リソース仕様の一部ではないため、ラベルに関する情報は次の場所にありません。 APIガイド。 ただし、ノードに関する情報を YAML または JSON 形式でリクエストすると、(他のラベルと同様に) 表示できます。

   $ kubectl get nodes -o yaml
   # или
   $ kubectl get nodes -o json

   これは、リソースの仕様を学ぶだけでなく、リソースについてさらに学ぶための優れた方法です。

4. クラスターと名前空間を簡単に切り替える

kubectl が Kubernetes API にリクエストを行うと、まず kubeconfig ファイルを読み取り、接続に必要なすべてのパラメーターを取得します。

デフォルトでは、kubeconfig ファイルは次のとおりです。 ~/.kube/config。 通常、このファイルは特別なコマンドによって作成または更新されます。

複数のクラスターを操作する場合、kubeconfig ファイルにはそれらすべてのクラスターに接続するための設定が含まれます。 どのクラスターを操作しているかを kubectl コマンドに伝える方法が必要です。

クラスター内では、複数のネームスペース (物理クラスター内の仮想クラスターの一種) を作成できます。 Kubectl は、kubeconfig ファイルに基づいて使用する名前空間も決定します。 これは、kubectl コマンドにどの名前空間を使用するかを指示する方法も必要であることを意味します。

この章では、その仕組みと効果的に機能させる方法について説明します。

KUBECONFIG 環境変数に複数の kubeconfig ファイルがリストされている場合があることに注意してください。 この場合、これらすべてのファイルは実行時に XNUMX つの共通構成に結合されます。 パラメーターを指定して kubectl を実行することで、デフォルトの kubeconfig ファイルを変更することもできます。 --kubeconfig。 見る 公式ドキュメント.

kubeconfig ファイル

kubeconfig ファイルに正確に何が含まれているかを見てみましょう。

ご覧のとおり、kubeconfig ファイルには一連のコンテキストが含まれています。 コンテキストは XNUMX つの要素で構成されます。

• クラスター — クラスターサーバーの API URL。
• ユーザー - クラスター内のユーザー認証資格情報。
• 名前空間 - クラスターに参加するときに使用される名前空間。

実際には、kubeconfig でクラスターごとに XNUMX つのコンテキストを使用することがよくあります。 ただし、ユーザーまたは名前空間ごとに区別して、クラスターごとに複数のコンテキストを持つことができます。 ただし、このマルチコンテキスト構成は一般的ではないため、通常はクラスターとコンテキストの間に XNUMX 対 XNUMX のマッピングが存在します。

常に、コンテキストの XNUMX つが最新です。

kubectl が構成ファイルを読み取るときは、常に現在のコンテキストから情報を取得します。 上記の例では、kubectl は Hare クラスターに接続します。

したがって、別のクラスターに切り替えるには、kubeconfig ファイル内の現在のコンテキストを変更する必要があります。

これで、kubectl が Fox クラスターに接続します。

同じクラスター内の別の名前空間に切り替えるには、現在のコンテキストの名前空間要素の値を変更する必要があります。

上記の例では、kubectl は Fox クラスターの Prod 名前空間を使用します (以前は Test 名前空間が設定されていました)。

kubectl にはオプションも用意されていることに注意してください --cluster, --user, --namespace и --contextこれにより、kubeconfig での設定に関係なく、個々の要素と現在のコンテキスト自体を上書きできます。 見て kubectl options.

理論的には、kubeconfig の設定を手動で変更できます。 でも不便ですよ。 これらの操作を簡素化するために、パラメータを自動的に変更できるさまざまなユーティリティが用意されています。

kubectxを使用する

クラスターと名前空間を切り替えるための非常に人気のあるユーティリティ。

ユーティリティはコマンドを提供します kubectx и kubens 現在のコンテキストと名前空間をそれぞれ変更します。

前述したように、クラスターごとにコンテキストが XNUMX つしかない場合、現在のコンテキストを変更することはクラスターを変更することを意味します。

これらのコマンドの実行例を次に示します。

基本的に、これらのコマンドは、上で説明したように kubeconfig ファイルを編集するだけです。

インストールする kubectxの指示に従います。 Github。

どちらのコマンドもコンテキスト名と名前空間名のオートコンプリートをサポートしているため、それらを完全に入力する必要がなくなります。 オートコンプリートの設定手順 ここで.

もう一つの便利な機能 kubectx です インタラクティブモード。 ユーティリティと連携して動作します fzf、個別にインストールする必要があります。 fzf をインストールすると、自動的に対話モードが利用可能になります。 kubectx。 fzf が提供する対話型の無料検索インターフェイスを介して、コンテキストと名前空間を対話的に選択できます。

シェルエイリアスの使用

kubectl にはそのためのコマンドも用意されているため、現在のコンテキストと名前空間を変更するための別のツールは必要ありません。 はい、チーム kubectl config kubeconfig ファイルを編集するためのサブコマンドを提供します。

ここではそのうちのいくつかは、次のとおりです。

• kubectl config get-contexts: すべてのコンテキストを表示します。
• kubectl config current-context: 現在のコンテキストを取得します。
• kubectl config use-context: 現在のコンテキストを変更します。
• kubectl config set-context: コンテキスト要素を変更します。

ただし、これらのコマンドを直接使用するのは長いため、あまり便利ではありません。 実行が簡単なシェル エイリアスを作成できます。

これらのコマンドに基づいて、kubectx と同様の機能を提供するエイリアスのセットを作成しました。 ここで実際の動作を見ることができます。

エイリアスは fzf を使用して対話型の自由検索インターフェイス (kubectx の対話モードなど) を提供することに注意してください。 これは、必要があることを意味します fzfをインストールするこれらのエイリアスを使用するには。

エイリアス自体の定義は次のとおりです。

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

これらのエイリアスを設定するには、上記の定義をファイルに追加する必要があります ~/.bashrc または ~/.zshrc そしてシェルを再起動します。

プラグインの使用

Kubectl を使用すると、基本コマンドと同じ方法で実行されるプラグインをロードできます。 たとえば、kubectl-foo プラグインをインストールし、次のコマンドを実行して実行できます。 kubectl foo.

この方法でコンテキストと名前空間を変更すると便利です。たとえば、次のように実行します。 kubectl ctx コンテキストを変更し、 kubectl ns ネームスペースを変更します。

これを行う XNUMX つのプラグインを作成しました。

• kubectl-ctx
• kubectl-ns

プラグインの動作は、前のセクションのエイリアスに基づいています。

仕組みは次のとおりです。

プラグインは fzf を使用して、インタラクティブな無料検索インターフェイス (kubectx のインタラクティブ モードなど) を提供することに注意してください。 これは、必要があることを意味します fzfをインストールするこれらのエイリアスを使用するには。

プラグインをインストールするには、次の名前のシェル スクリプトをダウンロードする必要があります。 kubectl-ctx и kubectl-ns PATH 変数内の任意のディレクトリにコピーし、たとえば次のようにして実行可能にします。 chmod +x。 この後すぐに使えるようになります kubectl ctx и kubectl ns.

5. オートエイリアスで入力を減らす

シェル エイリアスは入力を高速化する良い方法です。 プロジェクト kubectl エイリアス 基本的な kubectl コマンドのショートカットが約 800 個含まれています。

800 ものエイリアスをどうやって覚えているのかと疑問に思われるかもしれません。 ただし、これらは以下に示す簡単なスキームに従って構築されているため、すべてを覚える必要はありません。

たとえば、次のように

1. kgpooyaml - kubectl ポッドの oyaml を取得する
2. ksysgsvcw — kubectl -n kube-system get svc w
3. ksysrmcm -kubectl -n kube-system rm cm
4. kgdepallsl - kubectl のデプロイメントをすべて取得します sl

ご覧のとおり、エイリアスはコンポーネントで構成されており、それぞれが kubectl コマンドの特定の要素を表します。 各エイリアスには、基本コマンド、操作、およびリソース用の XNUMX つのコンポーネントと、パラメータ用の複数のコンポーネントを含めることができます。 上の図に従って、これらのコンポーネントを左から右に「実装」するだけです。

現在の詳細な図は次の場所にあります。 GitHubの。 そこでも見つけることができます エイリアスの完全なリスト.

たとえば、エイリアス kgpooyamlall は次のコマンドと同等です。 kubectl get pods -o yaml --all-namespaces.

オプションの相対的な順序は重要ではありません: コマンド kgpooyamlall コマンドと同等です kgpoalloyaml.

すべてのコンポーネントをエイリアスとして使用する必要はありません。 例えば k, kg, klo, ksys, kgpo も使用できます。 さらに、コマンド ラインでエイリアスと通常のコマンドまたはオプションを組み合わせることができます。

たとえば、次のように

1. 代わりに kubectl proxy あなたは書ける k proxy.
2. 代わりに kubectl get roles あなたは書ける kg roles (現在、Roles リソースのエイリアスはありません)。
3. 特定のポッドのデータを取得するには、次のコマンドを使用できます。 kgpo my-pod — kubectl get pod my-pod.

一部のエイリアスにはコマンド ライン引数が必要であることに注意してください。 たとえば、エイリアス kgpol 手段 kubectl get pods -l。 オプション -l 引数 - ラベル指定が必要です。 エイリアスを使用すると次のようになります kgpol app=ui.

一部のエイリアスには引数が必要なため、エイリアス a、f、l を最後に使用する必要があります。

一般に、このスキームを一度理解すると、実行するコマンドからエイリアスを直感的に派生でき、入力時間を大幅に節約できます。

インストール

kubectl-aliases をインストールするには、ファイルをダウンロードする必要があります .kubectl_aliases GitHub から取得してファイルに含めます ~/.bashrc または ~/.zshrc:

source ~/.kubectl_aliases

オートコンプリート

前に述べたように、コマンド ラインでエイリアスに単語を追加することがよくあります。 例えば：

$ kgpooyaml test-pod-d4b77b989

kubectl コマンド補完を使用している場合は、おそらくリソース名などにオートコンプリートを使用したことがあるでしょう。 しかし、エイリアスが使用されている場合にこれを実行できるでしょうか?

オートコンプリートが機能しない場合、エイリアスの利点の一部が失われるため、これは非常に重要な質問です。

答えは、使用しているシェルによって異なります。

1. Zsh の場合、エイリアス補完はすぐに機能します。
2. 残念ながら、Bash の場合、オートコンプリートを機能させるにはいくつかの作業が必要です。

Bash でエイリアスのオートコンプリートを有効にする

Bash の問題は、(たとえば、Zsh のように) エイリアスが参照するコマンドではなく、エイリアスを (Tab キーを押すたびに) 完了しようとすることです。 800 個すべてのエイリアスに対する補完スクリプトがないため、自動補完は機能しません。

プロジェクト 完全なエイリアス は、この問題に対する一般的な解決策を提供します。 これは、エイリアスの補完メカニズムに接続し、内部でエイリアスをコマンドに展開し、完了したコマンドの補完オプションを返します。 これは、エイリアスのパディングが完全なコマンドの場合とまったく同じように動作することを意味します。

以下では、最初に complete-alias をインストールする方法を説明し、次にすべての kubectl エイリアスの補完を有効にするようにそれを構成する方法を説明します。

完全なエイリアスのインストール

まず第一に、完全なエイリアスは次のものに依存します。 bash-補完。 したがって、complete-alias をインストールする前に、bash-completion がインストールされていることを確認する必要があります。 インストール手順は、Linux および MacOS 用に以前に提供されています。

MacOS ユーザーへの重要な注意事項注: kubectl オートコンプリート スクリプトと同様に、complete-alias は MacOS のデフォルトである Bash 3.2 では機能しません。 特に、complete-alias は bash-completion v2 に依存します (brew install bash-completion@2)、これには少なくとも Bash 4.1 が必要です。 つまり、MacOS で完全エイリアスを使用するには、新しいバージョンの Bash をインストールする必要があります。

スクリプトをダウンロードする必要があります bash_completion.sh の GitHubリポジトリ ファイルに含めてください ~/.bashrc:

source ~/bash_completion.sh

シェルを再起動すると、complete-alias が完全にインストールされます。

kubectl エイリアスのオートコンプリートを有効にする

技術的に完全なエイリアスはラッパー関数を提供します _complete_alias。 この関数はエイリアスをチェックし、エイリアス コマンドの完了ヒントを返します。

関数を特定のエイリアスに関連付けるには、組み込みの Bash メカニズムを使用する必要があります。 コンプリート、インストールする _complete_alias エイリアス補完機能として。

例として、kubectl コマンドを表すエイリアス k を考えてみましょう。 インストールする _complete_alias このエイリアスの補完機能として、次のコマンドを実行する必要があります。

$ complete -F _complete_alias k

この結果、エイリアス k をオートコンプリートするたびに、関数が呼び出されます。 _complete_alias、エイリアスをチェックし、コマンドの完了ヒントを返します。 kubectl.

XNUMX 番目の例として、エイリアスを考えてみましょう。 kgを意味します kubectl get:

$ complete -F _complete_alias kg

前の例と同様に、kg をオートコンプリートすると、kg の場合と同じ補完ヒントが得られます。 kubectl get.

システム上の任意のエイリアスに complete-alias を使用できることに注意してください。

したがって、すべての kubectl エイリアスのオートコンプリートを有効にするには、それぞれのエイリアスに対して上記のコマンドを実行する必要があります。 kubectl-aliases を次のように設定している場合、次のスニペットはまさにこれを実行します。 ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

このコード部分は、 ~/.bashrc、コマンド シェルを再起動すると、800 個の kubectl エイリアスすべてでオートコンプリートが利用できるようになります。

6. プラグインによる kubectl の拡張

から始まる バージョン1.12、kubectl がサポート プラグインの仕組みを使用すると、追加のコマンドで機能を拡張できます。

あなたが精通している場合 Git プラグインのメカニズムの場合、kubectl プラグインは同じ原理に基づいて構築されます。

この章では、プラグインをインストールする方法、プラグインを見つける場所、および独自のプラグインを作成する方法について説明します。

プラグインのインストール

Kubectl プラグインは、次のような名前の単純な実行可能ファイルとして配布されます。 kubectl-x。 プレフィックス kubectl- が必要であり、その後にプラグインを呼び出すことができる新しい kubectl サブコマンドが続きます。

たとえば、hello プラグインは次のファイルとして配布されます。 kubectl-hello.

プラグインをインストールするには、ファイルをコピーする必要があります kubectl-x PATH 内の任意のディレクトリにコピーし、それを実行可能にします。たとえば、 chmod +x。 この直後に次のようにプラグインを呼び出すことができます kubectl x.

次のコマンドを使用すると、システムに現在インストールされているすべてのプラグインを一覧表示できます。

$ kubectl plugin list

このコマンドは、同じ名前のプラグインが複数ある場合、または実行不可能なプラグイン ファイルがある場合にも警告を表示します。

Krew を使用したプラグインの検索とインストール

Kubectl プラグインは、ソフトウェア パッケージと同様に共有または再利用できます。 しかし、他の人が共有しているプラ​​グインはどこで見つけられるのでしょうか?

プロジェクトクルー kubectl プラグインの共有、検索、インストール、管理のための統合ソリューションを提供することを目的としています。 このプロジェクトは自らを「kubectl プラグインのパッケージ マネージャー」と呼んでいます (Krew は 醸造).

Krew は、選択してインストールできる kubectl プラグインのリストです。 同時に、Krew は kubectl のプラグインでもあります。

これは、Krew のインストールは基本的に他の kubectl プラグインのインストールと同じように機能することを意味します。 詳細な手順については、次のサイトを参照してください。 GitHub ページ.

最も重要な Krew コマンドは次のとおりです。

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

Krew を使用してプラグインをインストールしても、上記の標準的な方法を使用してプラグインをインストールすることは妨げられないことに注意してください。

コマンドに注意してください kubectl krew list このコマンドは、Krew を使用してインストールされたプラグインのみを表示します。 kubectl plugin list すべてのプラグイン、つまり、Krew を使用してインストールされたプラグインと他の方法でインストールされたプラグインをリストします。

他の場所でプラグインを探す

Krew は若いプロジェクトで、現在は リスト プラグインはわずか 30 個ほどです。 必要なプラグインが見つからない場合は、GitHub などの他の場所でプラグインを見つけることができます。

GitHub セクションを参照することをお勧めします kubectl-プラグイン。 そこには、チェックしてみる価値のある利用可能なプラグインが多数見つかります。

独自のプラグインを作成する

あなたは自分でできます プラグインを作成する - 難しいことではありません。 必要なことを行う実行可能ファイルを作成し、次のような名前を付ける必要があります kubectl-x 上記のようにインストールします。

ファイルは、bash スクリプト、Python スクリプト、またはコンパイルされた GO アプリケーションの可能性がありますが、それは問題ではありません。 唯一の条件は、オペレーティング システムで直接実行できることです。

では、サンプルプラグインを作成してみましょう。 前のセクションでは、kubectl コマンドを使用して各ポッドのコンテナーを一覧表示しました。 このコマンドをプラグインに変えるのは簡単です。 kubectl img.

ファイルを作成する kubectl-img 次のコンテンツ：

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

次に、ファイルを実行可能にします chmod +x kubectl-img それを PATH 内の任意のディレクトリに移動します。 この直後にプラグインを使用できるようになります kubectl img.

前述したように、kubectl プラグインは任意のプログラミング言語またはスクリプト言語で作成できます。 シェル スクリプトを使用している場合、プラグイン内から kubectl を簡単に呼び出すことができるという利点があります。 ただし、次を使用すると、実際のプログラミング言語でより複雑なプラグインを作成できます。 Kubernetesクライアントライブラリ。 Go を使用している場合は、以下も使用できます cli-ランタイムライブラリ、特に kubectl プラグインを作成するために存在します。

プラグインを共有する方法

あなたのプラグインが他の人にとって役立つと思われる場合は、お気軽に GitHub で共有してください。 必ずトピックに追加してください kubectl-プラグイン.

プラグインの追加をリクエストすることもできます 乗組員リスト。 これを行う方法については、 GitHub リポジトリ.

コマンドの完了

プラグインは現在オートコンプリートをサポートしていません。 つまり、プラグインの完全名と引数の完全名を入力する必要があります。

この関数の GitHub kubectl リポジトリには、 オープンリクエスト。 したがって、この機能は将来的に実装される可能性があります。

幸運!!!

このトピックに関して他に何を読むべきか:

1. Kubernetes の XNUMX つのレベルの自動スケーリングとそれらを効果的に使用する方法.
2. 著作権侵害の精神を備えた Kubernetes と実装用のテンプレート.
3. Telegram の Kubernetes に関する私たちのチャンネル.

出所： habr.com