DigitalOceanKubernetesでCert-Managerを使用してNginxIngressを設定する方法

投稿日: 2019-11-08 2022-10-21
タグ: Kubernetes, Let's Encrypt, nginx, Security, Solutions

序章

Kubernetes Ingresses を使用すると、Kubernetesクラスターの外部からクラスター内のサービスにトラフィックを柔軟にルーティングできます。これは、HTTPおよびHTTPSトラフィックをKubernetesサービスにルーティングするためのルールを定義するIngress Resources と、トラフィックを負荷分散して適切な場所にルーティングすることでルールを実装するIngress Controllersを使用して実現されます。バックエンドサービス。

人気のあるIngressControllerには、 Nginx 、 Contour 、 HAProxy 、およびTraefikが含まれます。入力は、それぞれが専用のロードバランサーを使用する複数のLoadBalancerサービスを設定するためのより効率的で柔軟な代替手段を提供します。

このガイドでは、Kubernetesで管理されている Nginx Ingress Controller をセットアップし、トラフィックをいくつかのダミーバックエンドサービスにルーティングするためのいくつかのIngressリソースを作成します。 Ingressをセットアップしたら、 cert-manager をクラスターにインストールして、IngressへのHTTPトラフィックを暗号化するためのTLS証明書を管理およびプロビジョニングします。このガイドでは、Helmパッケージマネージャーを使用しません。 Helmを使用してNginxIngressControllerをロールアウトするためのガイドについては、Helmを使用してDigitalOceanKubernetesでNginxIngressをセットアップする方法を参照してください。

前提条件

このガイドを開始する前に、次のものを利用できるようにしておく必要があります。

ロールベースのアクセス制御（RBAC）が有効になっているKubernetes1.15+クラスター。このセットアップではDigitalOceanKubernetes クラスターを使用しますが、別の方法を使用してクラスターを自由に作成できます。
The kubectl ローカルマシンにインストールされ、クラスターに接続するように構成されたコマンドラインツール。インストールについてもっと読むことができます kubectl 公式ドキュメント。 DigitalOcean Kubernetesクラスターを使用している場合は、 DigitalOcean Kubernetesクラスターへの接続方法を参照して、を使用してクラスターに接続する方法を確認してください。 kubectl.
Ingressが使用するDigitalOceanロードバランサーを指すことができるドメイン名とDNSAレコード。 DigitalOceanを使用してドメインのDNSレコードを管理している場合は、DNSレコードの管理方法を参照して作成方法を確認してください。 A 記録。
The wget ローカルマシンにインストールされているコマンドラインユーティリティ。インストールできます wget オペレーティングシステムに組み込まれているパッケージマネージャーを使用します。

これらのコンポーネントを設定したら、このガイドを開始する準備が整います。

ステップ1—ダミーバックエンドサービスの設定

Ingress Controllerを展開する前に、まず2つのダミーエコーサービスを作成して展開し、Ingressを使用して外部トラフィックをルーティングします。 echo Servicesは、 hashcorp / http-echo Webサーバーコンテナを実行します。このコンテナは、Webサーバーの起動時に渡されたテキスト文字列を含むページを返します。詳細については http-echo、 GitHubリポジトリを参照してください。Kubernetesサービスの詳細については、Kubernetesの公式ドキュメントからサービスを参照してください。

ローカルマシンで、というファイルを作成して編集します echo1.yaml を使用して nano またはお気に入りの編集者：

nano echo1.yaml

次のサービスおよび展開マニフェストに貼り付けます。

echo1.yaml

apiVersion: v1
kind: Service
metadata:
  name: echo1
spec:
  ports:
  - port: 80
    targetPort: 5678
  selector:
    app: echo1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo1
spec:
  selector:
    matchLabels:
      app: echo1
  replicas: 2
  template:
    metadata:
      labels:
        app: echo1
    spec:
      containers:
      - name: echo1
        image: hashicorp/http-echo
        args:
        - "-text=echo1"
        ports:
        - containerPort: 5678

このファイルでは、というサービスを定義します echo1 トラフィックをポッドにルーティングします app: echo1 ラベルセレクター。ポートでTCPトラフィックを受け入れます 80 そしてそれをポートにルーティングします 5678, http-echoのデフォルトポート。

