DigitalOcean KubernetesでCert-Managerを使用してNginx Ingressをセットアップする方法

前書き

Kubernetes Ingressesを使用すると、Kubernetesクラスターの外部からクラスター内のサービスにトラフィックを柔軟にルーティングできます。 これは、HTTPおよびHTTPSトラフィックをKubernetesサービスにルーティングするルールを定義するIngress _Resources_と、トラフィックを負荷分散して適切なバックエンドサービスにルーティングすることによりルールを実装するIngress _Controllers_を使用して実現されます。 人気のあるイングレスコントローラーには、https://github.com/kubernetes/ingress-nginx/blob/master/README.md [Nginx]、https://github.com/heptio/contour [Contour]、https:// wwwが含まれます。 haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/[HAProxy]、およびhttps://github.com/containous/traefik[Traefik]。 Ingressは、それぞれが専用のロードバランサーを使用する複数のLoadBalancerサービスをセットアップするより効率的で柔軟な代替手段を提供します。

このガイドでは、Kubernetesが管理するhttps://github.com/kubernetes/ingress-nginx[Nginx Ingress Controller]を設定し、いくつかのIngressリソースを作成して、トラフィックを複数のダミーバックエンドサービスにルーティングします。 Ingressをセットアップしたら、https://github.com/jetstack/cert-manager [cert-manager]をクラスターにインストールして、IngressへのHTTPトラフィックを暗号化するためのTLS証明書を管理およびプロビジョニングします。

前提条件

このガイドを始める前に、次のものを用意しておく必要があります。

  • https://kubernetes.io/docs/reference/access-authn-authz/rbac/ [ロールベースのアクセス制御](RBAC)が有効になっているKubernetes 1.10+クラスター

  • ローカルマシンにインストールされ、クラスターに接続するように設定されたコマンドラインツール「+ kubectl 」。 ` kubectl +`のインストールの詳細については、https://kubernetes.io/docs/tasks/tools/install-kubectl/ [公式ドキュメント]をご覧ください。

  • Ingressが使用するDigitalOceanロードバランサーを指すことができるドメイン名とDNS Aレコード。 DigitalOceanを使用してドメインのDNSレコードを管理している場合は、https://www.digitalocean.com/docs/networking/dns/how-to/manage-records/ [DNSレコードを管理する方法]でAを作成する方法を参照してください。記録。

  • https://www.digitalocean.com/community/tutorials/how-to-install-software-on-kubernetes-clusters-with-the -helm-package-manager [Helm Package Managerを使用してKubernetesクラスターにソフトウェアをインストールする方法]。 Helm v2.12.1以降を使用していることを確認してください。さもないと、cert-manager Helmチャートのインストールで問題が発生する可能性があります。 インストールしたHelmバージョンを確認するには、ローカルマシンで `+ helm version +`を実行します。

  • ローカルマシンにインストールされた `+ wget `コマンドラインユーティリティ。 オペレーティングシステムに組み込まれているパッケージマネージャーを使用して、 ` wget +`をインストールできます。

これらのコンポーネントをセットアップしたら、このガイドから始める準備ができました。

ステップ1-ダミーバックエンドサービスのセットアップ

Ingress Controllerを展開する前に、Ingressを使用して外部トラフィックをルーティングする2つのダミーエコーサービスを作成して展開します。 echoサービスは、https://hub.docker.com/r/hashicorp/http-echo/ [+ hashicorp / http-echo +] Webサーバーコンテナを実行します。これは、 Webサーバーが起動します。 `+ http-echo +`の詳細については、https://github.com/hashicorp/http-echo [GitHub Repo]を参照してください。Kubernetesサービスの詳細については、https://kubernetes.io/docs/を参照してください。 Kubernetes公式ドキュメントのconcept / services-networking / service / [Services]。

ローカルマシンで、 `+ nano `またはお気に入りのエディターを使用して、 ` echo1.yaml +`というファイルを作成および編集します。

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

このファイルでは、 `+ app:echo1 `ラベルセレクターでトラフィックをPodにルーティングする ` echo1 `というサービスを定義します。 ポート「+80」でTCPトラフィックを受け入れ、ポート「567​​8 +」、「 http-echo +」のデフォルトポートにルーティングします。

