初心者向けガイド

概要

このガイドでは、KubernetesおよびDocker環境に展開されているWebアプリケーションにNorth-Southトラフィックを負荷分散する方法を理解するための展開例について説明します。また、KubernetesのWebアプリケーションのフロントエンド、バックエンドサービス間でEast-Westトラフィックをどのように負荷分散するかについて詳しく説明しています。

展開例は、次のコンポーネントで構成されています。

  • マスターノードおよびワーカーノードの2つのノードを持つKubernetesクラスター。

  • KubernetesクラスターのEast-Westトラフィックで負荷分散を行うNetScaler CPXの単一インスタンス。

  • WebアプリケーションへのIngressトラフィックで負荷分散を行うNetScaler VPXアプライアンスの単一インスタンス。

  • Ingressコントローラーとして使用するNetScaler MASサーバー上の単一インスタンス。

  • Webアプリケーション用のフロントエンドサービス( hotdrinks.beverages.com )。

  • Webアプリケーション用の2つのバックエンドサービス( coffeeおよびtea )。

次の表は、コンポーネントのバージョンです:

コンポーネント バージョン
Kubernetes v1.11.1
NetScaler CPX 12.0.58.15
NetScaler VPXアプライアンス 12.0.58.15

前提条件

NetScaler MASサーバーのフィンガープリントをコピーする

NetScaler Management and Analytics System(MAS)で、NetScaler MASサーバーのフィンガープリントをコピーするには、次の手順を実行します。

  1. NetScaler MASにログオンします。

  2. [System]>[System Administration] に移動して [View SSL Certificate] をクリックします。

  3. [Certificate Details] ページの [Fingerprint] フィールドから、NetScaler MASサーバーのフィンガープリントをコピーします。

    Fingerprint

NetScaler MASでKubernetesクラスターの詳細を構成する

Kubernetes環境でIngressコントローラーとしてNetScaler MASを使用するには、NetScaler MASでKubernetesクラスターの詳細を構成して、NetScaler MASとKubernetesクラスターを統合する必要があります。

前提条件

