Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第6章 CLI の拡張

6.1. 概要

このトピックでは、CLI の拡張のインストールおよび作成方法について説明します。通常 プラグイン または バイナリー拡張 と呼ばれるこの機能を使用すると、利用可能なデフォルトの oc コマンドセットを拡張でき、新規タスクを実行することができます。

プラグインはファイルのセットで構成されます。通常は少なくとも 1 つの plugin.yaml 記述子、1 つ以上のバイナリー、スクリプト、またはアセットファイルが含まれます。

現時点で CLI プラグインは oc plugin サブコマンドでのみ利用可能です。

重要

現時点で CLI プラグインはテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能のリリースに先駆けてご提供することができ、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

詳細は、「テクノロジープレビュー機能のサポート範囲」を参照してください。

6.2. 前提条件

以下が必要になります。

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

oc がプラグインを検索するファイルシステム内の場所に、プラグインの plugin.yaml 記述子、バイナリー、スクリプト、およびアセットファイルをコピーします。

現在、OpenShift Container Platform はプラグイン用のパッケージマネージャーを提供していません。したがって、お客様にプラグインファイルを適切な場所に配置していただく必要があります。各プラグインは独自のディレクトリーに置くことが推奨されます。

圧縮ファイルとして配布されているプラグインをインストールするには、「プラグインローダー」のセクションで指定される場所に展開します。

6.3.1. プラグインローダー

プラグインローダーは、「プラグインファイルの検索」のほか、プラグインを実行する上で必要最低限の情報をプラグインが提供するかどうかを確認します。正しい場所に置かれたファイルで、最低限の情報を提供しないもの (例: 不十分な plugin.yaml 記述子) は無視されます。

6.3.1.1. 検索の順序

プラグインローダーは、以下の順序で検索します。

  1. ${KUBECTL_PLUGINS_PATH}

    これが指定されている場合は、検索はここで停止します。

    KUBECTL_PLUGINS_PATH 環境変数がある場合、ローダーはこれをプラグインを検索する際の唯一の場所として使用します。KUBECTL_PLUGINS_PATH 環境変数はディレクトリーの一覧です。Linux および Mac では、この一覧はコロンで区切られています。Windows の場合、この一覧はセミコロンで区切られています。

    KUBECTL_PLUGINS_PATH がない場合、ローダーは他の場所を探し始めます。

  2. ${XDG_DATA_DIRS}/kubectl/plugins

    プラグインローダーは、XDG System Directory Structure の仕様に応じて指定された 1 つ以上のディレクトリーを検索します。

    とりわけローダーは、XDG_DATA_DIRS 環境変数が指定したディレクトリーの場所を見つけます。プラグインローダーは、XDG_DATA_DIRS 環境変数が指定したディレクトリー内にある kubectl/plugins ディレクトリーを検索します。XDG_DATA_DIRS が指定されていない場合は、デフォルトで /usr/local/share:/usr/share を指定します。

  3. ~/.kube/plugins

    ユーザーの kubeconfig ディレクトリーにある plugins ディレクトリーです。ほとんどのケースでは、これは ~/.kube/plugins です。

    # Loads plugins from both /path/to/dir1 and /path/to/dir2
    $ KUBECTL_PLUGINS_PATH=/path/to/dir1:/path/to/dir2 kubectl plugin -h

6.4. プラグインの作成

プラグインは、CLI コマンドの作成に使用できるプログラミング言語またはスクリプトで作成できます。プラグインには必ずしもバイナリーコンポーネントが必要であるとは限りません。echosed、または grep などのオペレーティングシステムのユーティリティーに完全に依存させることができます。または、oc バイナリーに依存させることも可能です。

oc プラグインで唯一の必須要件として、plugin.yaml 記述子ファイルが必要となります。このファイルは、プラグインの登録に必要な最低限の属性を宣言する必要があり、「検索の順序」のセクションで指定された場所に置かれる必要があります。

6.4.1. plugin.yaml 記述子

記述子ファイルは、以下の属性をサポートします。