次に、デプロイメントを定義します。これは、 echo1、ポッドを管理します app: echo1 ラベルセレクター。デプロイメントには2つのポッドレプリカが必要であり、ポッドはと呼ばれるコンテナを開始する必要があることを指定します echo1 を実行します hashicorp/http-echo 画像。私たちは渡します text パラメータを設定し、 echo1、そのため http-echo Webサーバーが戻る echo1. 最後に、ポートを開きます 5678 ポッドコンテナ上。

ダミーのServiceandDeploymentマニフェストに満足したら、ファイルを保存して閉じます。

次に、を使用してKubernetesリソースを作成します kubectl apply とともに -f フラグ、保存したファイルをパラメータとして指定します。

kubectl apply -f echo1.yaml

次の出力が表示されます。

Outputservice/echo1 created
deployment.apps/echo1 created

サービスが公開されている内部IPであるClusterIPがあることを確認して、サービスが正しく開始されたことを確認します。

kubectl get svc echo1

次の出力が表示されます。

OutputNAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
echo1     ClusterIP   10.245.222.129   <none>        80/TCP    60s

これは、 echo1 サービスは現在、社内で利用可能です。 10.245.222.129 ポートで 80. トラフィックをcontainerPortに転送します 5678 選択したポッドで。

今では echo1 サービスが稼働しています。このプロセスを繰り返します。 echo2 サービス。

と呼ばれるファイルを作成して開きます echo2.yaml:

echo2.yaml

apiVersion: v1
kind: Service
metadata:
  name: echo2
spec:
  ports:
  - port: 80
    targetPort: 5678
  selector:
    app: echo2
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo2
spec:
  selector:
    matchLabels:
      app: echo2
  replicas: 1
  template:
    metadata:
      labels:
        app: echo2
    spec:
      containers:
      - name: echo2
        image: hashicorp/http-echo
        args:
        - "-text=echo2"
        ports:
        - containerPort: 5678

ここでは、基本的に上記と同じService and Deploymentマニフェストを使用しますが、ServiceandDeploymentに名前を付けてラベルを付け直します echo2. さらに、いくつかのバリエーションを提供するために、ポッドレプリカを1つだけ作成します。設定することを確認します text パラメータから echo2 Webサーバーがテキストを返すように echo2.

ファイルを保存して閉じ、を使用してKubernetesリソースを作成します kubectl:

kubectl apply -f echo2.yaml

次の出力が表示されます。

Outputservice/echo2 created
deployment.apps/echo2 created

もう一度、サービスが稼働していることを確認します。

kubectl get svc

両方が表示されるはずです echo1 と echo2 ClusterIPが割り当てられたサービス：

OutputNAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
echo1        ClusterIP   10.245.222.129   <none>        80/TCP    6m6s
echo2        ClusterIP   10.245.128.224   <none>        80/TCP    6m3s
kubernetes   ClusterIP   10.245.0.1       <none>        443/TCP   4d21h

ダミーのエコーWebサービスが稼働しているので、NginxIngressControllerの展開に進むことができます。

手順2— Kubernetes NginxIngressControllerを設定する

このステップでは、ロールアウトします v1.1.1 Kubernetesで管理されているNginxIngressControllerのいくつかのNginxIngressControllerがあることに注意してください。 Kubernetesコミュニティは、このガイドとNginxIncで使用されているコミュニティを維持しています。 kubernetes-ingressを維持します。このチュートリアルの手順は、公式のKubernetes Nginx IngressControllerインストールガイドの手順に基づいています。

Nginx Ingress Controllerは、Nginx Webサーバーを実行し、Kubernetesコントロールプレーンで新規および更新されたIngressResourceオブジェクトを監視するポッドで構成されています。入力リソースは、基本的にバックエンドサービスのトラフィックルーティングルールのリストです。たとえば、Ingressルールは、パスに到着するHTTPトラフィックを指定できます。 /web1 に向けられるべきです web1 バックエンドWebサーバー。 Ingress Resourcesを使用して、ホストベースのルーティングを実行することもできます。たとえば、ヒットしたリクエストをルーティングします。 web1.your_domain.com バックエンドKubernetesサービスへ web1.

