Login
      目次 x
      クラスタへのアクセスと管理
        • 印刷する
        • PDF
        目次

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

          • 印刷する
          • PDF
          Article Summary

          VPC環境で利用できます。

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

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

          クラスタへのアクセス

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

          kubectlコマンドを使用してクラスタにアクセスする方法は以下のとおりです。

          1. NAVERクラウドプラットフォームコンソールのVPC環境でServices > Container > Ncloud Kubernetes Serviceメニューを順にクリックします。
          2. クラスタリストでアクセスするクラスタの行をクリックし、そのクラスタの認証方式に応じて設定ファイルを構成します。
            • Admin認証：[ダウンロード] ボタンをクリックし、クラスタの設定ファイルをダウンロードします。
            • IAM認証：[IAM認証ガイド] ボタンをクリックしてncp-iam-authenticatorをインストールし、kubeconfigファイルを作成します。
          3. 以下の例のようにkubectlコマンドに--kubeconfigオプションを使用してダウンロードした設定ファイルのパスを指定し、実行します。
            $ kubectl --kubeconfig "設定ファイル" get nodes
          参考

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

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

            • MacまたはLinux OSで$KUBE_CONFIG環境変数を設定
            $ export KUBE_CONFIG="${HOME}/Downloads/kubeconfig-1865.yaml"
$ echo $KUBE_CONFIG
/Users/azamara/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を参照して新規バージョンで変更された事項がサービスに影響を与える可能性はないか確認してください。
          • Admission Webhook：クラスタ内にWebhookがある場合、アップグレード中にデッドロックに陥るおそれがあります。Dynamic Admission Controlを参照してアップグレードの前にあらかじめ措置を講じてください。
          • 使用可能なサーバの確保：安定的なアップグレードのために、使用可能なサーバを3台以上確保してください。

          以下を参考にして、アップグレードに関連する詳細事項を設定することができます。

          • PodDisruptionBudget：Specifying a Disruption Budget for your Applicationを参考にし、クラスタのアップグレード中にもサービス中の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アクセス制御リスト（IPACL）を変更するクラスタを選択し、[Endpoint]> [IP ACLを編集する]ボタンをクリックします。

          vnks_ip_acl_ja

          Default action

          Control Planeにアクセスしたいクライアントの認定IPが、アクセス制御リスト（ACL）に登録されているルールによって許可または拒否されていない場合は、デフォルトアクションに従ってアクセスをフィルタリングします。

          IP ACL( Access Control List)

          認定 IP アドレスに基づいて Kubernetes Control Plane の IP ACL を設定できます。
          最大20個まで登録可能です。

          • アクセスソース：IPv4ベースのCIDRブロックを入力します。
          • アクション：アクセスソースCIDRに対応するIPがアクセス時に処理する方法を選択します。
          • メモ：入力するルールのメモを作成できます。

          Example

          Case 1）認定アイピーへのすべてのアクセスをブロックし、VPC内のVMインスタンスでのみKubernetes Control Planeにアクセスしたい場合

          • Default actionをdenyに設定します。
          • IP ACL にはルールを登録しない。

          上記のように設定すると、認定アイピーを使用したすべてのアクセスがブロックされます。 VPC ネットワーク内の VM インスタンス環境で Control Plane にアクセスする場合は、認定アイピーを使用せず、したがって IP ACL の影響を受けません。

          ケース2）特定の認定アイピー143.248.142.77へのアクセスをブロックし、他の認定アイピーがアクセスを許可したい場合

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

          上記のように設定すると、143.248.142.77へのアクセスは拒否されますが、残りの正規アイピーはDefault actionによってアクセスが許可されます。

          この記事は役に立ちましたか?
          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