次に、 + app:echo1 + Label Selectorでポッドを管理する、 + echo1 +`とも呼ばれるデプロイメントを定義します。 。 Deploymentに2つのPodレプリカが必要であり、Podが `+ hashicorp / http-echo +`イメージを実行する `+ echo1 +`というコンテナーを起動するように指定します。 `+ text-`パラメータを渡して + echo1 + に設定すると、 + http-echo + Webサーバーは + echo1 + `を返します。 最後に、Podコンテナーのポート「567​​8」を開きます。

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

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

kubectl create -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 」サービスがポート「+80」の「10.245.222.129」で内部的に利用可能になったことを示しています。 選択したPodの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

ここでは、基本的に上記と同じサービスと展開のマニフェストを使用しますが、サービスと展開の名前とラベルを「+ echo2 」に変更します。 さらに、いくつかの多様性を提供するために、1つのPodレプリカのみを作成します。 Webサーバーがテキスト「 echo2 」を返すように、「 text 」パラメーターを「 echo2 +」に設定します。

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

kubectl create -f echo2.yaml

次のような出力が表示されるはずです。

Outputservice/echo2 created
deployment.apps/echo2 created

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

kubectl get svc

ClusterIPが割り当てられた `+ echo1 `サービスと ` echo2 +`サービスの両方が表示されます。

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サービスが稼働しているので、Nginx Ingress Controllerのロールアウトに進むことができます。

ステップ2-Kubernetes Nginx Ingress Controllerのセットアップ

このステップでは、Kubernetesが管理するhttps://github.com/kubernetes/ingress-nginx[Nginx Ingress Controller]の「++」を展開します。 several Nginx Ingress Controllersがあることに注意してください。 Kubernetesコミュニティは、このガイドおよびNginx Inc.で使用されているものを維持しています。 kubernetes-ingressを維持します。 このチュートリアルの手順は、公式のKubernetes Nginx Ingress Controller Installation Guideの手順に基づいています。

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

この場合、Ingress ControllerをDigitalOcean Kubernetesクラスターに展開しているため、Controllerは、すべての外部トラフィックが送信されるDigitalOceanロードバランサーをスピンアップするLoadBalancerサービスを作成します。 このロードバランサーは、外部トラフィックをNginxを実行しているIngress Controller Podにルーティングし、次にIngin Controller Podが適切なバックエンドサービスにトラフィックを転送します。

まず、Nginx Ingress Controllerに必要なKubernetesリソースを作成します。 これらは、コントローラーの構成を含むConfigMap、Kubernetes APIへのコントローラーアクセスを許可する役割ベースのアクセス制御(RBAC)の役割、およびhttps://quay.io/repository/kubernetes-ingress-を使用する実際のIngress Controller展開で構成されますNginx Ingress Controllerイメージのcontroller / nginx-ingress-controller?tag = 0.24.1&tab = tags [v0.24.1]。 これらの必要なリソースの完全なリストを確認するには、Kubernetes Nginx Ingress ControllerのGitHubリポジトリからhttps://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml[manifest]を参照してください。 。

これらの必須リソースを作成するには、 `+ kubectl apply `と ` -f +`フラグを使用して、GitHubでホストされるマニフェストファイルを指定します。

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

ここでは、 `+ create `の代わりに ` apply `を使用します。これにより、将来、Ingress Controllerオブジェクトに完全に上書きするのではなく、増分で ` apply `の変更を加えることができます。 ` apply +`の詳細については、公式のKubernetesドキュメントのhttps://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#kubectl-apply [リソースの管理]を参照してください。

次のような出力が表示されるはずです。

Outputnamespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.extensions/nginx-ingress-controller created

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

次に、Ingress Controller LoadBalancerサービスを作成します。このサービスは、前のコマンドで展開したIngress Controller PodにHTTPおよびHTTPSトラフィックの負荷を分散してルーティングするDigitalOceanロードバランサーを作成します。

LoadBalancerサービスを作成するには、サービス定義を含むマニフェストファイルを再度 `+ kubectl apply +`します。

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

次のような出力が表示されるはずです。

Outputservice/ingress-nginx created

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

kubectl get svc --namespace=ingress-nginx

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

OutputNAME            TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx   LoadBalancer         80:32486/TCP,443:32096/TCP   20h

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

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

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

ステップ3-入力リソースの作成

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

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