この場合、IngressControllerをDigitalOceanKubernetesクラスターにデプロイしているため、コントローラーは、すべての外部トラフィックが送信されるDigitalOceanロードバランサーをプロビジョニングするLoadBalancerサービスを作成します。このロードバランサーは、外部トラフィックをNginxを実行しているIngress Controller Podにルーティングし、Nginxはトラフィックを適切なバックエンドサービスに転送します。

まず、Nginx IngressControllerKubernetesリソースを作成します。これらは、コントローラーの構成を含むConfigMap、Kubernetes APIへのコントローラーアクセスを許可するロールベースのアクセス制御（RBAC）ロール、およびを使用する実際のIngressコントローラーデプロイメントで構成されます。 v1.1.1 NginxIngressControllerイメージのこれらの必要なリソースの完全なリストを確認するには、Kubernetes NginxIngressControllerのGitHubリポジトリのマニフェストを参照してください。

注：このチュートリアルでは、 DigitalOceanProviderの公式インストール手順に従います。 Kubernetesプロバイダーに応じて適切なマニフェストファイルを選択する必要があります。

リソースを作成するには、 kubectl apply そしてその -f GitHubでホストされているマニフェストファイルを指定するフラグ：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/do/deploy.yaml

を使用しております apply 将来的には段階的にできるようにここに apply Ingress Controllerオブジェクトを完全に上書きするのではなく、変更します。詳細については apply、Kubernetesの公式ドキュメントからリソースの管理を参照してください。

次の出力が表示されます。

Outputnamespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created

この出力は、から作成されたすべてのIngressControllerオブジェクトの便利な要約としても機能します。 deploy.yaml マニフェスト。

IngressControllerポッドが開始したことを確認します。

kubectl get pods -n ingress-nginx \
  -l app.kubernetes.io/name=ingress-nginx --watch

OutputNAME                                       READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-l2jhk       0/1     Completed   0          13m
ingress-nginx-admission-patch-hsrzf        0/1     Completed   0          13m
ingress-nginx-controller-c96557986-m47rq   1/1     Running     0          13m

打つ CTRL+C プロンプトに戻ります。

次に、でサービスの詳細を取得して、DigitalOceanロードバランサーが正常に作成されたことを確認します。 kubectl:

kubectl get svc --namespace=ingress-nginx

数分後、DigitalOceanロードバランサーのIPアドレスに対応する外部IPアドレスが表示されます。

OutputNAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.245.201.120   203.0.113.0   80:31818/TCP,443:31146/TCP   14m
ingress-nginx-controller-admission   ClusterIP      10.245.239.119   <none>            443/TCP                      14m

後の手順で必要になるため、ロードバランサーの外部IPアドレスを書き留めます。

注：デフォルトでは、NginxIngressLoadBalancerサービスには service.spec.externalTrafficPolicy 値に設定 Local、すべてのロードバランサートラフィックをNginxIngressPodsを実行しているノードにルーティングします。他のノードは、ロードバランサーのヘルスチェックに意図的に失敗するため、入力トラフィックはそれらにルーティングされません。外部トラフィックポリシーはこのチュートリアルの範囲を超えていますが、詳細については、Kubernetes外部トラフィックポリシーの詳細およびType =LoadBalancerのサービスのソースIPを公式から参照できます。 Kubernetesドキュメント。

このロードバランサーは、HTTPおよびHTTPSポート80および443でトラフィックを受信し、それをIngressControllerPodに転送します。次に、IngressControllerはトラフィックを適切なバックエンドサービスにルーティングします。

これで、DNSレコードをこの外部ロードバランサーにポイントし、トラフィックルーティングルールを実装するためのいくつかの入力リソースを作成できます。

ステップ3—入力リソースを作成する

最小限の入力リソースを作成して、特定のサブドメインに向けられたトラフィックを対応するバックエンドサービスにルーティングすることから始めましょう。

このガイドでは、テストドメインexample.comを使用します。これを自分が所有するドメイン名に置き換える必要があります。

