クラスタのアクセスと管理

VPC環境で利用できます。

クラスタ作成を完了すると、Ncloud Kubernetes Serviceのダッシュボードでクラスタリストを確認でき、クラスタにアクセスできます。クラスタリストでクラスタの詳細情報確認 、ファイルの再設定、クラスタ削除などの個別クラスタと関連したタスクを実行できます。

NAVERクラウドプラットフォームコンソールの VPC 環境で、Services > Containers > Ncloud Kubernetes Service メニューを順にクリックすると、作成したクラスタのリストが表示されます。

クラスタアクセス

作成したクラスタに kubectlコマンドを用いてアクセスできます。

kubectlコマンドを使用してクラスタにアクセスする方法は、次の通りです。

1. NAVERクラウドプラットフォームコンソールの VPC 環境で、Services > Containers > Ncloud Kubernetes Service メニューを順にクリックします。

2. クラスタリストでアクセスするクラスタの行をクリックした認証方式に応じて設定ファイルを構成します。

   • Admin認証: [ダウンロード] ボタンをクリックしてクラスタの設定ファイルをダウンロードします。
   • IAM認証: [IAM認証ガイド] ボタンをクリックして ncp-iam-authenticatorをインストールした後、kubeconfigファイルを作成します。
   参考

   Admin認証は、2022年2月13日以前に作成したクラスタのみサポートします。

3. 以下の例のように kubectlコマンドに--kubeconfigオプションを使用してダウンロードした設定ファイルのパスを指定した後、実行します。

   $ kubectl --kubeconfig「設定ファイル」 get nodes
   

   参考

   $HOME/.kube/configパスに設定ファイルを直接追加する方法もあります。

4. 以下のリンクを参照し、使用中の OSに適した方法で環境変数を設定します。

   • Macまたは Linux OSで $KUBE_CONFIG 環境変数を設定

   $ export KUBE_CONFIG="${HOME}/Downloads/kubeconfig-1865.yaml"
   $ echo $KUBE_CONFIG
   /Users/user/Downloads/kubeconfig-1865.yaml
   
   $ kubectl --kubeconfig $KUBE_CONFIG get nodes
   

   • Windows Powershellで $KUBE_CONFIG 環境変数を設定

   > $KUBE_CONFIG=$HOME+"\Downloads\kubeconfig-1865.yaml"
   > $KUBE_CONFIG
   C:\Users\NAVER\Downloads\kubeconfig-1865.yaml
   > kubectl --kubeconfig $KUBE_CONFIG get nodes
   

   • Windowsコマンドプロンプトで $KUBE_CONFIG 環境変数を設定

   > SET KUBE_CONFIG=%USERPROFILE%\Downloads\kubeconfig-1865.yaml
   > kubectl --kubeconfig %KUBE_CONFIG% get nodes
   

正常に設定された場合、以下の例のように結果が表示されます。

NAME                  STATUS   ROLES   AGE
nks-pool-0000-w-001   Ready    node    5h22m
nks-pool-0000-w-002   Ready    node    5h22m
nks-pool-0000-w-003   Ready    node    5h22m

クラスタの詳細情報を見る

クラスタリストで個別クラスタの行をクリックすると、詳細情報を確認できます。

• [ガイドを見る] ボタンをクリックしてクラスタにアクセスする方法に関するガイドを確認できます。このガイドで説明する内容は、クラスタアクセスでより詳しく確認できます。
• Audit Log の右側にある [変更] ボタンをクリックして有効化の有無を変更できます。
  Audit Log を有効にすると、Cloud Log Analyticsでログを収集できます。ただし、有効にするにはまず Cloud Log Analyticsサービスを申し込む必要があります。(CLA ご利用ガイドを参照)

kubeconfigファイルの再設定

kubeconfig設定ファイルを再設定できます。再設定機能を使用する場合、既存のファイルはこれ以上使用できません。再設定で作成された新規設定ファイルをダウンロードして使用してください。

kubeconfig設定ファイルを再設定する方法は、次の通りです。

1. クラスタリストで、個別クラスタの行をクリックします。
2. クラスタの詳細情報タブで [再設定] ボタンをクリックします。
3. 認証ファイルを再設定するクラスタの名前を入力して後、 [再設定] ボタンをクリックします。

クラスタ削除

クラスタを削除する方法は、次の通りです。

