ALB Ingress Controller

ALB Ingress ControllerはKubernetes IngressをApplication LoadBalancer商品に連動して、HTTP、HTTPSトラフィックを、クラスタ内のPodにルーティングされるようにします。

動作

• Ingressが生成されると、Ingress ControllerはIngressに設定された値を使用して、Application Load Balancerを生成します。
• Ingress Ruleに設定されたServiceのNodePortにWorker Nodeに対するTarget Groupを作成してLoad Balancerに登録します。

開始する

開始する前にIngress ControllerをインストールするKubernetes Serviceクラスタとkubectlインストールとkubeconfig設定が先行しなければならない。

クラスタにALB Ingress Controllerをインストールする

次のコマンドを使用すると、kube-system名前空間にalb-ingress-controllerが生成され、それに必要なServiceAccount、ClusterRole、ClusterRoleBindingが生成されます。

kubectl --kubeconfig=$KUBE_CONFIG apply -f https://raw.githubusercontent.com/NaverCloudPlatform/nks-alb-ingress-controller/main/docs/install/pub/install.yaml

使い方

• kubernetes.io/ingress.class: alb
  • ALB Ingress Controllerを使用するには、Ingress Resourceに kubernetes.io/ingress.class：alb Annotationを追加する必要があります。
• Service type: NodePort
  • Ingressを介して公開することがServiceはすべてNodePort typeで生成しなければします。
• Default Rule
  • Default Ruleは、マッチングされたruleが一個もない場合に適用されるruleでspec.backendに設定することができます。
  • 別のruleとuse-annotation設定は不可能であり、設定していない場合、ポート80に設定された基本的なTarget Groupが作成されます。
• Rule Priority
  • Ingressに定義されたruleの順序によって優先順位が決定されます。一番上のruleの優先順位が1に設定されます。

Ingress Annotations

IngressとServiceオブジェクトのannotationを使用して設定を変更することができます。 alb ingress annotationはすべて alb.ingress.kubernetes.io/で始まります。

• alb.ingress.kubernetes.io/actions.${actionName}: actionsモデルに合わせてjson形式のstringに作成してListener Ruleの追加機能を設定することができます。 Ingressに設定されたRuleのserviceNameを使用しようとする ${actionName}に設定し、servicePortを use-annotationに設定すると、Annotationが適用されます。

• 例示
  • パス /exampleにactionNameがtargetsなAnnotationを設定して、二つのService（a、b）に重みベースのルーティングになるように設定

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
    name: example-alb-ingress
    annotations:
      kubernetes.io/ingress.class: alb
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
      alb.ingress.kubernetes.io/actions.targets: >
        {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"a","servicePort":80,"weight":40},{"serviceName":"b","servicePort":80,"weight":60}],"enableStickySession":false}}
    labels:
      app: example-alb-ingress
    spec:
    rules:
      - http:
          paths:
            - path: /example
              backend:
                serviceName: targets
                servicePort: use-annotation
    

• alb.ingress.kubernetes.io/conditions.${conditionName}: conditionsモデルに合わせてjson形式のstringに作成してIngressに定義されたHost、Path条件に加え条件を設定することができます。 Ingress Ruleで ${conditionName}と一致するserviceNameのServiceについての条件を適用します。

• 例示
  • 既存のruleに設定されたパス /exampleにhost条件example.comとpath条件 /example2を追加

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
    name: example-alb-ingress
    annotations:
      kubernetes.io/ingress.class: alb
      alb.ingress.kubernetes.io/conditions.example: >
        [{"field":"hostHeader","hostHeader":{"values":["example.com"]}},{"field":"pathPattern","pathPattern":{"values":["/example2"]}}]
    labels:
      app: example-alb-ingress
    spec:
    rules:
      - http:
          paths:
            - path: /example
              backend:
                serviceName: example
                servicePort: 80
    

Example

ルーティングの例

異なる3つのServiceに対してさまざまな方法でルーティングする例です。

次のコマンドを実行すると、3つのSampleのDeploymentとServiceが生成されます。各サービスの名前は naver、cloud、 platformです。

kubectl --kubeconfig=$KUBE_CONFIG apply -f https://gist.githubusercontent.com/NaverCloudPlatformDeveloper/0e6262b996f74229719807cb5ae007fc/raw/3ce72e7961bc2407bfb87e153c94672e6ee6a1cf/nks-alb-ingress-sample-services.yaml

生成されたサービスに対して、以下のように動作するようにIngressを生成してみましょう。

• 経路別の動作
  • /platform: Service platformにルーティングします。
  • /navercloud: 50対50の重みで naver、cloud二Serviceにルーティングします。
  • その他のすべてのパス：Service naverにルーティングします。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: sample-alb-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/description: 'alb ingress controller'
    alb.ingress.kubernetes.io/actions.navercloud: >
      {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}]}}
  labels:
    app: sample-alb-ingress
