web-dev-qa-db-ja.com

Kubernetes EKS IngressおよびTLS

私はアプリケーションの非常に一般的なタスクを達成しようとしています：

証明書を割り当て、TLS/HTTPSで保護します。

私はほぼ1日ドキュメントを精査し、これを機能させるために複数の異なる戦術を試してみましたが、何も機能していません。

最初に、次のドキュメントに従って、Helmを使用してEKSでnginx-ingressをセットアップします： https://github.com/nginxinc/kubernetes-ingress 。次の設定を使用して、サンプルアプリを動作させようとしました（カフェ）。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  tls:
  - hosts:
    - cafe.example.com
    secretName: cafe-secret
  rules:
  - Host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

イングレスとサポートされているすべてのサービス/デプロイは正常に機能しましたが、1つ大きな欠落があります。イングレスにはアドレス/ ELBが関連付けられていません。

NAME           HOSTS                 ADDRESS   PORTS     AGE
cafe-ingress   cafe.example.com                80, 443   12h

サービスLoadBalancersはELBリソースを作成します。

testnodeapp    LoadBalancer   172.20.4.161     a64b46f3588fe...   80:32107/TCP     13h

ただし、イングレスはアドレスを作成していません。 TLS/HTTPSを処理するためにEKSで外部に公開されたIngressコントローラーを取得するにはどうすればよいですか？

kubernetesamazon-eks
9
Ken J

安全なイングレスでEKSを立ち上げて実行するために必要なすべてのステップを複製しました。これが、EKSでアプリケーションを迅速かつ安全に取得したい他の人に役立つことを願っています。

EKSを起動して実行するには：

  1. CloudFormationテンプレートを使用してEKSを展開します here ：CidrIp：193.22.12.32/32でアクセスを制限していることに注意してください。これをニーズに合わせて変更します。

  2. クライアントツールをインストールします。ガイド こちら に従ってください。

  3. クライアントを構成します。ガイド こちら に従ってください。
  4. ワーカーノードを有効にします。ガイド こちら に従ってください。

以下を実行することで、クラスターが稼働中であり、それを指していることを確認できます。

kubectl get svc

次に、nginx ingressを使用してテストアプリケーションを起動します。

注：すべてがingress-nginx名前空間の下に配置されます。理想的には、これは異なる名前空間でビルドするようにテンプレート化されますが、この例の目的では機能します。

Nginx-ingressをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml

here からrbac.ymlを取得します。実行：

kubectl apply -f rbac.yml

テスト用に証明書とキーを用意してください。次のように必要なシークレットを作成します。

kubectl create secret tls cafe-secret --key mycert.key --cert mycert.crt -n ingress-nginx

here からcoffee.ymlをコピーします。 coffee-ingress.ymlを here からコピーします。これを実行するドメインを更新します。それらを次のように実行します

kubectl apply -f coffee.yaml
kubectl apply -f coffee-ingress.yaml

ドメインのCNAMEを更新して、次のアドレスを指定します。

kubectl get ing -n ingress-nginx -o wide

DNSキャッシュを更新し、ドメインをテストします。要求の統計情報を含む安全なページを取得する必要があります。これを複数回複製したため、動作しない場合は、手順、構成、および証明書を確認してください。また、nginx-ingress-controller *ポッドのログを確認してください。

kubectl logs pod/nginx-ingress-controller-*********** -n ingress-nginx

これにより、何が間違っているのかがわかります。

13
Ken J

入力リソース を機能させるには、クラスターに 入力コントローラー が設定されている必要があります。

これは、通常kube-controller-managerバイナリの一部として実行され、通常はクラスター作成の一部として自動的に開始される他のタイプのコントローラーとは異なります。

helm を使用したEKSの場合、次を試すことができます。

helm registry install quay.io/coreos/alb-ingress-controller-helm

次に、イングレスリソースを構成します。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: 'true'
spec:
  rules:
  - Host: YOUR_DOMAIN
    http:
      paths:
      - path: /
        backend:
          serviceName: ingress-example-test
          servicePort: 80
  tls:
  - secretName: custom-tls-cert
    hosts:
    - YOUR_DOMAIN

構成を適用します。

kubectl create -f ingress.yaml

次に、TLS証明書を使用してシークレットを作成します。

kubectl create secret tls custom-tls-cert --key /path/to/tls.key --cert /path/to/tls.crt

ingressの定義でそれらを参照します：

tls:
  - secretName: custom-tls-cert
    hosts:
    - YOUR_DOMAIN

次の設定例は、イングレスコントローラの設定方法を示しています。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  labels:
    k8s-app: nginx-ingress-controller
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: nginx-ingress-controller
  template:
    metadata:
      labels:
        k8s-app: nginx-ingress-controller
    spec:
      # hostNetwork makes it possible to use ipv6 and to preserve the source IP correctly regardless of docker configuration
      # however, it is not a hard dependency of the nginx-ingress-controller itself and it may cause issues if port 10254 already is taken on the Host
      # that said, since hostPort is broken on CNI (https://github.com/kubernetes/kubernetes/issues/31307) we have to use hostNetwork where CNI is used
      # like with kubeadm
      # hostNetwork: true
      terminationGracePeriodSeconds: 60
      containers:
      - image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.17.1
        name: nginx-ingress-controller
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          timeoutSeconds: 1
        ports:
        - containerPort: 80
          hostPort: 80
        - containerPort: 443
          hostPort: 443
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
        args:
        - /nginx-ingress-controller
        - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
        - --publish-service=$(POD_NAMESPACE)/nginx-ingress-lb

次に、上記の構成を適用すると、公開されている外部IPのサービスを確認できます。

kubectl get service nginx-controller -n kube-system

外部IPは、外部で構成されたルーティングメカニズムによって構成されたKubernetesノードの1つで終端するアドレスです。サービス定義内で構成されている場合、要求がノードに到達すると、トラフィックはサービスエンドポイントにリダイレクトされます。

Kubernetesのドキュメント にさらに例を示します。

0
d0bry