1. クラスタリストで、削除するクラスタの行をクリックします。
2. クラスタリストの左上にある [削除] ボタンをクリックします。
3. 確認のポップアップでそのクラスタの名前を入力した後、 [削除] ボタンをクリックします。

クラスタ Autoscalerを使用する

クラスタ Autoscalerを使用して、クラスタを自動拡張や縮小できます。Autoscalerは、ユーザーがリクエストした Podのリソース量に比べて現在クラスタのリソースが不足している場合に自動でノードを増加させ、一定時間ノードの使用率が低く維持される場合にノード数を減少させます。

クラスタ Autoscalerを使用する方法は、次の通りです。

1. クラスタリストで、個別クラスタの行をクリックします。
2. クラスタの詳細情報タブに表示されるノードプールリストで Autoscalerを適用するノードプールの名前をクリックします。
3. [変更] ボタンをクリックします。
4. 設定ポップアップで [設定] ボタンをクリックした後、最小ノード数、 最大ノード数 を指定します。
5. [変更] ボタンをクリックします。

Autoscalerを使用する場合、以下の事項を考慮してください。

• Autoscaler機能を開始または停止するまで、1分から5分程度かかります。
• Autoscalerの使用中には手動でノード数を変更できません。そのため、ノード数を手動で変更するにはその機能を 未設定 に変更します。
• Autoscalerは、クラスタ内でその機能を設定したノードプールのみ適用されます。
• 以下のような場合、ノードの使用率が低くてもノード数は減少しません。
  • Controller(例: Deployment, StatefulSetなど)によって制御されない場合
  • Local Storageが設定されている場合
  • 他のノードに Podが移動できない場合
  • アノテーション "cluster-autoscaler.kubernetes.io/safe-to-evict" : "false"が設定されている場合

Autoscalerの特性に関する詳細は、Autoscaler FAQをご参照ください。

Autoscaler正常動作確認

Autoscalerが正常に動作するか確認するには、以下のコマンドを実行します。

$ kubectl --kubeconfig $KUBE_CONFIG get cm cluster-autoscaler-status -o yaml -n kube-system

正常に動作する場合の結果例は、次の通りです。

$ kubectl --kubeconfig $KUBE_CONFIG get cm cluster-autoscaler-status -o yaml -n kube-system

apiVersion: v1
data:
  status: |+
    Cluster-autoscaler status at 2019-09-03 08:59:53.84165088 +0000 UTC:
    Cluster-wide:
      Health:      Healthy (ready=1 unready=0 notStarted=0 longNotStarted=0 registered=1 longUnregistered=0)
                   LastProbeTime:      2019-09-03 08:59:53.70167178 +0000 UTC m=+23.846174142
                   LastTransitionTime: 2019-09-03 08:59:43.520248394 +0000 UTC m=+13.664750787
      ScaleUp:     NoActivity (ready=1 registered=1)
                   LastProbeTime:      2019-09-03 08:59:53.70167178 +0000 UTC m=+23.846174142
                   LastTransitionTime: 2019-09-03 08:59:43.520248394 +0000 UTC m=+13.664750787
      ScaleDown:   NoCandidates (candidates=0)
                   LastProbeTime:      2019-09-03 08:59:53.70167178 +0000 UTC m=+23.846174142
                   LastTransitionTime: 2019-09-03 08:59:43.520248394 +0000 UTC m=+13.664750787

    NodeGroups:
      Name:        k8s-default-group
      Health:      Healthy (ready=1 unready=0 notStarted=0 longNotStarted=0 registered=1 longUnregistered=0 cloudProviderTarget=1 (minSize=1, maxSize=5))
                   LastProbeTime:      2019-09-03 08:59:53.70167178 +0000 UTC m=+23.846174142
                   LastTransitionTime: 2019-09-03 08:59:43.520248394 +0000 UTC m=+13.664750787
      ScaleUp:     NoActivity (ready=1 cloudProviderTarget=1)
                   LastProbeTime:      2019-09-03 08:59:53.70167178 +0000 UTC m=+23.846174142
                   LastTransitionTime: 2019-09-03 08:59:43.520248394 +0000 UTC m=+13.664750787
      ScaleDown:   NoCandidates (candidates=0)
                   LastProbeTime:      2019-09-03 08:59:53.70167178 +0000 UTC m=+23.846174142
                   LastTransitionTime: 2019-09-03 08:59:43.520248394 +0000 UTC m=+13.664750787

