Login
      目次 x
      Ncloud Kubernetes Service のトラブルシューティング
        • 印刷する
        • PDF
        目次

        Ncloud Kubernetes Service のトラブルシューティング

          • 印刷する
          • PDF
          Article Summary

          VPC環境で利用できます。

          Ncloud Kubernetes Serviceの利用中にユーザーが遭遇しかねない問題状況や原因、解決方法をご案内します。ただし、一部の問題状況は以下の説明を熟知しても、ユーザーが直接解決するのが難しい場合があります。このようなユーザーの困難を効率的に解決するために、NAVERクラウドプラットフォームは問題解決に向けた様々な窓口も一緒に提供しています。トラブルシューティングを通じて解決できない場合、カスタマーサポートを通じて確認できます。

          Ncloud Kubernetes Serviceの設定と管理

          Q. Ncloud Kubernetes Serviceのクラスタが長時間作業中のままです。

          A. 新規クラスタの作成と削除、ノードプールスケールのインアウト、クラスタのアップグレード中に長時間作業中の状態を維持している場合は、NAVERクラウドプラットフォームのカスタマーサポートにて問題を確認し、解決できます。

          Q. Ncloud Kubernetes Serviceのクラスタを作成した後、Cilium-Operator Podが Pending状態です。

          A. Ncloud Kubernetes Serviceは CNIである Ciliumの安定した動作のために Operatorの数を2つに設定しています。したがってワーカーノードが1つのクラスタの場合、1つの Cilium Operatorが Pending状態になります。これは意図されたものであり、実際の Ciliumの動作に影響を与えません。Cilium-Operatorの Scaleを調整したり、ワーカーノードの数を増やして解決できます。

          Q. Ncloud Kubernetes Serviceのワーカーノードが Not Ready状態です。

          A. ワーカーノードが Not Readyの場合、様々な原因があります。その多くはワーカーノードの高いリソース使用量により発生します。ワーカーノードのリソース使用量を確認後、ワーカーノードに位置する Podを他のワーカーノードにスケジュールをするか、スケールを減らしてリソース使用量を減少させます。その後、ワーカーノードを再起動して Ready状態に変更されるか確認します。
          高いリソース使用量によりワーカーノードに問題が発生することを防ぐために、以下の Kubernetes機能の使用をお勧めします。

          Q. Evict状態の Podが作成されたり、作成中です。

          A. Kubernetesのコンポーネントである kubeletはノードのリソースをモニタリングします。監視対象ノードリソースがしきい値に達した場合、kubeletは積極的に Podを停止させてリソースを回収します。Evict状態の場合、kubeletが Podを停止させた状態を意味します。Podが Evict状態の場合、ノードのリソースを監視してしきい値以下に落とす必要があります。Ncloud Kubernetes Serviceのしきい値は、Kubernetesのデフォルト設定に伴います。その他の詳細については、以下の公式文書をご参照ください。

          Q. クラスタのアップグレード時にコントロールプレーンとワーカーノード間のバージョンスキューサポートポリシーについて教えてください。

          Ncloud Kubernetes Serviceは Kubernetesのバージョンスキューサポートポリシーに従います。Kubernetesはコントロールプレーンとワークノード間の一定のバージョン差を許可しています。詳細なポリシーは、公式文書で確認できます。

          Ncloud Kubernetes Serviceリリース

          Q. Podを作成すると、ImagePullBackOff状態が発生します。

          A. ImagePullBackOff状態は、Podが使用するイメージの取得に失敗して発生します。以下の内容で原因を把握して解決できます。

          • イメージおよびタグが正しくない場合、イメージを取得できません。
          • プライベートレジストリからイメージを取得時、適切な認証を実行できない場合はイメージを取得できません。適切な imagePullSecretsを使用しているか確認が必要です。Container Registryのサービスを利用中の場合、ご利用ガイドを通じて imagePullSecretsを作成できます。
          • Private Subnetを使用する Kubernetes Clusterの場合、イメージを使用するためにアウトバウンドトラフィックを有効になっている必要があります。有効になっていない場合、以下の手順を行います。

            • NAT Gateway(Old)の場合

              • コンソール > VPC > NAT Gateway(Old)メニューに移動し、NAT Gatewayを作成
              • コンソール > Products & Services > Networking > VPC > Route Tableメニューに移動
              • インターネット通信が必要な Private Subnetのルーティングテーブルを選択し、 [Routes設定] ボタンをクリック
              • 外部通信のためのルーティングルールを追加
                • Destination: 目的地のグローバル IPアドレスを CIDR形式で入力(例えば、インターネット全体が通信対象である場合は0.0.0.0/0と入力)
                • Target Type: 目的地と通信を行うためのネクストホップのタイプを選択(NAT Gateway)
                • Target Name: 作成した NAT Gateway名を選択
                • [作成] ボタンをクリックし正常にルールを追加および反映

            • NAT Gateway(New)の場合

              • コンソール > VPC > Nat Gateway(New)メニューに移動し、NAT Gatewayを作成
              • コンソール > VPC > Route Tableメニューに移動し、NAT Gatewayを介して通信するネットワークパスを設定
          • DockerHubイメージダウンロードポリシーにより阻止された場合、イメージを正常に利用できません。大量利用のための支払いアカウントを使用するか、プライベートレジストリを利用します。

          Q. 特定の Podで断続的に DNS照会に失敗したり長時間かかります。

          A. DNS照会に失敗したりクエリ処理に問題がある場合、その Podが使用するイメージの確認が必要です。

          上記の2つのイメージを使用する場合、DNSクエリ処理に問題が発生する可能性があります。イメージ内部の不具合である場合、NAVERクラウドプラットフォームでは解決できないため、他のコンテナイメージを使用するか、DNS設定の修正を通じた問題解決が必要です。

          Ncloud Kubernetes Serviceネットワーク

          Q. 作成していない Target Groupが存在します。

          A. ALBとマッピングした Ingress Manifest内の spec.defaultBackendが指定されていない場合、ワーカーノードグループの80ポートに設定された Target Groupを作成します。この Target Groupは ALBの動作に影響を与えず意図した動作です。

          Q. Ncloud Kubernetes Serviceクラスタにより作成されたロードバランサが削除できません。

          A. Global DNSにロードバランサを登録した場合、ロードバランサは削除できません。Global DNSでそのロードバランサの登録有無を確認した後、設定解除時にそのロードバランサの削除が行われます。
          この制約条件は改善される予定です。

          Q. NetworkPolicyが正常に作動しません。

          A. Cilium CNIを使用する場合、NetworkPolicyの機能の中には、以下のように既知の未対応機能があります。

          Q. Ciliumの Connectivity Testに失敗します。

          A. Ciliumでは、network状態をテストするための Connectivity Testセットを提供します。Ncloud Kubernetes Serviceでこのテストセットそのまま実行する場合、以下の2件のテストに失敗します。
          image.png
          これは link-local ipにバインドされた node-local-dnsを使用する場合に発生する既知の不具合です。有効な DNSリゾルビングのために以下のように CiliumNetworkPolicyで toCIDRフィールドに node-local-dnsが使用する IPアドレス帯域を追加する必要があります。

          # pod-to-a-allowed-cnp
  egress:
  - toPorts:
    - ports:
      - port: "53"
        protocol: ANY
    toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns
    toCIDR:
    - 169.254.25.10/32