まず、* echo1。*に向けられたトラフィックを `+ echo1 `バックエンドサービスにルーティングし、* echo2。*に向けられたトラフィックを ` echo2 +`バックエンドサービスにルーティングする簡単なルールを作成します。

お気に入りのエディターで `+ echo_ingress.yaml +`というファイルを開くことから始めます。

nano echo_ingress.yaml

次のイングレス定義に貼り付けます。

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: echo-ingress
spec:
 rules:
 - host: echo1.
   http:
     paths:
     - backend:
         serviceName: echo1
         servicePort: 80
 - host: echo2.
   http:
     paths:
     - backend:
         serviceName: echo2
         servicePort: 80

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

ここでは、「+ echo-ingress 」というIngressリソースを作成し、Hostヘッダーに基づいてトラフィックをルーティングすることを指定しました。 HTTP要求のHostヘッダーは、ターゲットサーバーのドメイン名を指定します。 ホストリクエストヘッダーの詳細については、Mozilla Developer Network https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host[definition page]を参照してください。 ホスト* echo1。*のリクエストは、ステップ1で設定した ` echo1 `バックエンドに送られ、ホスト* echo2。*のリクエストは ` echo2 +`バックエンドに送られます。

これで、 `+ kubectl +`を使用してIngressを作成できます。

kubectl apply -f echo_ingress.yaml

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

Outputingress.extensions/echo-ingress created

Ingressをテストするには、DNS管理サービスに移動し、DigitalOcean Load Balancerの外部IPを指す「+ echo1.example.com 」および「 echo2.example.com 」のAレコードを作成します。 ロードバランサーの外部IPは、前の手順で取得した「 ingress-nginx +」サービスの外部IPアドレスです。 DigitalOceanを使用してドメインのDNSレコードを管理している場合は、https://www.digitalocean.com/docs/networking/dns/how-to/manage-records/ [DNSレコードを管理する方法]でAを作成する方法を参照してください。記録。

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

ローカルマシンから、 + curl +、 `+ echo1 +`サービス:

curl echo1.example.com

`+ echo1 +`サービスから次の応答を取得する必要があります。

Outputecho1

これにより、 `+ echo1.example.com `へのリクエストがNginxイングレスを介して ` echo1 +`バックエンドサービスに正しくルーティングされていることが確認されます。

次に、 `+ echo2 +`サービスに対して同じテストを実行します。

curl echo2.example.com

`+ echo2 +`サービスから次の応答を取得する必要があります。

Outputecho2

これにより、 `+ echo 2.example.com `へのリクエストがNginxイングレスを介して ` echo 2`バックエンドサービスに正しくルーティングされていることが確認されます。

この時点で、仮想ホストベースのルーティングを実行するための基本的なNginx Ingressのセットアップが正常に完了しました。 次のステップでは、Helmを使用してhttps://github.com/jetstack/cert-manager[cert-manager]をインストールし、イングレスのTLS証明書をプロビジョニングして、より安全なHTTPSプロトコルを有効にします。

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

この手順では、Helmを使用してcert-managerをクラスターにインストールします。 cert-managerは、https://letsencrypt.org/ [Let’s Encrypt]およびその他の認証局からTLS証明書をプロビジョニングし、ライフサイクルを管理するKubernetesサービスです。 Ingress Resourcesに `+ certmanager.k8s.io / issuer `アノテーションを付け、Ingress仕様に ` tls +`セクションを追加し、1つ以上の_Issuers_を設定して優先する認証局を指定することにより、証明書を要求および設定できます。 Issuerオブジェクトの詳細については、https://cert-manager.readthedocs.io/en/latest/reference/issuers.html [Issuers]にある公式のcert-managerドキュメントを参照してください。

Helmを使用してcert-managerをクラスターにインストールする前に、cert-manager https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ [カスタムリソース定義]( CRD)。 cert-manager GitHub repositoryから直接「+ apply +」してこれらを作成します。

kubectl apply \
   -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

次のような出力が表示されるはずです。

Outputcustomresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io created

次に、 `+ kube-system +`名前空間にラベルを追加し、cert-managerをインストールして、https://docs.cert-manager.io/en/venafi/を使用して高度なリソース検証を有効にします。 admin / resource-validation-webhook.html [webhook]:

kubectl label namespace kube-system certmanager.k8s.io/disable-validation="true"