kind: ConfigMap
metadata:
  annotations:
    cluster-autoscaler.kubernetes.io/last-updated: 2019-09-03 08:59:53.84165088 +0000
      UTC
  creationTimestamp: 2019-09-03T08:59:31Z
  name: cluster-autoscaler-status
  namespace: kube-system
  resourceVersion: "426558451"
  selfLink: /api/v1/namespaces/kube-system/configmaps/cluster-autoscaler-status
  uid: 248a8014-ce29-11e9-8a51-f220cd8c2e67

クラスタアップグレード

クラスタをアップグレードして内部管理マスター領域を真意バージョンにローテーションできます。アップグレード以降に追加するノードプールは、その後のバージョンが適用されます。アップグレード中には一時的にリソースの照会、変更、削除ができない場合があります。

アップグレード前の点検

クラスタをアップグレードする前に、以下の事項を確認してサービスに影響を与えかねない要素をチェックしてください。

• 新規バージョンの変更事項: Kubernetes changelogを参照して新規バージョンで変更された事項がサービスに影響を与える可能性はないか確認します。
• バージョンスキューポリシー: Version Skew Policyを参照して、クラスタとコンポーネントのバージョン間の互換性を確認します。
• Admission Webhook: クラスタ内に Webhookがある場合、アップグレード中にデッドロックに陥るおそれがあります。Dynamic Admission Controlを参照してアップグレード前に予め対策を講じてください。
• 利用可能なサーバの確保: 安定的なアップグレードのために、可用サーバを3つ以上確保します。
• kube-system Namespaceリソースバックアップ: nodelocaldns, coredns ConfigMapと同じ kube-systemリソースはアップグレード時に維持されず、新しいバージョンに置き換えられます。変更されたリソースがある場合、バックアップしてアップグレードを完了してから再適用します。

次の内容を参照して、アップグレードに関する詳細を設定できます。

• PodDisruptionBudget: Specifying a Disruption Budgetを参照して、クラスタのアップグレード中にもサービス中の Podを目的の割合または数で維持できます。
• Readiness Probe: Define readiness probesを参照して、ノードプールの取り換え中に Podが再配置される時、Podがサービス可能な状態である場合にのみ Ncloud Kubernetes Serviceリソースを通じてアクセスできるように設定できます。

アップグレード方法

クラスタをアップグレードする方法は、次の通りです。

1. クラスタリストで、アップグレードしたいクラスタの行をクリックします。
2. クラスタの詳細情報タブで、 [アップグレード] ボタンをクリックします。
3. 設定ポップアップ画面でアップグレードするバージョンを選択した後、クラスタの名前を入力します。
4. [アップグレード] ボタンをクリックします。

Control Planeに関する IP ACL構成

パブリック IPアドレスをベースに Kubernetes Control Planeに関するアクセスを制限できます。

Kubernetes Consoleで IP Access Control List(ACL)を変更するクラスタを選択した後、Endpoint > IP ACL変更ボタンをクリックします。

Default action

Control Planeにアクセスしたい場合、クライアントのパブリック IPアドレスが IP Access Control List(ACL)に登録されているルールによって許可や拒否去れない場合、Default actionに応じてアクセスをフィルタリングします。

IP ACL(Access Control List)

パブリック IPアドレスをベースに Kubernetes Control Planeに関する IP ACLを設定できます。
最大20個まで登録できます。

• アクセスソース: IPv4ベースの CIDR Blockを入力します。
• アクション: アクセスソース CIDRに該当する IPアドレスがアクセスする場合、処理する方法を選択します。
• メモ: 入力するルールに関するメモを作成できます。

Example

Case 1) パブリック IPアドレスに関するすべてのアクセスを遮断し、VPC内 VMインスタンスでのみ Kubernetes Control Planeにアクセスしたし場合

• Default actionを denyに設定
• IP ACLでは何のルールも登録しない

上記のように設定する場合、パブリック IPアドレスを利用したすべてのアクセスを遮断します。VPCネットワーク内の VMインスタンス環境で Control Planeにアクセスする場合はパブリック IPアドレスを使用せず、IP ACLの影響も受けません。

Case 2) 特定パブリック IPアドレス 143.248.142.77に関するアクセスを遮断し、他のパブリック IPアドレスのアクセスは許可したい場合

• Default actionを allowに設定
• IP ACLではアクセスソースを143.248.142.77/32に、アクションは denyに設定

上記のように設定する場合、143.248.142.77に関するアクセスは拒否するが、それ以外のパブリック IPアドレスは Default actionによりアクセスを許可します。