まず、echo1.example.com宛てのトラフィックをにルーティングする簡単なルールを作成します。 echo1 echo2.example.comに向けられたバックエンドサービスとトラフィック echo2 バックエンドサービス。

と呼ばれるファイルを開くことから始めます echo_ingress.yaml お気に入りのエディターで：

nano echo_ingress.yaml

次の入力定義を貼り付けます。

echo_ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
spec:
  rules:
  - host: echo1.example.com
    http:
        paths:
        - pathType: Prefix
          path: "/"
          backend:
            service:
              name: echo1
              port:
                number: 80
  - host: echo2.example.com
    http:
        paths:
        - pathType: Prefix
          path: "/"
          backend:
            service:
              name: echo2
              port:
                number: 80

Ingressルールの編集が終了したら、ファイルを保存して閉じます。

ここでは、と呼ばれる入力リソースを作成することを指定しました echo-ingress、およびホストヘッダーに基づいてトラフィックをルーティングします。 HTTPリクエストのホストヘッダーは、ターゲットサーバーのドメイン名を指定します。ホストリクエストヘッダーの詳細については、Mozilla DeveloperNetwork定義ページを参照してください。ホストecho1.example.comでのリクエストは、 echo1 手順1で設定されたバックエンド、およびホストecho2.example.comでのリクエストは echo2 バックエンド。

これで、を使用してイングレスを作成できます kubectl:

kubectl apply -f echo_ingress.yaml

Ingressの作成を確認する次の出力が表示されます。

Outputingress.networking.k8s.io/echo-ingress created

Ingressをテストするには、DNS管理サービスに移動し、次のAレコードを作成します。 echo1.example.com と echo2.example.com DigitalOceanロードバランサーの外部IPを指しています。ロードバランサーの外部IPは、 ingress-nginx 前のステップでフェッチしたサービス。 DigitalOceanを使用してドメインのDNSレコードを管理している場合は、DNSレコードの管理方法を参照して作成方法を確認してください。 A 記録。

必要なものを作成したら echo1.example.com と echo2.example.com DNSレコード、を使用して作成したIngressControllerとリソースをテストできます curl コマンドラインユーティリティ。

ローカルマシンから、 curl the echo1 サービス：

curl echo1.example.com

から次の応答を受け取る必要があります echo1 サービス：

Outputecho1

これにより、 echo1.example.com Nginx入力を介してに正しくルーティングされています echo1 バックエンドサービス。

ここで、同じテストを実行します。 echo2 サービス：

curl echo2.example.com

から次の応答を受け取る必要があります echo2 サービス：

Outputecho2

これにより、 echo2.example.com Nginx入力を介してに正しくルーティングされています echo2 バックエンドサービス。

この時点で、仮想ホストベースのルーティングを実行するための最小限のNginxIngressを正常に設定できました。次のステップでは、 cert-manager をインストールして、IngressのTLS証明書をプロビジョニングし、より安全なHTTPSプロトコルを有効にします。

ステップ4—Cert-Managerのインストールと構成

このステップでは、cert-managerのv1.7.1をクラスターにインストールします。 cert-managerは、 Let’s Encrypt およびその他の認証局（CA）からTLS証明書をプロビジョニングし、それらのライフサイクルを管理するKubernetesアドオンです。 Ingress Resourcesに注釈を付け、追加することで、証明書を自動的に要求および構成できます。 tls Ingress仕様のセクションを作成し、1つ以上のIssuersまたはClusterIssuersを構成して、優先する認証局を指定します。 IssuerおよびClusterIssuerオブジェクトの詳細については、Issuerの公式のcert-managerドキュメントを参照してください。

公式のインストール手順に従って、cert-managerとそのカスタムリソース定義（CRD）（発行者やClusterIssuersなど）をインストールします。と呼ばれる名前空間に注意してください cert-manager cert-managerオブジェクトが作成される場所に作成されます。

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml

次の出力が表示されます。

Outputcustomresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
. . .
deployment.apps/cert-manager-webhook created
mutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created
validatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

インストールを確認するには、 cert-manager ポッドを実行するための名前空間：

kubectl get pods --namespace cert-manager

OutputNAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-578cd6d964-hr5v2              1/1     Running   0          99s
cert-manager-cainjector-5ffff9dd7c-f46gf   1/1     Running   0          100s
cert-manager-webhook-556b9d7dfd-wd5l6      1/1     Running   0          99s

これは、cert-managerのインストールが成功したことを示しています。

証明書の発行を開始する前に echo1.example.com と echo2.example.com ドメインでは、署名されたx509証明書を取得できる認証局を指定する発行者を作成する必要があります。このガイドでは、Let’s Encrypt認証局を使用します。これは、無料のTLS証明書を提供し、証明書構成をテストするためのステージングサーバーと、検証可能なTLS証明書をロールアウトするための運用サーバーの両方を提供します。

テストClusterIssuerを作成して、証明書プロビジョニングメカニズムが正しく機能していることを確認しましょう。 ClusterIssuerは名前空間スコープではなく、任意の名前空間のCertificateリソースで使用できます。

名前の付いたファイルを開きます staging_issuer.yaml お気に入りのテキストエディタで：

nano staging_issuer.yaml

次のClusterIssuerマニフェストに貼り付けます。

staging_issuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-staging
 namespace: cert-manager
spec:
 acme:
   # The ACME server URL
   server: https://acme-staging-v02.api.letsencrypt.org/directory
   # Email address used for ACME registration
   email: your_email_address_here
   # Name of a secret used to store the ACME account private key
   privateKeySecretRef:
     name: letsencrypt-staging
   # Enable the HTTP-01 challenge provider
   solvers:
   - http01:
       ingress:
         class:  nginx

ここでは、と呼ばれるClusterIssuerを作成することを指定します letsencrypt-staging、Let’sEncryptステージングサーバーを使用します。後で本番サーバーを使用して証明書をロールアウトしますが、本番サーバーはそれに対して行われるリクエストをレート制限するため、テスト目的ではステージングURLを使用する必要があります。

次に、証明書を登録するためのメールアドレスを指定し、Kubernetes Secretという名前を作成します。 letsencrypt-staging ACMEアカウントの秘密鍵を保存します。また、 HTTP-01 チャレンジメカニズム。これらのパラメーターの詳細については、Issuersの公式のcert-managerドキュメントを参照してください。

を使用してClusterIssuerをロールアウトします kubectl:

kubectl create -f staging_issuer.yaml

次の出力が表示されます。

Outputclusterissuer.cert-manager.io/letsencrypt-staging created

このプロセスを繰り返して、本番のClusterIssuerを作成します。証明書は、前の手順でプロビジョニングされたIngressリソースに注釈を付けて更新した後にのみ作成されることに注意してください。

というファイルを開きます prod_issuer.yaml お気に入りのエディターで：

nano prod_issuer.yaml

次のマニフェストに貼り付けます。

prod_issuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: your_email_address_here
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx

別のACMEサーバーのURLと letsencrypt-prod 秘密鍵の名前。

編集が終わったら、ファイルを保存して閉じます。

を使用してこの発行者をロールアウトする kubectl:

kubectl create -f prod_issuer.yaml

次の出力が表示されます。

Outputclusterissuer.cert-manager.io/letsencrypt-prod created

Let’sEncryptのステージングとprodClusterIssuersを作成したので、上記で作成したIngress Resourceを変更し、TLS暗号化を有効にする準備ができました。 echo1.example.com と echo2.example.com パス。

DigitalOcean Kubernetesを使用している場合は、最初に回避策を実装して、ポッドがIngressを使用して他のポッドと通信できるようにする必要があります。 DigitalOcean Kubernetesを使用していない場合は、ステップ6に進んでください。

ステップ5—ロードバランサーを介したポッド通信の有効化（オプション）

Let’s Encryptから証明書をプロビジョニングする前に、cert-managerは最初にセルフチェックを実行して、Let’sEncryptがドメインを検証するcert-managerポッドに到達できることを確認します。このチェックをDigitalOceanKubernetesに渡すには、NginxIngressロードバランサーを介したポッド-ポッド通信を有効にする必要があります。

