フィーチャーゲートの有効化または無効化
このページでは、フィーチャーゲートを有効化また無効化して、クラスター内でKubernetesの特定の機能を制御する方法を説明します。 フィーチャーゲートを有効化することで、一般提供される前にアルファまたはベータ機能をテストおよび使用できます。
備考:
一部の安定版(GA)ゲートについては、通常はGA後の1つのマイナーリリースでのみ無効化することもできます。 ただし、その場合はクラスターがKubernetesに準拠しなくなる可能性があります。始める前に
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:
以下も必要です:
- クラスターへの管理者アクセス
- 有効化したいフィーチャーゲートに関する知識(フィーチャーゲートのリファレンスを参照)
備考:
GA(安定版)機能は常にデフォルトで有効化されています。 通常、ゲートはアルファまたはベータ機能に対して設定します。フィーチャーゲートの成熟度を理解する
フィーチャーゲートを有効化する前に、フィーチャーゲートのリファレンスで機能の成熟度レベルを確認してください:
- アルファ: デフォルトでは無効化されており、バグを含む可能性があります。テストクラスターでのみ使用してください。
- ベータ: デフォルトでは通常有効化されており、十分にテストされています。
- GA: デフォルトでは常に有効化されています。GA後の1つのリリースでのみ無効化できる場合があります。
フィーチャーゲートを必要とするコンポーネントの特定
さまざまなフィーチャーゲートは、さまざまなKubernetesコンポーネントに影響を与えます:
- 一部の機能は、複数のコンポーネントでゲートを有効化する必要があります(例: APIサーバーとコントローラーマネージャー)
- 他の機能は、単一のコンポーネントのみでゲートを必要とします(例: kubeletのみ)
フィーチャーゲートのリファレンスは通常、各ゲートによって影響を受けるコンポーネントを示しています。 すべてのKubernetesコンポーネントは同じフィーチャーゲート定義を共有しているため、すべてのゲートがヘルプ出力に表示されますが、各コンポーネントの動作に影響を与えるのは関連するゲートのみです。
設定
クラスター初期化中
関連するコンポーネント全体でフィーチャーゲートを有効化するための構成ファイルを作成します:
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
apiServer:
extraArgs:
feature-gates: "FeatureName=true"
controllerManager:
extraArgs:
feature-gates: "FeatureName=true"
scheduler:
extraArgs:
feature-gates: "FeatureName=true"
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
FeatureName: true
クラスターを初期化します:
kubeadm init --config kubeadm-config.yaml
既存のクラスター
kubeadmクラスターの場合、フィーチャーゲートの設定はマニフェストファイル、構成ファイル、kubeadm設定など複数の場所で行うことができます。
/etc/kubernetes/manifests/内のコントロールプレーンコンポーネントのマニフェストを編集します:
-
kube-apiserver、kube-controller-manager、またはkube-schedulerの場合、コマンドにフラグを追加します:
spec: containers: - command: - kube-apiserver - --feature-gates=FeatureName=true # ... other flagsファイルを保存します。 Podは自動的に再起動します。
-
kubeletの場合、
/var/lib/kubelet/config.yamlを編集します:apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration featureGates: FeatureName: truekubeletを再起動します:
sudo systemctl restart kubelet -
kube-proxyの場合、ConfigMapを編集します:
kubectl -n kube-system edit configmap kube-proxy設定にフィーチャーゲートを追加します:
featureGates: FeatureName: trueDaemonSetを再起動します:
kubectl -n kube-system rollout restart daemonset kube-proxy
複数のフィーチャーゲートの設定
コマンドラインのフラグに、カンマ区切りのリストを使用します:
--feature-gates=FeatureA=true,FeatureB=false,FeatureC=true
構成ファイルをサポートするコンポーネント(kubelet、kube-proxy)の場合:
featureGates:
FeatureA: true
FeatureB: false
FeatureC: true
備考:
kubeadmクラスターの場合、コントロールプレーンのコンポーネント(kube-apiserver、kube-controller-manager、kube-scheduler)は通常、/etc/kubernetes/manifests/にある静的Podマニフェスト内のコマンドラインフラグを介して構成されます。
これらのコンポーネントは--configフラグを介して構成ファイルをサポートしていますが、kubeadmは主にコマンドラインフラグを使用します。フィーチャーゲート設定の確認
設定後、フィーチャーゲートがアクティブであることを確認します。 以下の方法は、コントロールプレーンのコンポーネントが静的Podとして実行されるkubeadmクラスターに適用されます。
コントロールプレーンコンポーネントのマニフェストを確認する
静的Podマニフェストで設定されたフィーチャーゲートを表示します:
kubectl -n kube-system get pod kube-apiserver-<node-name> -o yaml | grep feature-gates
kubeletの設定を確認する
kubeletのconfigzエンドポイントを使用します:
kubectl proxy --port=8001 &
curl -sSL "http://localhost:8001/api/v1/nodes/<node-name>/proxy/configz" | grep featureGates -A 5
もしくは、ノード上で直接構成ファイルを確認します:
cat /var/lib/kubelet/config.yaml | grep -A 10 featureGates
メトリクスエンドポイントを介して確認する
フィーチャーゲートのステータスは、KubernetesコンポーネントによってPrometheusスタイルのメトリクスで公開されます(利用可能なのはKubernetes 1.26以降)。
メトリクスエンドポイントをクエリして、どのフィーチャーゲートが有効になっているかを確認します:
kubectl get --raw /metrics | grep kubernetes_feature_enabled
特定のフィーチャーゲートを確認するには:
kubectl get --raw /metrics | grep kubernetes_feature_enabled | grep FeatureName
メトリクスは、有効なゲートには1、無効なゲートには0を表示します。
備考:
kubeadmクラスターでは、フィーチャーゲートが構成される可能性のあるすべての関連場所を確認してください。 設定は複数のファイルと場所に分散しています。/flagzエンドポイントで確認する
コンポーネントのデバッグエンドポイントにアクセスでき、ComponentFlagzフィーチャーゲートがそのコンポーネントで有効化されている場合、/flagzエンドポイントにアクセスしてコンポーネントの軌道に使用されたコマンドラインフラグを検査できます。
コマンドラインフラグを使用して構成されたフィーチャーゲートは、この出力に表示されます。
/flagzエンドポイントは、Kubernetesのz-pagesの一部であり、人間が読みやすい形式でコアコンポーネントのランタイムデバッグ情報を提供します。
より詳しくは、z-pagesのドキュメントを参照してください。
コンポーネント固有の要件の理解
コンポーネント固有のフィーチャーゲートの例:
- APIサーバー重視:
StructuredAuthenticationConfigurationのような機能は主にkube-apiserverに影響します - Kubelet重視:
GracefulNodeShutdownのような機能は主にkubeletに影響します - 複数コンポーネント: 一部の機能では、コンポーネント間の調整が必要です
注意:
ある機能が複数のコンポーネントを必要とする場合、関連するすべてのコンポーネントでゲートを有効化する必要があります。 一部のコンポーネントでのみ有効化すると、予期しない動作やエラーが発生する可能性があります。フィーチャーゲートは必ず本番環境以外の環境で最初にテストしてください。 アルファ機能は予告なしに削除される可能性があります。
次の項目
- フィーチャーゲートのリファレンスを読む
- 機能のステージについて学ぶ
- kubeadmの設定を確認する