次に、https://hub.helm.sh/charts/jetstack [Jetstack Helm repository]をHelmに追加します。 このリポジトリには、cert-manager Helm chartが含まれています。

helm repo add jetstack https://charts.jetstack.io

最後に、チャートを `+ kube-system`名前空間にインストールできます:

helm install --name cert-manager --namespace kube-system jetstack/cert-manager --version v0.8.0

次のような出力が表示されるはずです。

Output. . .
NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.readthedocs.io/en/latest/reference/issuers.html

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.readthedocs.io/en/latest/reference/ingress-shim.html

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

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

テスト発行者を作成して、証明書のプロビジョニングメカニズムが正しく機能していることを確認します。 お気に入りのテキストエディターで `+ staging_issuer.yaml +`という名前のファイルを開きます。

nano staging_issuer.yaml

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

staging_issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
  # The ACME server URL
  server: https://acme-staging-v02.api.letsencrypt.org/directory
  # Email address used for ACME registration
  email:
  # Name of a secret used to store the ACME account private key
  privateKeySecretRef:
    name: letsencrypt-staging
  # Enable the HTTP-01 challenge provider
  http01: {}

ここでは、 `+ letsencrypt-staging +`というClusterIssuerオブジェクトを作成し、Let’s Encryptステージングサーバーを使用することを指定します。 後で実稼働サーバーを使用して証明書を公開しますが、実稼働サーバーはそれに対して行われたリクエストのレートを制限する場合があるため、テスト目的ではステージングURLを使用するのが最善です。

次に、証明書を登録するためのメールアドレスを指定し、ACMEアカウントの秘密キーを保存するための「+ letsencrypt-staging 」というKubernetes https://kubernetes.io/docs/concepts/configuration/secret/[Secret]を作成します。 また、 ` HTTP-01 +`チャレンジメカニズムも有効にします。 これらのパラメーターの詳細については、https://cert-manager.readthedocs.io/en/latest/reference/issuers.html [Issuers]にある公式のcert-managerドキュメントを参照してください。

`+ kubectl`を使用してClusterIssuerをロールアウトします。

kubectl create -f staging_issuer.yaml

次のような出力が表示されるはずです。

Outputclusterissuer.certmanager.k8s.io/letsencrypt-staging created

Let’s Encryptステージング発行者を作成したので、上記で作成したIngressリソースを変更し、 `+ echo1.example.com `および ` echo2.example.com +`パスのTLS暗号化を有効にします。

お気に入りのエディターでもう一度 `+ echo ingress.yaml`を開きます:

nano echo_ingress.yaml

Ingress Resourceマニフェストに次を追加します。

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: echo-ingress



spec:





 rules:
 - host: echo1.example.com
   http:
     paths:
     - backend:
         serviceName: echo1
         servicePort: 80
 - host: echo2.example.com
   http:
     paths:
     - backend:
         serviceName: echo2
         servicePort: 80

ここでは、イングレスルールの実装に使用するイングレスコントローラーを決定する `+ ingress.class `を指定するためにいくつかのアノテーションを追加します。 さらに、 ` cluster-issuer `を、作成したばかりの証明書発行者である ` letsencrypt-staging +`に定義します。

最後に、 `+ tls `ブロックを追加して、証明書を取得するホストを指定し、 ` secretName +`を指定します。 このシークレットには、TLS秘密鍵と発行された証明書が含まれます。

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

`+ kubectl apply +`を使用して、既存のイングレスリソースを更新します。

kubectl apply -f echo_ingress.yaml

次のような出力が表示されるはずです。

Outputingress.extensions/echo-ingress configured

「+ kubectl describe +」を使用して、適用したIngressの変更の状態を追跡できます。

kubectl describe ingress
OutputEvents:
 Type    Reason             Age               From                      Message
 ----    ------             ----              ----                      -------
 Normal  CREATE             14m               nginx-ingress-controller  Ingress default/echo-ingress
 Normal  UPDATE             1m (x2 over 13m)  nginx-ingress-controller  Ingress default/echo-ingress
 Normal  CreateCertificate  1m                cert-manager              Successfully created Certificate "letsencrypt-staging"

証明書が正常に作成されたら、追加の `+ describe +`を実行して、作成が成功したことをさらに確認できます。

kubectl describe certificate

`+ Events +`セクションに次の出力が表示されるはずです。