これを行うには、クラウドロードバランサーの外部IPを指すDNS Aレコードを作成し、このサブドメインでNginxIngressServiceマニフェストに注釈を付けます。

DNS管理サービスに移動して、次のAレコードを作成することから始めます。 workaround.example.com DigitalOceanロードバランサーの外部IPを指しています。ロードバランサーの外部IPは、 ingress-nginx 手順2で取得したサービス。 DigitalOceanを使用してドメインのDNSレコードを管理している場合は、 DNSレコードの管理方法を参照して、Aレコードの作成方法を確認してください。ここではサブドメインを使用します workaround ただし、任意のサブドメインを自由に使用できます。

Ingressロードバランサーを指すDNSレコードを作成したので、IngressLoadBalancerサービスにdo-loadbalancer-hostnameアノテーションを付けます。名前の付いたファイルを開きます ingress_nginx_svc.yaml お気に入りのエディターで、次のLoadBalancerマニフェストに貼り付けます。

ingress_nginx_svc.yaml

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: 'true'
    service.beta.kubernetes.io/do-loadbalancer-hostname: "workaround.example.com"
  labels:
    helm.sh/chart: ingress-nginx-4.0.6
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/version: 1.1.1
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: controller
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/component: controller

このサービスマニフェストは、手順2でインストールした完全なNginxIngressマニフェストファイルから抽出されました。インストールしたNginxIngressバージョンに対応するサービスマニフェストを必ずコピーしてください。このチュートリアルでは、これは 1.1.1. また、必ず設定してください do-loadbalancer-hostname への注釈 workaround.example.com ドメイン。

完了したら、ファイルを保存して閉じます。

実行中の変更 ingress-nginx-controller を使用したサービス kubectl apply:

kubectl apply -f ingress_nginx_svc.yaml

次の出力が表示されます。

Outputservice/ingress-nginx-controller configured

これは、注釈を付けたことを確認します ingress-nginx-controller クラスタ内のサービスとポッドは、これを使用して相互に通信できるようになりました ingress-nginx-controller ロードバランサー。

ステップ6—ステージングと本番の発行証明書を暗号化しましょう

ドメインのステージングTLS証明書を発行するために、注釈を付けます echo_ingress.yaml 手順4で作成したClusterIssuerを使用します。これは、 ingress-shim を使用して、Ingressマニフェストで指定されたドメインの証明書を自動的に作成して発行します。

開く echo_ingress.yaml お気に入りのエディターで：

nano echo_ingress.yaml

Ingressリソースマニフェストに以下を追加します。

echo_ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - echo1.example.com
    - echo2.example.com
    secretName: echo-tls
  rules:
    - host: echo1.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo1
                port:
                  number: 80
    - host: echo2.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo2
                port:
                  number: 80

ここでは、cert-managerClusterIssuerをに設定するためのアノテーションを追加します letsencrypt-staging、ステップ4で作成したテスト証明書ClusterIssuer。この場合、入力のタイプを説明する注釈も追加します nginx.

また、 tls ブロックして、証明書を取得するホストを指定し、 secretName. このシークレットには、TLS秘密鍵と発行された証明書が含まれます。必ず交換してください example.com DNSレコードを作成したドメインを使用します。

変更が完了したら、ファイルを保存して閉じます。

次に、この更新を既存のIngressオブジェクトにプッシュします。 kubectl apply:

kubectl apply -f echo_ingress.yaml

次の出力が表示されます。

Outputingress.networking.k8s.io/echo-ingress configured

使用できます kubectl describe 適用したIngressの変更の状態を追跡するには：

kubectl describe ingress

OutputEvents:
  Type    Reason             Age               From                      Message
  ----    ------             ----              ----                      -------
  Normal  UPDATE             6s (x3 over 80m)  nginx-ingress-controller  Ingress default/echo-ingress
  Normal  CreateCertificate  6s                cert-manager              Successfully created Certificate "echo-tls"

証明書が正常に作成されたら、次のコマンドを実行できます。 describe その上で、その成功した作成をさらに確認します。

kubectl describe certificate

次の出力が表示されます。 Events セクション：

