Kubernetes Engine (OKE)の既知の問題

ノード・プールで開始する新しいワーカー・ノードのプロパティは、ノード・プールのプロパティに対する最新の変更を反映しません。UpdateNodePoolDetails API操作を使用してノード・プールのプロパティを更新する際に、非推奨のquantityPerSubnetおよびsubnetIds属性が使用されていることが原因となっている可能性があります。

次のいずれかを行います。

• UpdateNodePoolDetails API操作を使用する場合は、nodeConfigDetails属性の使用を開始します。最初に、quantityPerSubnetを使用してノード・プールを0にスケーリングします。次に、subnetIdsおよびquantityPerSubnet属性の使用を停止し、かわりにnodeConfigDetails属性を使用します。
• Oracle Supportに連絡して、同期を担当するバックエンド・コンポーネント(テナント・エージェント・コンポーネント)を再起動します。

Kubernetes Dashboardを起動すると、Webブラウザで「net/http: TLSハンドシェイク・タイムアウト」および「ピアによる接続リセット」エラー・メッセージが表示される場合があります。この問題は、Kubernetesバージョン1.11を実行している新規作成されたクラスタでのみ発生しています。関連するKubernetes問題の詳細は、https://github.com/kubernetes/dashboard/issues/3038を参照してください。

1. ターミナル・ウィンドウで入力します:

   $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443

2. Webブラウザでhttps://localhost:8443に移動します

Kubeconfigトークン・バージョン2.0.0を使用してバージョン2.11より前のHelm/Tillerバージョンにアクセスすると、次のいずれかのエラーが発生します:

• Error: Unauthorized
• Error: could not get Kubernetes client: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

次のようにHelm/Tillerをアップグレードします:

1. ターミナル・ウィンドウで、次のコマンドを入力してKubeconfigトークン・バージョン1.0.0をダウンロードします:

   $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>

2. クラスタのリージョンでOracle Cloud Infrastructure Registryレジストリの指定に使用するリージョン・キーを識別します(リージョンごとの可用性を参照)。たとえば、クラスタが米国東部(アッシュバーン)、iadにある場合、そのリージョンでレジストリを指定するために使用するリージョン・キーです。

3. 次のコマンドを入力してTillerをアップグレードします:

   $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

   ここで、<region-key>は前のステップで識別したキーです。

4. ブラウザでhttps://helm.sh/docs/using_helm/#installing-the-helm-clientに移動し、指示に従ってHelmクライアント・バイナリをダウンロードしてインストールします。

5. アップグレードされたHelm/Tillerで、次のコマンドを入力してKubeconfigトークン・バージョン2.0.0をダウンロードします:

   $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

Kubernetes Engine 1.8.0リリースには、顧客のワーカー・ノードで実行されているkubeletの暗号強度を向上するためのセキュリティ改善が含まれました。2019年8月20日から2019年9月16日の間に作成された新しいワーカー・ノードには、この構成が含まれます。新しい暗号セットでは、http/2を介したkubeletへの接続は許可されません。この制限は、メトリック・サーバーと、メトリック・サーバーに依存するHorizontal Pod Autoscalerにも影響します。

既存の各ワーカー・ノードで順番に:

1. 新しいポッドが開始されないようにし、kubectl drain <node_name>を入力してワーカー・ノードの既存のポッドを削除します。詳細は次を参照してください。

   • kubectlの使用については、kubectlを使用したクラスタへのアクセスを参照してください
   • drainコマンドの詳細は、Kubernetesのドキュメントの排出を参照してください

   推奨: アプリケーションに適したポッド中断予算を活用し、排出操作全体で十分な数のレプリカ・ポッドが実行されていることを確認します。

2. ワーカー・ノードを削除します(たとえば、コンソールで終了します)。
3. 代替ワーカー・ノードが起動するのを待機します。

代替ワーカー・ノードには、kubeletとの通信を可能にする新しい設定が含まれます。