以下を用意してください:

  • kube-apiserverのURL。Kubernetesノードに次のコマンドを入力して、kube-apiserverのURLを取得します:

     root@ubuntu:~# kubectl cluster-info
     Kubernetes master is running at https://10.102.29.101:6443
     KubeDNS is running at https://10.102.29.101:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
    
  • Kubernetesに認証するための認証資格情報。基本認証、トークンベースの認証、またはクライアントベースの認証を使用できます。

    クライアントベースの認証を使用する場合は、Kubernetesのクライアント証明書およびクライアントキーの詳細を使用する必要があります。クライアント証明書とクライアントキーの詳細は、 /etc/kuberenetes/admin.confファイルにあります。クライアント証明書とクライアントキーの詳細を取得するには、次のコマンドをそれぞれ入力します:

     root@ubuntu:~# cat /etc/kubernetes/admin.conf | grep client-certificate
     client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM4akNDQWRxZ0F3SUJBZ0lJSlhueXNZSUJsa1V3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB4T0RBNE1UQXhNakE0TWpsYUZ3MHhPVEE0TVRBeE1qQTRNelphTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXp3R3VCemduaUVlTmt2cjYKQjY2RWl2bHN5Vll2SXdSNk5YRm91YXZ3SUtXYkNiLzl3bk5sWHNkY2pMYlZ1M09kOHk4SXZEVlpjZFJVL2RXbQp2ampXa3hzSENJRW12ODJZNE5VeW56V3ZxeTVibDdFeS9pb1Nsb1JGU0wwa1oyZ0o3RkgwbEhSU2IrOEMxVlRWCi9zTDhTMlRseHJKcUQ0RHlNWS9IeDlwMFBIWVN3Y1dXRGlWckNtbnpPSHlIK1MyVURjNllTc0xvYXlxclV2Y08Ka05TMjJPZ3hLUGJRUTFZMStLcFNLODBGR0lGdFJOWFEzaFlrNnNSRk5PMnI1NU5TVjhTUE4yYTAzWGFOTERxVgpWUUpyUGhOVE51VUw3WkNlbmxubExZUXRnVE5RMkQ4TmJ5cTJXdWxaU2xmZTJScmNXZUt2NHNYanN5MDZGK3dpClBiMWkrd0lEQVFBQm95Y3dKVEFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFKNlZjSGxJVTMzUVhWWVdDZTFONElITmhNNWxVem5mZnN4egpYSy9oTkc2V0Q3eVhscVhRVEpUalhPbnRISFVvY0Q3UGRUaG5tYUV5a0NHTDdMZVZmVEtjU3BsdnVrbXhZdDJkClh5VHFYeStPdmszRHMwUmY1QnNYRXBxTGN1VDE1Q2xWYW5MaEpuOGdxYkIxbk12bkNIMnFXT3VjNUR4cVNGMFYKYXdxOVZiekE5bkRvdzNLSml2d0ZxWWNpaENxSHQ1cENyQ2VOaFJHTGZnaEc0UUJDRENudnRML1NlR2x5WGMxWgozQWQ4eDZVSmxGS1ZXaklaWThKTGRzZjdicUxyRmswVVVrMHdGeUtrY1RtY1BNaTE1UEY5aDgwOHluLzU3Sy9ICmNHMVdadFE0U3R5czRyTUFwc0RXcStWZXVzSlhQd1VNVVo4TEtwc0sybFF5U2tBdWZCUT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    
     root@ubuntu:~# cat /etc/kubernetes/admin.conf | grep client-key
     client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBendHdUJ6Z25pRWVOa3ZyNkI2NkVpdmxzeVZZdkl3UjZOWEZvdWF2d0lLV2JDYi85CnduTmxYc2RjakxiVnUzT2Q4eThJdkRWWmNkUlUvZFdtdmpqV2t4c0hDSUVtdjgyWTROVXlueld2cXk1Ymw3RXkKL2lvU2xvUkZTTDBrWjJnSjdGSDBsSFJTYis4QzFWVFYvc0w4UzJUbHhySnFENER5TVkvSHg5cDBQSFlTd2NXVwpEaVZyQ21uek9IeUgrUzJVRGM2WVNzTG9heXFyVXZjT2tOUzIyT2d4S1BiUVExWTErS3BTSzgwRkdJRnRSTlhRCjNoWWs2c1JGTk8ycjU1TlNWOFNQTjJhMDNYYU5MRHFWVlFKclBoTlROdVVMN1pDZW5sbmxMWVF0Z1ROUTJEOE4KYnlxMld1bFpTbGZlMlJyY1dlS3Y0c1hqc3kwNkYrd2lQYjFpK3dJREFRQUJBb0lCQUNwWUw1OHViM2ZERzBTNwpyald3RDFEV1lOaDJsc0hWQXFLNEJqSWs1OFBsM0djTUxQNS8ySGFnMVYrN2J0RWZmMm5sYnlZQXk4RXJMQStZCmlybFNxeUlBWDFud0FWc3UxVno0ZjVodHhQZUJUaDhqa2tqSGxuSFBzTlNHVEZJU3lDVGRSdWl2T3NYRzRJOS8KQVI5U0I0WHNwOHdUWnZxdzU5b1hqVWhtZVd4OFpDby9LRmdVcTBUQkJIQ1lDYlk1LzhWOFVjaU5tOHN1YVE0LwowQWhnMjV3a0l2S3kwZWp3bEpsYVZPK2doenlTeGQ4L0NPemc2YTJqYXBBeGczR05sS2diR2lVL3lHck1XVnY1Cjc1WmtGS0FRTm1IY296UDhaMGFLc3BFV3ZUZEVZVVFEaWQwUG5OSk9aRE9JQ2l4VUMvR2sycjhsL0tzaVpTSU4KempHeUFwRUNnWUVBMDZEQ08xMUx1THNVQURZUlVOM29FcmJoRndZR2RVKzlNc2pGVnNIeG9xTGE3QUVjQTZYTgpXS09zaHV4dktHMDlqTXJDWGJkNXBpL1dJWEErUytJVitobGVDVWdRV0dLWnFVQXhCak1VMlI1MGJtTWpSOE1wCjMyU3ZRZ1NmVGJvVThTZXNzajFvSVZEeG5IQk9PLzZwRWdVT09WVU5jUWFxR1NtLzhLcEduQjhDZ1lFQSttamQKYXlDN3NLMjlsRU5NTXBoSGFqU0Q0VmV3M3ZJamFZNVhMY2QxOXcwNnhpYmR1bnFVYUVaMThLTmM5NUsrN0NuSApoV2grenpDZDIwbWhJdTZyWm1zK0NQYm1sSDhNb0l1ZHlqOU55M3drdjIrWkw2bnVkT3lPeGpsVWJUMkZaNzJlCk1yTVdkQ2hFMWwySEVGZWlHUXo1enFtQ21kWlpwYTA2Z3NnTTNhVUNnWUFkOXBIcGs5RUh5NzBPTnBtSENKUTIKS2h4K2hRVGZFVFlwZlpHck1mU0RZV2w3cHNDUHA2Y0dXTTR4b0VJd3lCN0IwMmRubTNXbTJQa0piUG4xQm9LMApFV2xtQ1FUL2JwNXcvenl4c3dQTnBlazRRK01YNHdNSHRScTNUeTQ2OUJESkFDUU1iSE5VM0VBSk5VRnVieVVDCi95SS9iZEprWVZ3dUNlSTZNZkdqWXdLQmdRQ1dzREErWFU1VlBkaE50a25PVUpENU9tejZXQmpac1FEYWJvdkwKd3JJY1gxdTFEb0p6eTN3dlcrZHhUZjJPQmtMYVB6SVArQmdIZW93a0FDVDFyb1o2ZGFLNUprc1BwWHpseDk3RwpiRjNXUy9pWk13RU9DOGF4bWdFNURCcmdPaHRqbUZud3pKQ0FpaE1TcE9tNFRlUUFDeXp3emxVSFdsUk1QUGh1CjV3L0crUUtCZ0RzdEN2WVMzNVlBR3IrM25FR0Z4Y2cwdlpQdmtxVGxhUmpIRlcrZDhGYkNLWUZPQWRLUTk4TUwKcThTUzI1dVRqWUlITDJrS04vK0NnVUt2TUYxSFFNbzE0UmEzS2NTT2NoOFhCWitTazllRWRqL2dyaGRvd0FORgpkZFVBSEhMdzY5NWd6ZkZ3bkdTQWgyVWRZdTdVL3RxZlBOUGphRnJVbHVDc3NPaW95bmN5Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
    

