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管理のポリシーの設定を参照してください。

詳細

Bridge Netfilterカーネル・モジュールが有効でない場合、localhostとのトラフィック通信は正常にルーティングされません。例:

/ # 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スクリプトとその更新方法の詳細は、ノード・ドクター・スクリプトを使用した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エンジンによってプロビジョニングされた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パフォーマンスの問題の影響を受ける可能性があります。

kube-apiserverレイテンシが既知のOCI CLIパフォーマンスの問題によって発生していることを確認するには、クライアントによって使用されている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の選択的サービス・インポートの有効化を参照してください。

詳細

Kubernetesエンジンを使用して作成したクラスタで、既存のノード・プールをKubernetesバージョン1.33.1にアップグレードすると、以前に正常に実行されたワークロードで問題が発生し、Too many open filesなどのエラー・メッセージが返される場合があります。

考えられる原因は、Kubernetesバージョン1.33.1を実行しているノード・プールで、コンテナ内のオープン・ファイル(ulimit nofile)のデフォルトのソフト制限が1024に削減されたことです。以前に高いデフォルト制限に暗黙的に依存していたワークロードでは、問題が発生する可能性があります。

コンテナ内のオープン・ファイル(ulimit nofile)のデフォルトのソフト制限は、CRI-Oコンテナ・ランタイムの変更により1024に削減されました。Kubernetesバージョン1.33.1では、CRI-Oバージョン1.33が使用されます。CRI-Oバージョン1.33では、CRI-O systemdサービス・ファイルでLimitNOFILEパラメータが明示的に設定されなくなりました。その結果、systemdのデフォルトのソフト制限(通常は1024)がコンテナ内のオープン・ファイルに適用されるようになりました。詳細は、https://github.com/cri-o/cri-o/pull/8962を参照してください。

回避方法

オラクル社では問題を認識しており、解決に取り組んでいます。一方、次の2つの回避策があります。

• 回避策1: ulimit nofileを増やすカスタムcloud-initスクリプトを作成します。例:

  #!/bin/bash
  mkdir -p /etc/crio/crio.conf.d
  echo "[crio]" > /etc/crio/crio.conf.d/11-default.conf
  echo "  [crio.runtime]" >> /etc/crio/crio.conf.d/11-default.conf
  echo "    default_ulimits=[\"nofile=262144:262144\"]" >> /etc/crio/crio.conf.d/11-default.conf
  curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
  sudo bash /var/run/oke-init.sh

  nofile=262144:262144が例であることに注意してください。nofileをワークロードに適した値に設定します。カスタムのcloud-initスクリプトの作成の詳細は、「カスタムのCloud-init初期化スクリプトによる管理対象ノードの設定」を参照してください。

• 回避策2:永続解決が使用可能になるまで、ノード・プールで実行されているKubernetesのバージョンを一時的にKubernetesバージョン1.32にダウングレードします。

詳細

Kubernetesエンジンによって作成されたKubernetesクラスタのLoadBalancerタイプのKubernetesサービスまたは永続ボリューム要求(PVC)を定義すると、Kubernetes APIエンドポイント・サブネットまたはワーカー・ノード・サブネットが必要なOCIサービス・エンドポイントに到達できない場合、対応するロード・バランサまたはボリュームのプロビジョニングが失敗する可能性があります。この問題は、ルート表、セキュリティ・リストまたはゲートウェイ(インターネット・ゲートウェイ、NATゲートウェイ、サービス・ゲートウェイ)の構成の誤りなど、不正確または不完全なVCN構成によって頻繁に発生します。

Kubernetes Engineによって作成されたクラスタでは、Kubernetes APIへのアクセスは、Kubernetes APIエンドポイントを介して提供されます。このエンドポイントは、クラスタの作成時に指定したサブネットにあります。このエンドポイントは、パブリック(パブリックIPアドレスを使用してインターネットからアクセス可能)またはプライベート(パブリックIPアドレスなしで、VCN内または接続ネットワーク内からのみアクセス可能)として構成できます。

ネットワーク構成の誤りによって影響を受けるワークロードには、次のようなイベントが表示されることがあります。