クラスタ内のワーカー・ノードで新しいポッドが起動すると、状況によってはタイムアウトが原因でポッドがノードにアタッチされたすべてのボリュームのマウントに失敗し、次のようなメッセージが表示されます:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

この問題に対して特定されている考えられる原因の1つは、ポッド仕様のsecurityContextフィールドにfsGroupフィールドが含まれている場合です。コンテナが非rootユーザーとしてワーカー・ノードで実行されている場合、securityContextのfsGroupフィールドを設定すると、Kubernetesが所有権を変更する必要があるファイルの数が原因でタイムアウトが発生する可能性があります(https://github.com/kubernetes/kubernetes/issues/67014を参照)。

ポッド仕様のsecurityContextにfsgroupフィールドが含まれていない場合、原因は不明です。

ポッド仕様のsecurityContextにfsgroupフィールドが含まれていて、コンテナが非rootユーザーで実行されている場合は、次の回避策を検討してください:

• securityContextからfsgroupフィールドを削除します。
• (fsgroupのかわりに) securityContextのsupplementalGroupsフィールドを使用し、supplementalGroupsをボリューム識別子に設定します。
• コンテナがルートとして実行されるようにポッド仕様を変更します。

ポッド仕様のsecurityContextにfsgroupフィールドが含まれていないか、コンテナがすでにrootとして実行されている場合は、ワーカー・ノードを再起動または置換する必要があります。たとえば、インスタンスを停止して起動するか、インスタンスを再起動するか、インスタンスを終了して新しいインスタンスを起動します。必要に応じて、インスタンスの停止、起動または再起動またはインスタンスの終了の手順に従って、コンソールまたはAPIを使用します。または、次の例のようなCLIコマンドを使用してインスタンスを終了することもできます:

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

<name>は、インスタンスの「プライベートIPアドレス」プロパティから導出されたワーカー・ノード名です(たとえば、10.0.10.5)。

OS管理サービスを使用してOracle Cloud Infrastructureインスタンス上でオペレーティング・システムの更新およびパッチを管理する場合、Kubernetesエンジンによって作成されたクラスタ・ノード・プールがオンラインにならない状況が発生することがあります。

2つの回避策が考えられます:

• 回避策1: OS管理を使用してOracle Cloud Infrastructureインスタンスを管理する場合は、OS管理でOracle Enterprise Linuxを有効にします。ソフトウェア・ソースの管理を参照してください。
• 回避策2: OS管理を使用してOracle Cloud Infrastructureインスタンスを管理しない場合は、OS管理の実行を許可するポリシーが存在しないことを確認してください。具体的には、インスタンスの動的グループにOS管理サービスへのアクセス権を付与するポリシーを削除します。OS管理のポリシーの設定を参照してください。

/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 

この問題を確認するには、インスタンスでターミナル・ウィンドウを開き、次のコマンドを実行します:

sudo /usr/sbin/lsmod | grep br_netfilter 

結果が返されない場合は、Bridge Netfilterカーネル・モジュールが有効になっていません。Bridge Netfilterカーネル・モジュールは、KubernetesポッドのVxLANトラフィックをマスカレードするために必要です。

Bridge Netfilterカーネル・モジュールを有効にします。インスタンスでターミナル・ウィンドウを開き、次のコマンドを実行します:

sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

VCNネイティブ・ポッド・ネットワークを使用している場合、ポッドへのインバウンド・リクエストのソース・クライアントIPアドレスが予想どおりに保持されないことがあります。かわりに、マニフェスト・ファイルでexternalTrafficPolicy: Localが設定されているLoadBalancerタイプのKubernetesサービスを介して受信したインバウンド・リクエストは、ワーカー・ノードのIPアドレスから送信されたものとして表示される場合があります。

マニフェスト・ファイルにoci.oraclecloud.com/load-balancer-type: "lb"注釈があるLoadBalancerタイプのKubernetesサービスを介して受信したインバウンドTCPリクエストの場合、X-Forwarded-ForまたはX-Real-IPヘッダーからソース・クライアントIPアドレスを取得します。

VCNネイティブ・ポッド・ネットワークを使用している場合、クラスタ内の1つ以上のノード・プールのワーカー・ノードにベア・メタル・シェイプを指定すると、ポッドはネットワーク経由で通信できない可能性があります。

VCNネイティブ・ポッド・ネットワークを使用している場合、クラスタ内のすべてのノード・プールのワーカー・ノードにVMシェイプを指定します。

VCNネイティブ・ポッド・ネットワークを使用している場合、ノード・プールに選択したフレキシブル・シェイプに指定したOCPUの数に関係なく、ノード・プールのワーカー・ノード当たりのポッドの最大数は31に制限されることがあります。

ノード・プールのワーカー・ノード当たり31個を超えるポッドが必要な場合は、ノード・プールのワーカー・ノードに別のシェイプを選択します。

VCNネイティブ・ポッド・ネットワークを使用している場合、VCNに指定された最初のCIDRブロック外のCIDRブロックを持つポッド・サブネットに接続されているワーカー・ノードで実行されているポッドは、Kubernetesサービスと通信できない可能性があります。

VCNに指定された最初のCIDRブロック内のCIDRブロックを持つポッド・サブネットを作成します。

Node Doctorスクリプトを使用してノードの問題をトラブルシューティングする場合、スクリプトに次のような例外エラー・メッセージが表示されます:

FileNotFoundError: [Errno 2] No such file or directory: '/home/opc/vendor/pip…

Node Doctorスクリプトは引き続き実行され、メッセージGenerating node doctor bundleが表示されてトラブルシューティング出力が生成されます。

オラクル社では問題を認識しており、解決に取り組んでいます。その間、Node DoctorスクリプトでメッセージGenerating node doctor bundleが表示される場合は、トラブルシューティング出力がまだ有効であることに注意してください。

Node DoctorスクリプトでFileNotFoundError: [Errno 2]...例外エラー・メッセージが表示されないようにする場合は、次のように入力してNode Doctorスクリプトを更新します:

node-doctor.sh --update

Node Doctorスクリプトおよびその更新方法の詳細は、Node Doctorスクリプトを使用したKubernetesクラスタのノード問題のトラブルシューティングを参照してください。

クラスタでVCNネイティブ・ポッド・ネットワーキングが使用され、ワークロード・ポッドとCoreDNSポッドの両方が同じワーカー・ノードで実行されている場合、トラフィックが誤ってNATedであるため、DNS解決が失敗することがあります。

2023-03-21で、この問題を解決したOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新がリリースされました。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新の手順に従って、更新をデプロイします。

クラスタがVCNネイティブ・ポッド・ネットワーキングを使用し、ワーカー・ノードがOracle Linux 8 (OL8)を実行している場合、ワーカー・ノードの1つでポッドの起動に失敗することがあります。この問題の特性は次のとおりです:

• ワーカー・ノードがOL8イメージを実行しています。
• ホスト・ネットワーク関連のポッドはワーカー・ノードで予期したとおりに実行されますが、他のすべてのポッドは起動に失敗します。
• crictlログには、メッセージAdding address to IPVLAN parent device (IPアドレスがワーカー・ノードのセカンダリVNICにアタッチされていることを示す)が含まれ、その後にエラー・メッセージError adding secondary VNIC IPが続きます。
• ワーカー・ノードでLinux IP addressコマンドを実行すると、1つ(または複数)のセカンダリVNICにIPアドレスがアタッチされていないことが示されます。
• その他すべて(またはほとんど)のワーカー・ノードは期待どおりに動作しています。

この問題で特定される可能性の高い原因は、ネットワーク・デバイスおよび接続を管理するNetworkManagerに関連しています。場合によっては、NetworkManagerによって、1つ以上のワーカー・ノードのセカンダリVNICにアタッチされているIPアドレスがデタッチされ、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインが失敗します。

2023-03-21で、この問題を解決したOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新がリリースされました。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新の手順に従って、更新をデプロイします。

ノード・プールにOracle Linux 8.7またはOracle Linux 8.8を指定した場合(Oracle Linux 8.7またはOracle Linux 8.8プラットフォーム・イメージ、またはOracle Linux 8.7またはOracle Linux 8.8上に構築されたOKEワーカー・ノード・イメージを選択)、ノード・プールのワーカー・ノードのステータスが予期せずNotReadyに変更される可能性があります。この問題の特性は次のとおりです:

• ワーカー・ノードはOracle Linux 8.7またはOracle Linux 8.8を実行しています。
• ワーカー・ノードは、Kubernetesバージョン1.24.1、1.25.4または1.26.2を実行しています。(Kubernetesバージョン1.25.12、1.26.7および1.27を実行しているワーカー・ノードは影響を受けません。)
• 存続期間の短いポッドはワーカー・ノードに頻繁にデプロイされます。
• ノード・プールのワーカー・ノードにデプロイされたポッドは、予想より長くContainerCreatingステータスのままになることもあります。

オラクル社では問題を認識しており、解決に取り組んでいます。

その間に、この問題が発生した場合は、次の回避策のうち要件に最も適したものを使用してください:

• ノード・プールのOracle Linux 7イメージを指定します。
• ノード・プールのOracle Linux 8.6イメージ(または以前のOracle Linux 8イメージ)を指定します。
• ノード・プールの新しいバージョンのKubernetesを指定します。(Kubernetesバージョン1.25.12、1.26.7および1.27を実行しているワーカー・ノードは影響を受けません。)

コンソールに表示されなくなったイメージのOCIDを取得するには:

• プラットフォーム・イメージ: すべてのOracle Linux 7.xイメージおよびすべてのOracle Linux 8.xイメージを参照してください
• OKEワーカー・ノード・イメージ: OKEワーカー・ノードのすべてのOracle Linux 7.xイメージおよびOKEワーカー・ノードのすべてのOracle Linux 8.xイメージを参照してください

VCNネイティブ・ポッド・ネットワーキングを使用する2023年6月26日より前に作成されたクラスタでは、新しいワーカー・ノードのプロビジョニングに遅延が表示される場合があります。

OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用してワーカー・ノードをブートストラップする場合、Kubernetes Engineは各コンピュート・インスタンスにKubernetesカスタム・リソース(NativePodNetworkまたはNPN、リソース)をデプロイします。ワーカー・ノードが正常にブートストラップされると、Kubernetes Engineによって、コンピュート・インスタンスに関連付けられたNPNリソースにSUCCESSのステータスが付与されます。

場合によっては、Kubernetes Engineが関連付けられたNPNリソースにSUCCESSのステータスを付与する前にコンピュート・インスタンスが終了した場合、NPNリソースは無期限にBACKOFFまたはIN_PROGRESSステータスのままになります。このような「失効」リソースが存在すると、新しいワーカー・ノードのプロビジョニングが遅延する可能性があります。

この問題は、2023-06-26の後に作成されたクラスタで修正されます。2023-06-26より前に作成されたクラスタの問題を解決するには、この項の手順に従って、1回かぎりのアクションを実行して失効したリソースを削除します。

開始する前に、システムが次の前提条件を満たしていることを確認します。

• OCI CLIがインストールされていること(CLIのインストールを参照)
• OCI CLIの構成(CLIの構成を参照)
• jqがダウンロードおよびインストールされました(https://jqlang.github.io/jq/download/を参照)
• Allow group <group-name> to manage instance-family in <location>など、少なくともINSTANCE_READ権限を付与するIAMポリシーが存在します(グループに必要なポリシーの作成を参照)
• kubectlを使用してOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用するクラスタを管理できるように、適切なkubeconfigファイルにアクセスできます(Kubectlを使用したクラスタへのアクセスを参照)

次のように、失効したリソースを特定して削除します。

1. システムがすべての前提条件を満たしていることを確認します。
   1. 次のスクリプトをpre-req-check.shという名前のファイルに保存します。

      #!/bin/bash
      echo Validating cluster access to get npn resources
      ACTIVE_RESOURCES=($(kubectl get npn -o json | jq '[.items[] | select(.status.state == "SUCCESS")]' | jq -r '.[] | .metadata.name'))
      if [[ -z "$ACTIVE_RESOURCES" ]] || [ ${#ACTIVE_RESOURCES[@]} == 0 ]
      then
        echo No active NPN resources found. Make sure you have cluster access and this is an OCI VCN-Native CNI cluster. '\'nPlease check prerequisites and retry.
        exit
      fi
       
      cr_name=${ACTIVE_RESOURCES[0]}
      echo Validating access to get compute instance
      INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
      INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
       
      if [[ -z "$INSTANCE_STATE" ]]
      then
        echo Unable to get instance details, please check prerequisites and retry.
      else
        echo All prerequisites in place, please proceed to cleaning up stale resources.
      fi

   2. 次のように入力して、pre-req-check.shスクリプトを実行します。

      sh pre-req-check.sh

2. ステータスが「成功」でないために削除可能な候補であるNPNリソースを識別します。
   1. ステータスがSUCCESSでないNPNリソースのリストを potential_stale_resources.txtというテキスト・ファイルに出力するには、次のように入力します。

      kubectl get npn -o json | jq '[.items[] | select(.status.state != "SUCCESS")]' | jq -r '.[] | .metadata.name' >> potential_stale_resources.txt

   2. オプションで、次のように入力して、potential_stale_resources.txtの候補NPNリソースのリストを表示します。

      cat potential_stale_resources.txt

      たとえば、potential_stale_resources.txtには次のものを含めることができます。

      anyhqljth4...trq
      anyhqljth4...snq
      anyhqljth4...qhq

3. 使用不可または終了済のコンピュート・インスタンスに関連付けられている候補NPNリソースを決定して、削除する失効済NPNリソースを識別します。
   1. 次のスクリプトをget_stale_resources.shという名前のファイルに保存します。

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read  -r cr_name
      do
        echo verifying NPN resource $cr_name
        INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
        if [  -z $INSTANCE_ID ]
        then
          echo Unable to get npn resource details. Please check prerequisites and retry from step 2.
          exit
        fi
        echo Associated instance is $INSTANCE_ID
        INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
        if [  -z $INSTANCE_STATE ]
        then
          # check for 404 for tombstoned instances
          STATUS=$(oci compute instance get --instance-id $INSTANCE_ID 2>&1 | tail -n +2 | jq .status)
          if [ $STATUS == 404 ]
          then
            echo 404 getting instance $INSTANCE_ID, Instance has been tombstoned. Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          fi
        else
          echo Instance $INSTANCE_ID in $INSTANCE_STATE state
          if [ $INSTANCE_STATE == "TERMINATED" ]
          then
            echo Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          else
            echo Instance $INSTANCE_ID not terminated. '\'nSkipping resource $cr_name '\'n
          fi
        fi
      done < $1

   2. 次のように入力して、get_stale_resources.shスクリプトを実行します。

      sh get_stale_resources.sh potential_stale_resources.txt

      get_stale_resources.shスクリプトは、削除する失効したNPNリソースを識別し、処理メッセージを画面に出力して、失効したNPNリソースの名前をstale_resources.txtという名前のファイルに書き込みます。例:

      Reading resources from potential_stale_resources.txt
      verifying NPN resource anyhqljth4...trq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...trq
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq in RUNNING state
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq not terminated.
      Skipping resource anyhqljth4...trq
       
      verifying NPN resource anyhqljth4...snq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...snq
      Instance ocid1.instance.oc1.phx.anyhqljth4...snq in TERMINATED state
      Adding resource anyhqljth4...snq to stale_resources
       
      verifying NPN resource anyhqljth4...qhq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...qhq
      ServiceError:
      {
          "client_version": "Oracle-PythonSDK/2.104.2, Oracle-PythonCLI/3.29.0",
          "code": "NotAuthorizedOrNotFound",
          "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
          "message": "instance ocid1.instance.oc1.phx.anyhqljth4...qhq not found",
          "opc-request-id": "CCB8D1925...38ECB8",
          "operation_name": "get_instance",
          "request_endpoint": "GET https://iaas.us-phoenix-1.oraclecloud.com/20160918/instances/ocid1.instance.oc1.phx.anyhqljth4...qhq",
          "status": 404,
          "target_service": "compute",
          "timestamp": "2023-06-27T20:24:28.992241+00:00",
          "troubleshooting_tips": "See [https://docs.oracle.com/iaas/Content/API/References/apierrors.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
      }
      404 getting instance ocid1.instance.oc1.phx.anyhqljth4...qhq, Instance has been tombstoned
      Adding resource anyhqljth4...qhq to stale_resources

   3. オプションで、次のように入力して、stale_resources.txtの失効したNPNリソースのリストを表示します。

      cat stale_resources.txt

      たとえば、stale_resources.txtには次のものを含めることができます。

      anyhqljth4...snq
      anyhqljth4...qhq

4. stale_resources.txtファイルにリストされている失効したNPNリソースを削除します。
   1. 次のスクリプトをdelete_stale_resources.shという名前のファイルに保存します。

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read -r cr_name
      do
          echo Deleting $cr_name
          kubectl delete npn $cr_name
      done < $1

   2. 次のように入力して、delete_stale_resources.shスクリプトを実行します。

      sh delete_stale_resources.sh stale_resources.txt

      delete_stale_resources.shスクリプトは、stale_resources.txtファイルにリストされている失効したNPNリソースを削除し、処理メッセージを画面に出力します。例:

      Reading resources from stale_resources.txt
      Deleting anyhqljth4...snq
      nativepodnetwork.oci.oraclecloud.com "anyhqljth4...snq" deleted

5. ハウスキーピングの適切な方法として、前に作成したstale_resources.txtおよびpotential_stale_resources.txtファイルを削除します。

仮想ノードにArmシェイプを指定すると、ノード上でスケジュールされたポッドは、意図したとおりにArmプロセッサで実行されます。ただし、kubectl describe nodeコマンドまたはKubernetes APIを使用して仮想ノードを調べた場合、ノードにスケジュールされているポッドがArmプロセッサで実行されていても、ノードのアーキテクチャ・プロパティはAMD64を示します。

オラクル社では問題を認識しており、解決に取り組んでいます。

一方、この問題が発生した場合は、仮想ノードのアーキテクチャ・プロパティの値を無視します。

KubernetesエンジンがLoadBalancerタイプのKubernetesサービスのOCIロード・バランサをプロビジョニングする場合、ロード・バランサは削除保護を有効にしません。

その後、コンソール、CLIまたはAPIを使用してロード・バランサの削除保護を有効にすると、cloud-controller-managerはロード・バランサの削除を妨げるだけでなく、ロード・バランサのプロパティも更新できません。

オラクル社では問題を認識しており、解決に取り組んでいます。

一方、コンソール、CLIまたはAPIを使用して、ロード・バランサの削除保護を有効にしないでください。

コンソール、CLIまたはAPIを使用して、Kubernetes EngineによってプロビジョニングされるOCIロード・バランサを変更することはお薦めしません(詳細は、LoadBalancerタイプのKubernetesサービスの定義を参照)。

OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの新しいバージョンは、通常、OC1、OC2およびOC3レルムでリリースされます。

ただし、2024年9月3日に、セキュリティおよびパフォーマンスの拡張を含むOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン・バージョン2.2.0が、OC1レルムでのみリリースされました。

2024年10月4日に、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン・バージョン2.2.2が、OC1、OC2およびOC3レルムでリリースされ、さらに拡張されました。

したがって、2024年9月3日から2024年10月4日の間:

• OC2およびOC3レルムで作成した新しいクラスタでは、以前のバージョンのOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン(バージョン2.1.0)が使用されていました。
• OC2レルムおよびOC3レルム内の既存のクラスタの場合、Oracleに更新をクラスタ上のOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインに自動的にデプロイするように指定した場合でも、バージョン2.2.0はそれらのクラスタにデプロイされませんでした。

お客様またはOracleがOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインに更新をデプロイするかどうかに関係なく、更新はワーカー・ノードが次回再起動される場合にのみ適用されます。

その結果、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン・バージョン2.1.0を実行しているOC2およびOC3レルムにクラスタが存在する場合があります。

OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン・バージョン2.2.0および2.2.2の機能拡張を利用するには、バージョン2.2.2を使用するように、OC2またはOC3のクラスタを更新することを強くお薦めします。

コンソールでバージョン2.2.0を選択できる場合でも、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインのバージョン2.2.0は、OC2およびOC3レルムでリリースされません。

OC2またはOC3レルムで拡張クラスタに対してOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを有効にし、デプロイするアドオンのバージョンを選択することを指定する場合は、バージョン2.2.0を選択しないでください。代わりに、バージョン2.2.2 (またはそれ以降)を選択します。OC2およびOC3レルムで拡張クラスタのバージョン2.2.0を選択した場合、ワーカー・ノードは起動せず、クラスタは機能しないことに注意してください。

詳細は、「ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用」を参照してください。

Kubernetes Engineによって作成されたKubernetesクラスタを操作する場合、クラスタがKubernetes APIサーバーと相互作用すると予期しない遅延(kubectlコマンドに対するレスポンスが遅いなど)が発生することがあります。

古いバージョンのOCI CLIまたはPython(あるいはその両方)がインストールされているクライアント・マシンを使用している場合、kube-apiserverレイテンシでのこれらの断続的なスパイクは、既知のOCI CLIパフォーマンスの問題が原因である可能性があります。このパフォーマンスの問題は、特に Pythonバージョン3.6で確認されています。

デフォルトでは、Kubernetesエンジンがクラスタ用に作成するkubeconfigファイルには、トークンを生成するためのOCI CLIコマンド(OCI ce cluster generate-tokenコマンド)が含まれています。このトークンは、kube-apiserverへのリクエストを認証するために使用されます。現在、各kube-apiserverリクエストによってOCI CLIの呼出しがトリガーされ、コマンドを実行してトークンが生成されます。このOCI CLI呼出しは、既知のOCI CLIパフォーマンスの問題の影響を受ける可能性があります。

既知のOCI CLIパフォーマンスの問題によってkube-apiserverレイテンシが発生したことを確認するには、クライアントで使用されているkubeconfigファイルを見つけて表示します。kubeconfigファイルのusersセクションで、対象のクラスタに関連付けられているユーザーを見つけます。サービス・アカウントを使用するためにkubeconfigファイルに変更が加えられていない場合(Kubeconfigファイルへのサービス・アカウント認証トークンの追加を参照)、userセクションには、次のyaml形式のOCI CLIトークン生成コマンドが含まれます:

- name: <user-name>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - ce
      - cluster
      - generate-token
      - --cluster-id
      - <your-cluster-ocid>
      - --region
      - <your-region>
      command: oci
      env: []

kube-apiserverレイテンシが既知のパフォーマンスの問題に起因することを確認するには、次のコマンドを使用して、OCI CLIがトークン生成コマンドの実行に要する時間を返します。

time oci ce cluster generate-token --cluster-id <your-cluster-ocid> --region <your-region>

コマンドの実行にかかった時間が、確認したkube-apiserverレイテンシに近い場合、既知のパフォーマンスの問題が発生している可能性があります。

サポートされているバージョンのPythonとともに、最新の安定版のOCI CLIを使用していることを確認してください(OCI CLIドキュメントの手動インストールを参照)。

Pythonバージョン3.6を使用している場合は、新しい Pythonバージョンにアップグレードすることをお勧めします。

新しいPythonバージョンにアップグレードできない場合は、すべてのサービスのインポートを無効にし(デフォルトの動作)、必要な個々のサービスおよびモジュールのみを選択的にインポートします。選択的にサービスをインポートすることは、Pythonバージョン3.6のパフォーマンスを向上させるために知られています。詳細は、Python 3.6の選択的サービス・インポートの有効化を参照してください。