NetScaler MASでKubernetesクラスターを構成するには:

  1. 管理者資格情報を使用して、NetScaler MASサーバーGUIにログオンします。デフォルトの管理者資格情報は、nsroot/nsrootです。

  2. [Orchestration]>[Container Orchestration] に移動します。

  3. [Container Orchestration] ペインで [Kubernetes Configuration] を選択し [Continue] をクリックします。

    Container Orchestration

  4. [Cluster Setting]セクションで、kube-apiserverのURLを[API Server URL] フィールドに入力します。通信にデジタル証明書を使用している場合は、 [Server Certificate Validation] チェックボックスをオンにして、[CA] フィールドに証明書パスコードを入力します。

  5. [User Settings]セクションでは、次のいずれかの認証方法を選択できます:

    • 基本認証[Username] フィールドにホストマシンのユーザー名を入力します。

    • トークンベースの認証[Token] フィールドにトークンを入力します。

    • クライアント認証[Client Certificate] および [Client Key] フィールドに、それぞれクライアント証明書とクライアントキーの詳細を入力します。

  6. [OK] をクリックします。

    Container Orchestrationの構成

NetScaler CPXでKubernetesのEast-Westトラフィックの負荷分散を構成する

NetScaler CPXインスタンスをデーモンセットとしてKubernetesクラスターに展開して、クラスター内のコンテナー化されたアプリケーションを負荷分散できます。NetScaler CPXインスタンスをデーモンセットとして展開すると、NetScaler CPXインスタンスはノード上にポッドとして展開され、Kubernetesクラスターに参加する新しいノードごとに自動的にポッドとして展開されます。

NetScaler CPXインスタンスを展開する前に、マスターノードでNetScaler CPXインスタンスのサービスアカウントを作成してください。次のYAMLファイルを使用してサービスアカウント、 cpxを作成できます:

Sample: serviceaccount.yaml

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: cpx
rules:
  - apiGroups: [""]
    resources: ["services", "endpoints", "ingresses", "pods", "secrets"]
    verbs: ["*"]

  - apiGroups: ["extensions"]
    resources: ["ingresses", "ingresses/status"]
    verbs: ["*"]

---

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: cpx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cpx
subjects:
- kind: ServiceAccount
  name: cpx
  namespace: default