# pod-to-external-fqdn-allow-google-cnp
  egress:
  - toPorts:
    - ports:
      - port: "53"
        protocol: ANY
      rules:
        dns:
        - matchPattern: '*'
    toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns
    toCIDR:
    - 169.254.25.10/32

          Q. LoadBalancerタイプのサービスリソースを作成した後、Pending状態を維持しています。

          A. クラスタ作成時に選択したロードバランササブネットを削除したり、割り当て可能な IPアドレスがない場合 External-IPアドレスは割り当てられません。以下の手順により、デフォルトのロードバランササブネットを変更するか、他のロードバランササブネットを選択します。

          • デフォルトのロードバランササブネットを変更します。

            • 以下のコマンドを実行して kube-system Namespaceで ncloud-configという名前を持つ configmapを確認します。
            $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system
$ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml
            • 以下を参照して kube-system Namespaceで ncloud-configという名前を持つ configmapを確認し、修正します。
            $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system
  NAME            DATA   AGE
  ncloud-config   9      131m

$ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: ncloud-config
    namespace: kube-system
  data:
    acgNo: "12345"
    apiUrl: https://nks.apigw.ntruss.com
    basePath: /ncloud-api/v1
    lbPublicSubnetNo: "98765"
    lbSubnetNo: "12345"
    regionCode: KR
    regionNo: "11"
    vpcNo: "12345"
    zoneNo: "110"
            • data.acgNo: ワーカーノードの eth0インターフェースに割り当てられた acgの instanceIDを入力します。
            • data.apiUrl: https://nks.apigw.ntruss.comを入力します。
            • data.basePath: /ncloud-api/v1を入力します。
            • data.lbPublicSubnetNo: ワーカーノードが割り当てられた VPC内の Load Balancer専用 Publicサブネットの SubnetIDを入力します。
            • data.lbSubnetNo: ワーカーノードが割り当てられた VPC内の Load Balancer専用 Privateサブネットの SubnetIDを入力します。
            • data.regionCode: ワーカーノードが位置するリージョンコードを入力します。(例: 「FKR」)
            • data.regionNo: ワーカーノードのリージョン番号を入力します。(例: 「11」)
            • data.vpcNo: ワーカーノードが割り当てられた VPCの IDを入力します。
            • data.zoneNo: ワーカーノードが位置するゾーン番号を入力します。(例: 「110」)
            • 以下のコマンドを実行して Load Balancer専用のサブネットを変更します。
            $ kubectl --kubeconfig $KUBE_CONFIG -n kube-system patch configmap ncloud-config --type='json' -p='[{"op":"replace", "path":"/data/lbSubnetNo", "value": "94465"}]'
            • サンプルサブネット IDとして94465を使用したコマンドです。
            • Kubernetesワーカーノードを作成した VPC内の Load Balancer専用サブネットの SubnetIDを使用します。有効でない SubnetIDを使用する場合、サブネットの変更後に Load Balancerは正常に作成できません。
            • 変更完了後に以下のコマンドを実行し、configmapに変更事項が適用されたか確認します。
            $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml

          Q. Ingressと接続した ALB(ApplicationLoadBalancer)が正常に作成されなかったり、動作しません。


          A. 以下の解決方法は ALB Ingress Controllerによって作成した ALBの場合に該当します。以下のコマンドを実行して、関連リソースとログを照会します。

          $ kubectl --kubeconfig $KUBE_CONFIG logs -n kube-system -l app.kubernetes.io/name=alb-ingress-controller