Error syncing load balancer: failed to ensure load balancer: Get "https://network-load-balancer-api...": dial tcp ...:443: i/o timeout

または

failed to provision volume with StorageClass "oci-bv": rpc error: code = Internal desc = failed to check existence of volume Get "https://iaas...": dial tcp ...:443: i/o timeout

その他の症状には、次のものがあります。

• LoadBalancerタイプのサービスに対する外部ロード・バランサのプロビジョニングに失敗しました。
• CSIボリューム・プラグインを使用したPVCの永続ボリュームのプロビジョニングに失敗しました。
• Cloud-controller-manager (CCM)コンテナの起動の失敗、またはノードに残っている永続的なテイント(ワークロードのスケジュールを妨げる可能性があります)。

詳細は、関連するサービス・ログを確認してください(Kubernetesエンジン(OKE)サービス・ログの表示を参照)。

背景

すべてのVCNでは、ワーカー・ノード(コンピュート・インスタンス)と他のネットワークまたはサービス間の通信を可能にするために、正しいゲートウェイ構成が必要です。Kubernetes Engineのコンテキストでは、適切なゲートウェイ選択により、Kubernetes APIエンドポイントとワーカー・ノードの両方が、クラスタ・プロビジョニング、ノード操作、および他のOCIサービスとの統合のためのネットワーク・アクセスを持つことが保証されます。

KubernetesクラスタのKubernetes APIエンドポイントは、クラスタの作成時に指定したサブネットに存在するため、エンドポイントへのネットワーク・アクセスを制御できます。基礎となるKubernetesコントロール・プレーンは、テナンシの外部でOracleによって管理およびホストされます。OCIでは、0.0.0.0/0宛のトラフィックをインターネット・ゲートウェイに送信するルールが関連付けられているルート表に含まれている場合、サブネットはパブリックとみなされます。ルート表にそのようなルールが含まれていない場合、サブネットはプライベートとみなされます。

VCNのプライマリ・ゲートウェイ・オプションは次のとおりです。

• インターネット・ゲートウェイ(IGW):パブリック・サブネットのコンピュート・インスタンスがパブリック・インターネットにアクセスできるようにします。インスタンスにはパブリックIPアドレスが必要です。また、サブネットのルート表には、0.0.0.0/0をインターネット・ゲートウェイに送信するルールが含まれている必要があります。
• NAT Gateway:プライベート・サブネットのコンピュート・インスタンスが、インバウンド・インターネット・トラフィックに公開することなく、アウトバウンド・インターネット接続(オペレーティング・システムの更新やパッケージのインストールなど)を開始できるようにします。NATゲートウェイを使用するインスタンスには、パブリックIPアドレスは必要ありません。
• サービス・ゲートウェイ(SGW):プライベート・サブネット内のコンピュート・インスタンスは、パブリック・インターネットをトラバースせずに、Oracleの内部ネットワークを介して、他のOCIサービス(オブジェクト・ストレージ、コンテナ・レジストリ、Autonomous AI Database、ストリーミング、その他の選択したサービスなど)にアクセスできます。

同じターゲットOCIサービスに対してインターネット・ゲートウェイとサービス・ゲートウェイを一緒に使用しないでください。インターネット・ゲートウェイとサービス・ゲートウェイをルーティング・オプションとしてVCN内の同じOCIサービスに混在させると、トラフィックが間違ったネットワーク・パスで送信される可能性があります。たとえば、プライベートOCIサービスを対象とするリクエストは、サービス・ゲートウェイを介してではなく、インターネット・ゲートウェイを介してパブリック・インターネットを介してルーティングされます。インターネット・ゲートウェイとサービス・ゲートウェイの両方を可能なルートとして使用すると、Kubernetes APIエンドポイントまたはワーカー・ノードがOCIエンドポイントに必要なプライベートでセキュアな接続を確立できなくなるため、プロビジョニングの失敗、永続的なテイント、またはクラスタ内のその他の接続の問題が発生する可能性があります。

したがって、ワーカー・ノードおよびKubernetes APIエンドポイントで使用されるサブネットのルート表が、宛先に基づいてトラフィックを適切なゲートウェイに明確に誘導するようにしてください。プライベート・サブネットからOCIサービスにアクセスするには、ルートがインターネット・ゲートウェイではなくサービス・ゲートウェイを介してトラフィックを明示的に送信することを確認します。