apiVersion: rbac.authorization.k8s.io/v1

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cpx
  namespace: default

kubectl create -f <yaml>コマンドを使用して、YAMLファイルを展開し、サービスアカウント、cpxを作成します。

例:

kubectl create -f serviceaccount.yaml

kubectl get saコマンドを使用して、cpxサービスアカウントが作成されたかを検証します。

例:

root@ubuntu:~# kubectl get sa
NAME      SECRETS   AGE
cpx       1         2d
default   1         19d

NetScaler CPXインスタンスをデーモンセットとして展開するには、YAMLファイルかJSONスクリプトを作成する必要があります。ファイルまたはスクリプトには、コンテナーの種類、CPXイメージファイル名、NetScaler MASサーバーのIPアドレス、およびNetScaler MASサーバーのフィンガープリントを指定します。

以下は、NetScaler CPXインスタンスを展開するためのYAMLファイルの例です。

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: cpx
spec:
  template:
    metadata:
      name: cpx
      labels:
        app: cpx-daemon
      annotations:
        NETSCALER_AS_APP: "True"
    spec:
      serviceAccountName: cpx
      hostNetwork: true
      containers:
        - name: cpx
          image: "cpx:12.0-58.15"
          securityContext:
             privileged: true
          env:
          - name: "EULA"
            value: "yes"
          - name: "NS_NETMODE"
            value: "HOST"
          - name: "kubernetes_url"
            value: "https://10.102.29.101:6443"
          - name: "NS_MGMT_SERVER"
            value: "10.106.73.237"
          - name: "NS_MGMT_FINGER_PRINT"
            value: "E9:AA:2C:BC:47:DF:AC:A2:02:A6:1C:2F:8B:64:AC:61:10:ED:72:4B"
          - name: "NS_ROUTABLE"
            value: "FALSE"
          - name: "HOST"
            valueFrom:
               fieldRef:
                  fieldPath: status.hostIP
          - name: "KUBERNETES_TASK_ID"
            valueFrom:
               fieldRef:
                  fieldPath: metadata.name
          volumeMounts:
          imagePullPolicy: Always

次の表では、サンプルデーモンセットで使用されているセクション、パラメーター、および環境変数について説明しています:

セクション パラメーター 説明
container name NetScaler CPXコンテナーの名前。
  image コンテナーを作成するためのイメージを指定します。
SecurityContext privileged: true NetScaler CPXコンテナーが特権モードで実行されるように指定します。
  name: “EULA” NetScaler CPX専用の環境変数。「https://www.citrix.com/products/netscaler-adc/cpx-express.html」のエンドユーザーライセンス契約書(EULA)を読んで同意したことを検証するために必要です。
  name: “NS_NETMODE” NetScaler CPX固有の環境変数で、NetScaler CPXインスタンスがホストモードで起動するように指定できます。インスタンスがホストモードで起動すると、インスタンスへの管理アクセスのために、ホストマシン上に4つのデフォルトiptable規則が構成されます。次のポートを使用します:HTTPは9995、HTTPSは9996、SSHは9997、SNMPは9998です。また、異なるポートを指定する場合は、-e NS_HTTP_PORT、-e NS_HTTPS_PORT、-e NS_SSH_PORT、-e NS_SNMP_PORTという環境変数を使用できます。
  name: “kubernetes_url” Kubernetes URLを指定するNetScaler CPX固有の環境変数。
  name: “NS_MGMT_SERVER” NetScaler MASサーバーのIPアドレスを記述するNetScaler CPX固有の環境変数。NetScaler CPXインスタンスが展開されると、このIPアドレスのNetScaler MASサーバーに自動的に登録されます。
  name: “NS_MGMT_FINGER_PRINT” NetScaler MASのフィンガープリントを定義するNetScaler CPX固有の環境変数。
  name: “NS_ROUTABLE” NetScaler CPXコンテナーが非IPコンテナーモードで実行されるかどうかを指定するNetScaler CPX固有の環境変数。値は必ずFALSEに設定してください。
  name: “KUBERNETES_TASK_ID” Kubernetesクラスター内のNetScaler CPX IDを識別します。
imagePullPolicy   Kubernetesがイメージをどのようにプルするかを指定します。