OutputEvents:
 Type    Reason         Age   From          Message
 ----    ------         ----  ----          -------
 Normal  Generated      63s   cert-manager  Generated new private key
 Normal  OrderCreated   63s   cert-manager  Created Order resource "letsencrypt-staging-147606226"
 Normal  OrderComplete  19s   cert-manager  Order "letsencrypt-staging-147606226" completed successfully
 Normal  CertIssued     18s   cert-manager  Certificate issued successfully

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

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

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

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

次のような出力が表示されるはずです。

OutputURL transformed to HTTPS due to an HSTS policy
--2018-12-11 14:38:24--  https://echo1.example.com/
Resolving echo1.example.com (echo1.example.com)... 203.0.113.0
Connecting to echo1.example.com (echo1.example.net)|203.0.113.0|:443... connected.
ERROR: cannot verify echo1.example.com's certificate, issued by ‘CN=Fake LE Intermediate X1’:
 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 +`の運用証明書を展開できます。

ステップ5-本番発行者のロールアウト

このステップでは、ステージング証明書のプロビジョニングに使用する手順を変更し、イングレスホスト用の有効で検証可能な本番証明書を生成します。

まず、ClusterIssuerの運用証明書を作成します。

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

nano prod_issuer.yaml

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

prod_issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod
spec:
 acme:
   # The ACME server URL
   server: https://acme-v02.api.letsencrypt.org/directory
   # Email address used for ACME registration
   email:
   # Name of a secret used to store the ACME account private key
   privateKeySecretRef:
     name: letsencrypt-prod
   # Enable the HTTP-01 challenge provider
   http01: {}

異なるACMEサーバーURLと、 `+ letsencrypt-prod +`シークレットキー名に注意してください。

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

次に、 `+ kubectl +`を使用してこの発行者をロールアウトします。

kubectl create -f prod_issuer.yaml

次のような出力が表示されるはずです。

Outputclusterissuer.certmanager.k8s.io/letsencrypt-prod created

この新しい発行者を使用するには、 `+ echo_ingress.yaml +`を更新します。

nano echo_ingress.yaml

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

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: echo-ingress
 annotations:
   kubernetes.io/ingress.class: nginx
   certmanager.k8s.io/cluster-issuer:
spec:
 tls:
 - hosts:
   - echo1.example.com
   - echo2.example.com
   secretName:
 rules:
 - host: echo1.example.com
   http:
     paths:
     - backend:
         serviceName: echo1
         servicePort: 80
 - host: echo2.example.com
   http:
     paths:
     - backend:
         serviceName: echo2
         servicePort: 80

ここでは、ClusterIssuerとシークレット名の両方を「+ letsencrypt-prod +」に更新します。

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

`+ kubectl apply +`を使用して変更をロールアウトします。

kubectl apply -f echo_ingress.yaml
Outputingress.extensions/echo-ingress configured

Let’s Encrypt運用サーバーが証明書を発行するまで数分待ちます。 `+ certificate&`オブジェクトで `+ kubectl describe`を使用して進捗を追跡できます:

kubectl describe certificate letsencrypt-prod

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

OutputEvents:
 Type    Reason         Age   From          Message
 ----    ------         ----  ----          -------
 Normal  Generated      82s   cert-manager  Generated new private key
 Normal  OrderCreated   82s   cert-manager  Created Order resource "letsencrypt-prod-2626449824"
 Normal  OrderComplete  37s   cert-manager  Order "letsencrypt-prod-2626449824" completed successfully
 Normal  CertIssued     37s   cert-manager  Certificate issued successfully

HTTPSが正しく機能していることを確認するために、 `+ curl +`を使用してテストを実行します。

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を使用するようにリダイレクトされていることを示します。

`+ https:// echo 1.example.com `で ` curl`を実行します。

curl https://echo1.example.com

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

Outputecho1

詳細な `+ -v +`フラグを指定して前のコマンドを実行すると、証明書のハンドシェイクをより深く掘り下げ、証明書情報を検証できます。

この時点で、Nginx IngressのLet’s Encrypt証明書を使用してHTTPSを正常に設定できました。

結論

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

Nginx Ingress Controllerには多くの代替手段があります。 詳細については、Kubernetesの公式ドキュメントからhttps://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-controllers[Ingress controller]を参照してください。

Related