OutputEvents:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Requested  64s    cert-manager  Created new CertificateRequest resource "echo-tls-vscfw"
  Normal  Issuing    40s    cert-manager  The certificate has been successfully issued

これにより、TLS証明書が正常に発行され、構成された2つのドメインに対してHTTPS暗号化がアクティブになったことを確認できます。

これで、バックエンドにリクエストを送信する準備が整いました echo HTTPSが正しく機能していることをテストするサーバー。

次を実行します wget リクエストを送信するコマンド echo1.example.com 応答ヘッダーをに出力します STDOUT:

wget --save-headers -O- echo1.example.com

次の出力が表示されます。

Output. . .
HTTP request sent, awaiting response... 308 Permanent Redirect
. . .
ERROR: cannot verify echo1.example.com's certificate, issued by ‘ERROR: cannot verify echo1.example.com's certificate, issued by ‘CN=(STAGING) Artificial Apricot R3,O=(STAGING) Let's Encrypt,C=US’:
  Unable to locally verify the issuer's authority.
To connect to echo1.example.com insecurely, use `--no-check-certificate'.

これは、HTTPSが正常に有効になったことを示していますが、Let’s Encryptステージングサーバーによって発行された偽の一時証明書であるため、証明書を検証できません。

この一時的な偽の証明書を使用してすべてが機能することをテストしたので、2つのホストの本番証明書を展開できます echo1.example.com と echo2.example.com. これを行うには、 letsencrypt-prod ClusterIssuer。

アップデート echo_ingress.yaml 使用する letsencrypt-prod:

nano echo_ingress.yaml

ファイルに次の変更を加えます。

echo_ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - echo1.example.com
    - echo2.example.com
    secretName: echo-tls
  rules:
    - host: echo1.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo1
                port:
                  number: 80
    - host: echo2.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo2
                port:
                  number: 80

ここでは、ClusterIssuer名を次のように更新します。 letsencrypt-prod.

変更に満足したら、ファイルを保存して閉じます。

を使用して変更をロールアウトする kubectl apply:

kubectl apply -f echo_ingress.yaml

Outputingress.networking.k8s.io/echo-ingress configured

Let’sEncrypt本番サーバーが証明書を発行するまで数分待ちます。を使用して進行状況を追跡できます kubectl describe に certificate 物体：

kubectl describe certificate echo-tls

次の出力が表示されたら、証明書は正常に発行されています。

Output Normal  Issuing    28s                 cert-manager  Issuing certificate as Secret was previously issued by ClusterIssuer.cert-manager.io/letsencrypt-staging
  Normal  Reused     28s                 cert-manager  Reusing private key stored in existing Secret resource "echo-tls"
  Normal  Requested  28s                 cert-manager  Created new CertificateRequest resource "echo-tls-49gmn"
  Normal  Issuing    2s (x2 over 4m52s)  cert-manager  The certificate has been successfully issued

次に、を使用してテストを実行します curl HTTPSが正しく機能していることを確認するには：

curl echo1.example.com

次のように表示されます。

Output<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.15.9</center>
</body>
</html>

これは、HTTPリクエストがHTTPSを使用するようにリダイレクトされていることを示しています。

走る curl の上 https://echo1.example.com:

curl https://echo1.example.com

次の出力が表示されます。

Outputecho1

前のコマンドは冗長で実行できます -v フラグを使用して、証明書のハンドシェイクを深く掘り下げ、証明書情報を確認します。

この時点で、NginxIngressのLet’sEncrypt証明書を使用してHTTPSを正常に構成できました。

結論

このガイドでは、Nginx Ingressを設定して、Kubernetesクラスター内のバックエンドサービスに外部リクエストを負荷分散してルーティングします。また、cert-manager証明書プロビジョナーをインストールし、2つのホストパスにLet’s Encrypt証明書を設定することで、Ingressを保護しました。

NginxIngressControllerには多くの選択肢があります。詳細については、Kubernetesの公式ドキュメントのイングレスコントローラーを参照してください。

HelmKubernetesパッケージマネージャーを使用してNginxIngressControllerをロールアウトするためのガイドについては、Helmを使用してDigitalOceanKubernetesでNginxIngressを設定する方法を参照してください。

getdocs

13036