NetScaler CPXインスタンスを展開後、次の手順を実行して展開を検証できます。

  1. サービスアカウントを確認するには、以下のコマンドを入力します:
    root@ubuntu:~#kubectl get serviceaccount
    NAME SECRETS AGE
    cpx 1 21h
    default 1 6d
    
  2. NetScaler CPXの作成を確認するには、以下のコマンドを入力します:
    root@ubuntu:~#kubcetl get pods
    NAME READY STATUS RESTARTS AGE
    cpx-55tjg 1/1 Running 0 21h
    
    root@ubuntu:~#kubectl get ds
    NAME      DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    cpx       1         1         1         1            1           <none>          3d
    
  3. NetScaler CPXがNetScaler MASに登録されているかどうかを確認するには、次の手順を実行します。

    1. 管理者資格情報を使用して、NetScaler MASサーバーGUIにログオンします。デフォルトの管理者資格情報はnsroot/nsrootです。

    2. [Networks]>[Instances] に移動して [NetScaler VPX] を選択します。登録済みのNetScaler CPXインスタンスを表示できます:

    CPX登録

  4. Kubernetesのマスターノードで、NetScaler MASがNetScaler固有の構成をNetScaler CPXインスタンスに適用したかを確認するには、次の手順を実行します。

    1. 次のコマンドを使用して、NetScaler CPXポッドのbashにアクセスします。
      kubectl exec -it <POD-NAME> bash
      

      POD-NAMEはNetScaler CPXのポッド名です。

    2. cli_script.shスクリプトを使用して、NetScaler CPXインスタンスに適用された構成を表示します。

      root@ubuntu:~# kubectl exec -it cpx-ph5pm bash
      root@worker:/# cli_script.sh 'sh cs vs'
      exec: sh cs vs
      1)      kube-dns.kube-system.dns.svc-cs (192.168.1.3:25366) - UDP       Type: CONTENT
              State: UP
              Last state change was at Wed Aug 29 06:25:16 2018
              Time since last state change: 0 days, 04:02:17.650
              Client Idle Timeout: 120 sec
              Down state flush: ENABLED
              Disable Primary Vserver On Down : DISABLED
              Appflow logging: ENABLED
              State Update: DISABLED
              Default: kube-dns.kube-system.dns.svc-lb-default-lb     Content Precedence: RULE
              L2Conn: OFF     Case Sensitivity: ON
              Authentication: OFF
              401 Based Authentication: OFF
              Listen Policy: NONE
              IcmpResponse: PASSIVE
              RHIstate:  PASSIVE
              Traffic Domain: 0
      

Kubernetesでサービスを作成する

East-Westトラフィックの負荷分散のためにNetScaler CPXインスタンスを展開後、フロントエンドサービスとバックエンドサービスを展開する必要があります。

以下は、コーヒー(coffee)と紅茶(tea)のバックエンドサービスのYAMLファイルの例です:

Sample: coffee.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: coffee-backend
  labels:
      name: coffee-backend
spec:
  replicas: 4
  template:
    metadata:
      labels:
        name: coffee-backend
    spec:
      containers:
      - name: coffee-backend
        image: in-docker-reg.eng.citrite.net/cpx-dev/hotdrinks.beverages.com:v1
        ports:
        - name: coffee-backend
          containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-backend
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    name: coffee-backend

Sample: tea.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tea-backend
  labels:
      name: tea-backend
spec:
  replicas: 4
  template:
    metadata:
      labels:
        name: tea-backend
    spec:
      containers:
      - name: tea-backend
        image: in-docker-reg.eng.citrite.net/cpx-dev/hotdrinks.beverages.com:v1
        ports:
        - name: tea-backend
          containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  name: tea-backend
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    name: tea-backend

以下は、フロントエンドサービスのYAMLファイルの例です:

Sample: hotdrink-frontend.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: frontend
  labels:
      name: frontend
spec:
  replicas: 4
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
      - name: frontend
        image: in-docker-reg.eng.citrite.net/cpx-dev/hotdrinks.beverages.com:v1
        ports:
        - name: frontend
          containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    name: frontend

以下のように、kubectl create -f <yaml-file>コマンドを使用してこれらのサービスを展開します:

root@ubuntu:~# kubectl create -f coffee.yaml
deployment.extensions/coffee-backend created

root@ubuntu:~# kubectl create -f tea.yaml
deployment.extensions/tea-backend created

root@ubuntu:~# kubectl create -f hotdrink-frontend.yaml
deployment.extensions/frontend created