$ kubectl --kubeconfig $KUBE_CONFIG describe ingress [ingress-name]
          • ALB Ingress Controllerが存在しない場合、ALBは作成できません。ALB Ingress Controller設定ガイドを参照して ALB Ingress Controllerをクラスタにインストールします。
          • Ingress Manifestにエラーがある場合、ALBや関連ルールを作成しません。ALB Ingress Controllerの Podログ照会により原因を確認します。
            • Manifest内のルールと作成した ALBのルールが一致しない場合
            • 有効なアノテーションを使用していない場合
            • Manifestルールに記載されたサービスの名前とポートが間違えて記載されている場合
            • ルールの順序が正しくない場合(最上段のルールを一番先に適用)
          • 作成した ALBをコンソールまたは APIにより変更する場合、問題が発生します。ALB Ingress Controllerにより作成した ALBの場合、Kubernetesクラスタ内に登録した Ingressの Manifestと定期的に同期します。なるべくコンソールおよび APIによる変更は避け、変更時は Manifestの再適用により同期します。

          Q. Client IPアドレスを確認したいです。

          A. Ncloud Kubernetes Serviceにより作成できるロードバランサは NetworkLoadBalancer(NLB)、NetworkProxyLoadBalancer(NPLB)、ApplicationLoadBalancer(ALB)です。ロードバランサの種類によって Client IPアドレスの確認方法が異なります。

          • ALB: HTTP/HTTPSプロトコルを使用するため、アプリケーションで X-Forwarded-Forヘッダを通じてクライアント IPアドレスを確認できます。
          • NPLB: proxy-protocolを有効にすることで、Client IPアドレスを確認できます。サービスの明細内訳に関連アノテーションの記載が必要であり、アプリケーションでも proxy-protocol関連設定を有効になっている必要があります。例えば、nginx-ingress-controllerを使用する場合、nginx-ingress-controllerの proxy-protocol設定を有効になっている必要があります。
          • NLB: NLBの場合はロードバランサで Client IPアドレスが表示されますが、クラスタ内部での設定が必要です。サービスの明細内訳で「externalTrafficPolicy」を「Local」に変更して、Client IPアドレスを確認できます。「externalTrafficPolicy」の設定内容は公式文書で確認できます。

          Q. カーネルパラメータの変更後、クラスタでパケットドロップが発生します。

          A. Ncloud Kubernetes Serviceの CNIである Ciliumの起動時に動的に「rp filter」を無効にします。sysctl.confファイルの設定は変更しないため、ワーカーノードの特定のカーネルパラメータを変更するために sysctl.confファイルを適用する際に注意が必要です。もし Cilium設定と一致しない場合、パケットドロップが発生する場合があります。syctl.confファイルの変更および適用時に rp filter関連設定の「net.ipv4.conf.all.rp_filter」を「0」に修正してから適用する必要があります。他にもカーネルパラメータの変更時に注意が必要であり、判断が困難な場合は NAVERクラウドプラットフォームのカスタマーサポートまでにお問い合わせください。

          Q. ALB作成時にターゲットグループの設定を変更したいです。

          A. Ingressのバックエンドとして指定される Serviceの明細を変更して設定することができます。アノテーションを使用すると、Serviceを通じて作成されるターゲットグループのロードバランシングアルゴリズム、Health Checkの設定が可能です。
          例えば、下記のように指定すると、「naver」 Serviceを通じて作成されたターゲットグループは、least-connectionアルゴリズムを通じてロードバランシングが行われます。

          apiVersion: v1