spec:
  backend:
    serviceName: naver
    servicePort: 80
  rules:
    - http:
        paths:
          - path: /platform
            backend:
              serviceName: platform
              servicePort: 80
          - path: /navercloud
            backend:
              serviceName: navercloud
              servicePort: use-annotation

上記にingress.yamlファイルを作成した後、次のコマンドでクラスタにIngressを生成します。

kubectl --kubeconfig=$KUBE_CONFIG apply -f ./ingress.yaml

Ingressが生成されると、Application Load Balancerを生成し、生成が完了すると、IngressのADDRESSにLoad Balancer接続の情報が更新されていることを確認することができます。

kubectl --kubeconfig=$KUBE_CONFIG get ingress
NAME                 HOSTS   ADDRESS   PORTS   AGE
sample-alb-ingress   *       ing-default-samplealbing-e5bde-1494091-0687c0712561.kr.lb.naverncp.com   80      21s

Load Balancerのアドレスを呼び出してingressに設定したパスがそれぞれ異なるServiceのPodに接続されているServer nameで確認することができます。

• /navercloud （何度も呼び出してnaver、cloudにルーティング確認）

  $ curl http://ing-default-samplealbing-e5bde-1494091-0687c0712561.kr.lb.naverncp.com/navercloud
  Server address: 198.18.0.160:80
  Server name: cloud-868dcd94cb-7lpl6
  Date: 15/Oct/2020:12:31:25 +0000
  URI: /navercloud
  Request ID: 6eaff95fa4000943b9aea8903ba8e598
  
  $ curl http://ing-default-samplealbing-e5bde-1494091-0687c0712561.kr.lb.naverncp.com/navercloud
  Server address: 198.18.0.75:80
  Server name: naver-5b64c89ff8-gwqxx
  Date: 15/Oct/2020:12:35:59 +0000
  URI: /navercloud
  Request ID: 9aa7cc193798ce3bce89718570fb9cb9
  

• /platform

  $ curl http://ing-default-samplealbing-e5bde-1494091-0687c0712561.kr.lb.naverncp.com/platform
  Server address: 198.18.0.35:80
  Server name: platform-85f9569d46-9zx6v
  Date: 15/Oct/2020:12:31:34 +0000
  URI: /platform
  Request ID: 2c9ef5533e8eb3421f129a095ab0b418
  

• /navercloudplatform（設定ではないパス）

  $ curl http://ing-default-samplealbing-e5bde-1494091-0687c0712561.kr.lb.naverncp.com/navercloudplatform
  Server address: 198.18.0.75:80
  Server name: naver-5b64c89ff8-gwqxx
  Date: 15/Oct/2020:12:31:46 +0000
  URI: /navercloudplatform
  Request ID: aa95fbc807f305e6a8a07aa6a57884b2
  

HTTPからHTTPSにリダイレクトする

action typeがredirectionなannotationを活用して、 HTTP（80）に入ってくるトラフィックを HTTPS（443）でredirectする例です。 この例を実行するには、まずドメインが必要であり、そのドメインのCertificate Manager商品に登録された証明書が必要です。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-certificate-no: "1004"
    alb.ingress.kubernetes.io/actions.ssl-redirect: |
      {"type":"redirection","redirection":{"port": "443","protocol":"HTTPS","statusCode":301}}
  labels:
    app: sample-alb-ingress
  name: sample-alb-ingress
  namespace: sample
spec:
  backend:
    serviceName: my-service
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: ssl-redirect
          servicePort: use-annotation
      - path: /*
        backend:
          serviceName: my-service
          servicePort: 80

• 80ポートをポート443にredirectionするために二つのportを登録します。

  alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]'
  

• HTTPS リスナーに登録する証明書番号です。認証番号は、Resource Managerのnrnで確認することができます。 (例示: nrn:PUB:CertificateManager::000:Certificate/External/${certificateNo})

  alb.ingress.kubernetes.io/ssl-certificate-no: "1004"
  

• 443ポートにredirectするactionを登録します。

  alb.ingress.kubernetes.io/actions.ssl-redirect: |
    {"type":"redirection","redirection":{"port": "443","protocol":"HTTPS","statusCode":301}}
  

• /*パスにトラフィックが入ってくるとssl-redirectに登録したaction設定通り、ポート443でredirectします。（このruleは最上段に位置する必要があります。）

  
  - path: /*
    backend:
      serviceName: ssl-redirect
      servicePort: use-annotation
  

• 443ポートに入ってきたトラフィックがmy-serviceに転送されます。

  - path: /*
    backend:
      serviceName: my-service
      servicePort: 80
  

基本的にはalb-ingress-controllerはingressに登録されたruleをすべてlistenerに同じように登録します。しかし、redirect設定の場合、redirect loopが発生する可能性のあるケースでは、該当するポートのlistenerはredirect ruleを登録しません。したがって、上記の例では、80ポートのリスナーのみredirect ruleが登録されます。