サービスの展開後、ポッドが次のように作成されていることを確認します:

root@ubuntu:~# kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
coffee-backend-574f4dbfb-4tbkm   1/1       Running   0          7m
coffee-backend-574f4dbfb-j2swl   1/1       Running   0          7m
coffee-backend-574f4dbfb-tph7c   1/1       Running   0          7m
coffee-backend-574f4dbfb-tszln   1/1       Running   0          7m
cpx-ph5pm                        1/1       Running   0          12m
frontend-dc465fb47-87f4z         1/1       Running   0          6m
frontend-dc465fb47-ts88r         1/1       Running   0          6m
frontend-dc465fb47-vndq2         1/1       Running   0          6m
frontend-dc465fb47-x566h         1/1       Running   0          6m
tea-backend-7876c577c4-p8jsf     1/1       Running   0          6m
tea-backend-7876c577c4-r9gvd     1/1       Running   0          6m
tea-backend-7876c577c4-tfm8f     1/1       Running   0          6m
tea-backend-7876c577c4-xrnkq     1/1       Running   0          6m

サービスポッドの作成後、NetScaler MASがNetScaler固有の構成をNetScaler CPXインスタンスに適用し、East-Westトラフィックが負荷分散されていることを確認する必要があります。

root@ubuntu:~# kubectl exec -it cpx-55tjg bash
root@worker:/# cli_script.sh 'sh cs vs'
exec: sh cs vs
1)      kube-dns.kube-system.53.svc-cs (192.168.1.3:20084) - TCP        Type: CONTENT
        State: UP
        Last state change was at Mon Aug 27 10:34:14 2018
        Time since last state change: 0 days, 00:13:28.870
        Client Idle Timeout: 9000 sec
        Down state flush: ENABLED
        Disable Primary Vserver On Down : DISABLED
        Appflow logging: ENABLED
        State Update: DISABLED
        Default: kube-dns.kube-system.53.svc-lb-default-lb      Content Precedence: RULE
        L2Conn: OFF     Case Sensitivity: ON
        Authentication: OFF
        401 Based Authentication: OFF
        Listen Policy: NONE
        IcmpResponse: PASSIVE
        RHIstate:  PASSIVE
        Traffic Domain: 0
2)      coffee-backend.default.80.svc-cs (192.168.1.3:29867) - TCP      Type: CONTENT
        State: UP
        Last state change was at Mon Aug 27 10:38:21 2018
        Time since last state change: 0 days, 00:09:21.60
        Client Idle Timeout: 9000 sec
        Down state flush: ENABLED
        Disable Primary Vserver On Down : DISABLED
        Appflow logging: ENABLED
        State Update: DISABLED
        Default: coffee-backend.default.80.svc-lb-default-lb    Content Precedence: RULE
        L2Conn: OFF     Case Sensitivity: ON
        Authentication: OFF
        401 Based Authentication: OFF
        Listen Policy: NONE
        IcmpResponse: PASSIVE
        RHIstate:  PASSIVE
        Traffic Domain: 0
3)      tea-backend.default.80.svc-cs (192.168.1.3:21847) - TCP Type: CONTENT
        State: UP
        Last state change was at Mon Aug 27 10:38:37 2018
        Time since last state change: 0 days, 00:09:05.360
        Client Idle Timeout: 9000 sec
        Down state flush: ENABLED
        Disable Primary Vserver On Down : DISABLED
        Appflow logging: ENABLED
        State Update: DISABLED
        Default: tea-backend.default.80.svc-lb-default-lb       Content Precedence: RULE
        L2Conn: OFF     Case Sensitivity: ON
        Authentication: OFF
        401 Based Authentication: OFF
        Listen Policy: NONE
        IcmpResponse: PASSIVE
        RHIstate:  PASSIVE
        Traffic Domain: 0
4)      frontend.default.80.svc-cs (192.168.1.3:27109) - TCP    Type: CONTENT
        State: UP
        Last state change was at Mon Aug 27 10:39:30 2018
        Time since last state change: 0 days, 00:08:12.570
        Client Idle Timeout: 9000 sec
        Down state flush: ENABLED
        Disable Primary Vserver On Down : DISABLED
        Appflow logging: ENABLED
        State Update: DISABLED
        Default: frontend.default.80.svc-lb-default-lb  Content Precedence: RULE
        L2Conn: OFF     Case Sensitivity: ON
        Authentication: OFF
        401 Based Authentication: OFF
        Listen Policy: NONE
        IcmpResponse: PASSIVE
        RHIstate:  PASSIVE
        Traffic Domain: 0