たとえば、クラスタを作成してKubernetes APIエンドポイントのサブネットを指定し、パブリックIPアドレスをエンドポイントに割り当てない場合、接続の問題が発生する可能性があります。ルート表がインターネット・ゲートウェイに依存している場合、ワーカー・ノードは重要なOCIサービスにアクセスできない可能性があります。その結果、cloud-controller-managerコンテナの初期化に失敗し、ノードにテイントが残ることがあります。この問題を解決するには、NATゲートウェイまたはサービス・ゲートウェイを構成して、OCIサービスへの適切なアクセスを確保します。

回避方法

ネットワークの構成ミスの問題を解決するには、次をチェックしてワーカー・ノードがOCIサービス・エンドポイントと通信できることを確認します。

1. ネットワーク構成を確認します。VCN、サブネット、ルート表およびセキュリティ・リストがデプロイメント・シナリオの要件に従っていることを確認します。「ネットワーク・リソース構成例」を参照してください。

2. ゲートウェイ構成の確認:
   • パブリックKubernetes APIエンドポイント(パブリックIPアドレスを持つKubernetes APIエンドポイント):パブリックIPアドレスが割り当てられていること、およびインターネット・ゲートウェイへの必要なルートが存在することを確認します。
   • プライベートKubernetes APIエンドポイントの場合(パブリックIPアドレスのないKubernetes APIエンドポイント): OCIサービスへの接続にサービス・ゲートウェイが使用されていることを確認します。プライベート・サブネットからのインターネット・アクセスが必要な場合は、(インターネット・ゲートウェイではなく)NATゲートウェイを構成します。
   • デュアル・パスの回避:インターネット・ゲートウェイとサービス・ゲートウェイの両方を介して同じOCIサービス・トラフィックをルーティングしないでください。
3. ルート表構成の確認:
   • 正しいルート表がワーカー・ノードおよびKubernetes APIエンドポイント・サブネットに関連付けられていることを確認します。
   • ゲートウェイに必要なすべてのルート・ルールが存在することを確認します。
4. セキュリティ・リスト構成の確認:
   • ルールで必要なトラフィックが許可されていることを確認します。
   • 推奨: エンドポイント・サブネットにステートレス・ルールではなくステートフル・ルールを使用します。
5. DHCPオプションを確認します。カスタムDNSリゾルバを使用する場合は、169.254.169.254がDHCPオプションのエントリとして含まれていることを確認します。詳細は、DHCPオプションを参照してください。

構成の変更によって問題が解決されない場合は、クラスタの作成およびデプロイメントのためのネットワーク・リソース構成に対してネットワークをさらに確認してください。

この項で説明するように、Kubernetesバージョン1.34.1ではアップストリームの問題が多数識別されています。これらのアップストリームの問題は、Kubernetesバージョン1.34.2で対処されます。

Kubernetesクラスタを以前のバージョンからバージョン1.34.1にアップグレードする前に、Kubernetes環境がアップストリームの問題の影響を受けるかどうかを検討することをお薦めします:

• Kubernetes環境でStatefulSetsを実行しているワークロードを実行する場合は、Kube-Controller-Manager: コントロール・プレーンのアップグレード中にトリガーされたStatefulSetの誤ったロールアウトを確認してください。
• Kubernetes環境がkubeletメトリックに依存している場合は、kubelet_volume_stats_*メトリックがないを確認してください。
• Kubernetes環境でDRAリソースを使用する場合は、DRAドライバ接続がアイドル状態のときのKubeletデッドロックを確認します。

Kubernetes環境のアップグレードが、Kubernetesバージョン1.34.1のこれらのアップストリームの問題の影響を受ける場合、場合によってはアップグレードを実行しないことをお薦めします。かわりに、Kubernetesバージョン1.34.2をサポートするKubernetes Engineの本番リリースを発表してから、クラスタをKubernetesバージョン1.34.2にアップグレードするまで、クラスタをKubernetesバージョン1.33 (以前)の実行を維持してください。