kind: Service
metadata:
  annotations: 
    alb.ingress.kubernetes.io/algorithm-type: "least-connection"
  name: naver

          Service、Ingressで使用可能なアノテーションの場合、ALB Ingress Controller設定で確認できます。

          Ncloud Kubernetes Serviceセキュリティ

          Q. ncp-iam-authenticatorを通じて Kubernetes Clusterにアクセスできません。


          A. ncp-iam-authenticatorの利用中に発生するエラーメッセージで原因を分析できます。

          • Cluster is undefined (400): 無効なクラスタ UUIDが入力された時に発生します。
          • Authentication Failed (200): 無効な認証キーを使用した時に発生します。ncp-iam-authenticatorは、~/.ncloud/configure以下の認証キーを使用して有効期限切れになった認証キー、削除した認証キー、使用中止された認証キー、誤って記載した認証キーではないかを確認します。
          • Not Found Exception (404): ncloud_api_urlと regionキーを確認します。
          • You must be logged in to the server (Unauthorized): アカウント(サブアカウント)がクラスタに関連する権限を持っていないときに発生します。クラスタの作成時にメインアカウント、クラスタ作成アカウントは system:mastersグループに自動的に設定され、それ以外のアカウントは別途の権限を設定します。IAM認証ユーザー管理によりアクセスアカウントの権限設定を行います。

          Ncloud Kubernetes Serviceの拡張性とパフォーマンス

          Q. Cluster AutoScalerを設定しましたが Scale Up/Downが発生しません。

          A. Ncloud Kubernetes Serviceで提供する Cluster Autoscalerクラスタ内に、リソース不足によりスケジューリングされなかった Podが存在する場合にノードを増加させ、一定時間特定ノードの使用率が低い場合にノードを減少させます。Cluster Autoscalerが動作しない原因はいろいろ考えられます。

          • 使用している Podに Resource Request Limit設定が存在しない場合は動作しません。必ず Resource Request&Limit設定が必要です。
          • HPA(Horizontal Pod Autoscaling)の設定がない場合は動作しません。HPAにより Podが増加し、作成された Podのリソースリクエスト量に応じて Cluster Autoscalerが動作します。HPA設定を行うと Cluster Autoscalerが動作するようになります。
          • ノード減少の例外が存在する場合、ノードの減少が行われない可能性があります。以下のような例外事項が存在します。
            • Controller(例: Deployment StatefulSet ..)によって制御されない場合
            • Local Storageが設定されている場合
            • 他のノードに Podが移動できない場合
            • Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"が設定されている場合
            • その他の例外事項については、公式文書をご参照ください。

          Q. 手動でノードプールを縮小する際に特定ノードを削除したいです。

          A. ノードプールを手動で縮小する際に優先順位に従って手順が決まります。

          • 停止状態のノード
          • 作成日が古いノード

          特定のノードを削除したい場合、 Kubernetes Service > Node pools > Node Poolの詳細 > ノード削除 ボタンをクリックするか、そのノードを停止した後にノード数を変更して行えます。

          Q. Cluster AutoScalerを使用する際にパラメータを変更したり確認したいです。

          A. Cluster AutoScalerの設定時は基本パラメータを使用し、変更は提供しません。Cluster AutoScalerで使用されるパラメータおよび基本値は以下の文書から確認できます。

          Ncloud Kubernetes Serviceモニタリングとロギング

          Q. Kubernetes Dashboardにアクセスする際にリソースの照会ができません。


          A. Ncloud Kubernetes Serviceで提供する Dashboard(Kubernetes Dashboard)のアクセス権限はクラスタ内部の権限と同じです。NAVERクラウドプラットフォームのメインアカウントとクラスタ作成アカウント(サブアカウント)は、Admin権限を持っており、他の作業を行うことなく Dashboardにアクセスできます。しかしその他のサブアカウントはクラスタ使用権限を持っている必要があります。

          クラスタ権限を付与する方法は、ガイド文書にて確認できます。

          この記事は役に立ちましたか?
          What's Next
          Change password!
          Changing your password will log you out immediately. Use the new password to log back in.
          Change profile
          Success!
          First name must have atleast 2 characters. Numbers and special characters are not allowed.
          Last name must have atleast 1 characters. Numbers and special characters are not allowed.
          Enter a valid email
          Enter a valid password
          Your profile has been successfully updated.
          Logout