Done

また、NetScaler CPXインスタンスにプッシュされたNetScaler固有の構成はNetScaler MASで確認できます。[Applications]>[Configurations] に移動します。

アプリ構成

NetScaler VPXをIngressデバイスとして構成する

Ingressデバイスとして、NetScaler MPX、NetScaler VPX、NetScaler CPXなどのNetScaler ADCを構成できます。この展開例では、NetScaler VPXアプライアンスがIngressデバイスとして使用されています。

NetScaler VPXアプライアンスをIngressデバイスとして使用するには、以下が必要です。

  • 展開されたNetScaler VPXアプライアンス。詳しくは、「Citrix NetScaler VPXの展開」を参照してください。

  • コンテンツスイッチおよび負荷分散機能がNetScaler VPXアプライアンスで有効になっている。

  • NetScaler MASにNetScaler VPXアプライアンスを追加。詳しくは、「NetScaler MASへのインスタンスの追加」を参照してください。

    NetScaler MASにNetScaler VPXアプライアンスを追加すると、追加したインスタンスをNetScaler MASで表示できます。[Networks]>[Instances]>[NetScaler VPX] の順に選択します。

     MASのVPX

KubernetesでIngressルールを作成する

KubernetesでIngressルールを作成する必要があります。NetScaler MASのIngressコントローラーは、これらのルールを使用して、NetScaler VPXアプライアンス(Ingressデバイス)上でコンテンツスイッチポリシーを構成します。

以下は、KubernetesでIngressルールを作成するためのYAMLファイル例です。YAMLファイルはNetScaler固有の注釈を使用します:

注釈 説明
NETSCALER_VIP 仮想サーバーのIPアドレス(VIP)。このIPアドレスはルーティング可能にする必要があります。
NETSCALER_HTTP_PORT 仮想サーバーのHTTPポート
NETSCALER_SECURE_PORT 仮想サーバーのHTTPSポート

Sample: ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
   NETSCALER_HTTP_PORT: "8888"
   NETSCALER_VIP: "10.102.29.140"

spec:
  rules:
  - host: hotdrinks.beverages.com
    http:
      paths:
      - path: /
        backend:
          serviceName: frontend
          servicePort: 80

以下のように、kubectl create -f <yaml-file>コマンドを使用してIngressルールを展開します。

root@ubuntu:~# kubectl create -f ingress.yaml
Ingress/web-ingress created

Ingressルールの展開後、NetScaler MASはコンテンツスイッチ構成を作成し、NetScaler VPXアプライアンス(Ingressデバイス)に適用します。

NetScaler MASとNetScaler VPXアプライアンス(Ingressデバイス)の両方でコンテンツスイッチ構成を確認できます。

NetScaler MASで、[Applications]>[Configuration] に移動します。

Ingress構成

Ingressデバイスで静的ルートを追加する

インターネットトラフィックをKubernetesネットワークにルーティングするには、NetScaler VPXアプライアンス(Ingressデバイス)静的ルートを追加する必要があります。トラフィックを、NetScaler VPXアプライアンス(Ingressデバイス)で構成されたサービスにルーティングする必要があります。

静的ルートを追加する前に、以下のことを確認してください。

  • NetScaler VPXアプライアンスでsh servicegroup <service-group-name>コマンドを使用し、構成されたサービスIPアドレスを表示します。

    サービスグループ

    注意: サービスIPアドレスは「DOWN」状態です。

  • add ip <IP-ADDRESS> <NETMASK> -type SNIPを使用して、ホストネットワークのNetScaler VPXアプライアンス*(Ingressデバイス) *でSNIPを構成します。ホストネットワークは、Kubernetesノードが相互に通信するネットワークです。通常eth0のIPアドレスはこのネットワークからのものです。

  • 各KubernetesノードのpodCIDRを記録します。オーバーレイサブネットワークを使用している場合は、以下のように kubectl get nodes -o yaml | grep podCIDRを使用してpodCIDRを表示します:

    root@ubuntu:~# kubectl get nodes -o yaml | grep podCIDR
     podCIDR: 10.244.0.0/24
     podCIDR: 10.244.1.0/24
    