name: "great-plugin"              # REQUIRED: the plug-in command name, to be invoked under 'kubectl'
shortDesc: "great-plugin plug-in" # REQUIRED: the command short description, for help
longDesc: ""                      # the command long description, for help
example: ""                       # command example(s), for help
command: "./example"              # REQUIRED: the command, binary, or script to invoke when running the plug-in
flags:                            # flags supported by the plug-in
  - name: "flag-name"             # REQUIRED for each flag: flag name
    shorthand: "f"                # short version of the flag name
    desc: "example flag"          # REQUIRED for each flag: flag description
    defValue: "extreme"           # default value of the flag
tree:                             # allows the declaration of subcommands
  - ...                           # subcommands support the same set of attributes

前述の記述子は great-plugin プラグインを宣言します。これには、-f | --flag-name という名前の 1 つのフラグが含まれます。これは以下を実行して呼び出すことができます。

$ oc plugin great-plugin -f value

プラグインが呼び出されると、記述子ファイルと同じディレクトリーにある example バイナリーまたはスクリプトが呼び出され、多くの引数および環境変数が渡されます。「ランタイム属性へのアクセス」のセクションでは、example コマンドがフラグ値およびその他のランタイムコンテキストにアクセスする方法について説明しています。

6.4.2. 推奨されるディレクトリー構造

ファイルシステム内に、各プラグイン独自の (可能ならばプラグインコマンドと同じ名前の) サブディレクトリーを設定することが推奨されます。このディレクトリーには、plugin.yaml 記述子と任意のバイナリー、スクリプト、アセット、または必要とされるその他の依存関係が含まれている必要があります。

たとえば、great-plugin プラグインのディレクトリー構造は、以下のようになります。

~/.kube/plugins/
└── great-plugin
    ├── plugin.yaml
    └── example

6.4.3. ランタイム属性へのアクセス

多くの場合、プラグインをサポートするために作成するバイナリーまたはスクリプトファイルは、プラグインフレームワークで提供される一部のコンテキスト情報にアクセスできる必要があります。たとえば、記述子ファイルでフラグを宣言すると、プラグインは、ランタイムでユーザー提供のフラグ値へのアクセスが必要になります。

これはグローバルフラグの場合も同様です。プラグインフレームワークがこれを実行するので、プラグインの作成側で引数の解析を行う必要はありません。またこれにより、プラグインと通常の oc コマンド間の一貫性を最適なレベルに保つことができます。

プラグインは環境変数を使ってランタイムのコンテキスト属性にアクセスできます。たとえば、フラグで提供された値にアクセスするには、バイナリーまたはスクリプトの適切な関数呼び出しを使用して適切な環境変数の値を探します。

以下は、サポート対象の環境変数です。

  • KUBECTL_PLUGINS_CALLER: 現在のコマンド呼び出しで使用された oc バイナリーへの完全パスです。プラグイン作成側として、Kubernetes API の認証およびこれにアクセスするためのロジックを実装する必要はありません。代わりに、この環境変数が提供する値を使用して oc を呼び出し、必要な情報を取得することができます。たとえば、oc get --raw=/apis などを使用できます。
  • KUBECTL_PLUGINS_CURRENT_NAMESPACE: この呼び出しのコンテキストである現在の namespace です。これは namespace を使用する操作で考慮される実際の namespace です。つまり、これは kubeconfig、--namespace グローバルフラグ、環境変数などで提供され、優先順位が付けられた内容に従ってすでに処理されていることを意味します。
  • KUBECTL_PLUGINS_DESCRIPTOR_*: plugin.yaml 記述子で宣言されるすべての属性の環境変数です。たとえば、KUBECTL_PLUGINS_DESCRIPTOR_NAMEKUBECTL_PLUGINS_DESCRIPTOR_COMMAND などがあります。
  • KUBECTL_PLUGINS_GLOBAL_FLAG_*: oc がサポートするすべてのグローバルフラグの環境変数です。たとえば、KUBECTL_PLUGINS_GLOBAL_FLAG_NAMESPACEKUBECTL_PLUGINS_GLOBAL_FLAG_LOGLEVEL などがあります。
  • KUBECTL_PLUGINS_LOCAL_FLAG_*: plugin.yaml 記述子で宣言されるすべてのローカルフラグの環境変数です。たとえば、前述の great-plugin の例で出てきた KUBECTL_PLUGINS_LOCAL_FLAG_HEAT などがあります。