Flannelサブネットワークを使用している場合は、詳細は以下のようにすべてのノードの/run/flannel/subnet.envに格納されます:

   root@worker:~# cat /run/flannel/subnet.env
   FLANNEL_NETWORK=10.244.0.0/16
   FLANNEL_SUBNET=10.244.1.1/24
   FLANNEL_MTU=1450
   FLANNEL_IPMASQ=true

次に、add route <podCIDR_network> <podCIDR_netmask> <node_HostIP>コマンドを使用してNetScaler VPXアプライアンス(Ingressデバイス)に静的ルートを追加します。

例:

> add route 10.244.1.0 255.255.255.0 10.102.29.102
 Done

静的ルートの追加後、NetScaler MASによってプッシュされたIngress構成とサービスIPアドレスの状態を確認します:

  • NetScaler VPXアプライアンスでsh servicegroup <service-group-name>コマンドを使用し、構成されたサービスIPアドレスを表示します。サービスIPアドレスの状態は、以下のように「UP」状態になっている必要があります:

    サービスグループ

  • sh lb vssh cs vssh cs policyコマンドを使用して、NetScaler MASによってNetScaler VPXアプライアンスにプッシュされたIngress構成を表示します。

    > sh lb vs
     1)  web-ingress.default.80-frontend.default.80-lb (0.0.0.0:0) - HTTP        Type: ADDRESS
         State: UP
         Last state change was at Wed Aug 29 16:21:39 2018
         Time since last state change: 0 days, 00:14:16.120
         Effective State: UP
         Client Idle Timeout: 180 sec
         Down state flush: ENABLED
         Disable Primary Vserver On Down : DISABLED
         Appflow logging: ENABLED
         Port Rewrite : DISABLED
         No. of Bound Services :  4 (Total)       4 (Active)
         Configured Method: LEASTCONNECTION
         Current Method: Round Robin, Reason: Bound service's state changed to UP        BackupMethod: ROUNDROBIN
         Mode: IP
         Persistence: NONE
         Vserver IP and Port insertion: OFF
         Push: DISABLED  Push VServer:
         Push Multi Clients: NO
         Push Label Rule: none
         L2Conn: OFF
         Skip Persistency: None
         Listen Policy: NONE
         IcmpResponse: PASSIVE
         RHIstate: PASSIVE
         New Service Startup Request Rate: 0 PER_SECOND, Increment Interval: 0
         Mac mode Retain Vlan: DISABLED
         DBS_LB: DISABLED
         Process Local: DISABLED
         Traffic Domain: 0
         TROFS Persistence honored: ENABLED
         Retain Connections on Cluster: NO
      Done
    
     > sh cs vs
     1)  web-ingress.default.80-cs (10.102.29.70:80) - HTTP      Type: CONTENT
         State: UP
         Last state change was at Wed Aug 29 12:11:48 2018
         Time since last state change: 0 days, 04:24:15.110
         Client Idle Timeout: 180 sec
         Down state flush: ENABLED
         Disable Primary Vserver On Down : DISABLED
         Appflow logging: ENABLED
         Port Rewrite : DISABLED
         State Update: DISABLED
         Default:        Content Precedence: RULE
         Vserver IP and Port insertion: OFF
         L2Conn: OFF     Case Sensitivity: ON
         Authentication: OFF
         401 Based Authentication: OFF
         Push: DISABLED  Push VServer:
         Push Label Rule: none
         Listen Policy: NONE
         IcmpResponse: PASSIVE
         RHIstate:  PASSIVE
         Traffic Domain: 0
      Done
    
     > sh cs policy
     1)
         Policy: web-ingress.default.80-cs-frontend.default.80-cspol     Rule: HTTP.REQ.HOSTNAME.SERVER.EQ("hotdrinks.beverages.com") && HTTP.REQ.URL.PATH.STARTSWITH("/")       Action: web-ingress.default.80-cs-frontend.default.80-csaction
    
         Hits: 0
      Done
    
    

展開例を確認する

展開例のすべてのコンポーネントを展開後、DNSエントリ(HOSTエントリマッピング)を追加してhotdrinks.beverages.comをNetScaler VPXアプライアンス(Ingressデバイス)の仮想サーバーのIPアドレスにマッピングします。展開例の確認URLは、次のとおりです:http://hotdrinks.beverages.com/frontend.php

展開例