介绍 (Introduction)

Kubernetes Ingresses allow you to flexibly route traffic from outside your Kubernetes cluster to Services inside of your cluster. This is accomplished using Ingress Resources, which define rules for routing HTTP and HTTPS traffic to Kubernetes Services, and Ingress Controllers, which implement the rules by load balancing traffic and routing it to the appropriate backend Services. Popular Ingress Controllers include Nginx, Contour, HAProxy, and Traefik. Ingresses provide a more efficient and flexible alternative to setting up multiple LoadBalancer services, each of which uses its own dedicated Load Balancer.

Kubernetes 入口允许您灵活地将流量从Kubernetes集群外部路由到集群内部的服务。 这可以通过使用Ingress 资源 (用于定义将HTTP和HTTPS流量路由到Kubernetes Services的规则)以及Ingress Controllers (通过将流量进行负载平衡并将其路由到适当的后端服务来实现)来实现。 流行的入口控制器包括Nginx ， Contour ， HAProxy和Traefik 。 入口为设置多个LoadBalancer服务提供了一种更高效，更灵活的替代方法，每个服务都使用自己的专用负载均衡器。

In this guide, we’ll set up the Kubernetes-maintained Nginx Ingress Controller, and create some Ingress Resources to route traffic to several dummy backend services. Once we’ve set up the Ingress, we’ll install cert-manager into our cluster to manage and provision TLS certificates for encrypting HTTP traffic to the Ingress. This guide does not use the Helm package manager. For a guide on rolling out the Nginx Ingress Controller using Helm, consult How To Set Up an Nginx Ingress on DigitalOcean Kubernetes Using Helm.

在本指南中，我们将设置Kubernetes维护的Nginx Ingress Controller ，并创建一些Ingress资源以将流量路由到几个虚拟后端服务。 设置Ingress后，我们将在群集中安装cert-manager来管理和配置TLS证书，以加密到Ingress的HTTP流量。 本指南不使用头盔包管理器。 有关使用Helm推出Nginx入口控制器的指南，请参阅如何使用Helm在DigitalOcean Kubernetes上设置Nginx入口 。

先决条件 (Prerequisites)

Before you begin with this guide, you should have the following available to you:

在开始使用本指南之前，您应该具备以下功能：

• A Kubernetes 1.10+ cluster with role-based access control (RBAC) enabled

  启用了基于角色的访问控制 (RBAC)的Kubernetes 1.10+集群

• The kubectl command-line tool installed on your local machine and configured to connect to your cluster. You can read more about installing kubectl in the official documentation.

  kubectl命令行工具安装在本地计算机上，并配置为连接到集群。 您可以在官方文档中阅读有关安装kubectl更多信息。

• A domain name and DNS A records which you can point to the DigitalOcean Load Balancer used by the Ingress. If you are using DigitalOcean to manage your domain’s DNS records, consult How to Manage DNS Records to learn how to create A records.

  域名和DNS A记录，您可以指向Ingress使用的DigitalOcean负载均衡器。 如果您正在使用DigitalOcean来管理域的DNS记录，请查阅如何管理DNS记录以了解如何创建A记录。

• The wget command-line utility installed on your local machine. You can install wget using the package manager built into your operating system.

  安装在本地计算机上的wget命令行实用程序。 您可以使用操作系统内置的软件包管理器来安装wget 。

Once you have these components set up, you’re ready to begin with this guide.

设置好这些组件之后，就可以开始使用本指南了。

步骤1 —设置虚拟后端服务 (Step 1 — Setting Up Dummy Backend Services)

Before we deploy the Ingress Controller, we’ll first create and roll out two dummy echo Services to which we’ll route external traffic using the Ingress. The echo Services will run the hashicorp/http-echo web server container, which returns a page containing a text string passed in when the web server is launched. To learn more about http-echo, consult its GitHub Repo, and to learn more about Kubernetes Services, consult Services from the official Kubernetes docs.

在部署Ingress Controller之前，我们将首先创建并推出两个虚拟echo服务，然后使用Ingress将外部流量路由到这些服务。 echo Services将运行hashicorp/http-echo Web服务器容器，该容器返回一个页面，其中包含启动Web服务器时传入的文本字符串。 要了解有关http-echo更多信息，请查阅其GitHub Repo ；要了解有关Kubernetes Services的更多信息，请查阅来自Kubernetes官方文档的Services 。

On your local machine, create and edit a file called echo1.yaml using nano or your favorite editor:

在本地计算机上，使用nano或您喜欢的编辑器创建并编辑一个名为echo1.yaml的文件：

Paste in the following Service and Deployment manifest:

粘贴以下服务和部署清单：

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

In this file, we define a Service called echo1 which routes traffic to Pods with the app: echo1 label selector. It accepts TCP traffic on port 80 and routes it to port 5678,http-echo’s default port.

在此文件中，我们定义了一个名为echo1的服务，该服务使用以下app: echo1流量路由到Pods app: echo1标签选择器。 它在端口80上接受TCP通信，并将其路由到http-echo的默认端口5678 。

We then define a Deployment, also called echo1, which manages Pods with the app: echo1 Label Selector. We specify that the Deployment should have 2 Pod replicas, and that the Pods should start a container called echo1 running the hashicorp/http-echo image. We pass in the text parameter and set it to echo1, so that the http-echo web server returns echo1. Finally, we open port 5678 on the Pod container.

然后，我们定义一个Deployment，也称为echo1 ，它使用以下app: echo1管理Pod app: echo1 Label Selector 。 我们指定Deployment应该具有2个Pod副本，并且Pods应该启动一个运行hashicorp/http-echo映像的名为echo1的容器。 我们传入text参数并将其设置为echo1 ，以便http-echo Web服务器返回echo1 。 最后，我们打开Pod容器上的端口5678 。

Once you’re satisfied with your dummy Service and Deployment manifest, save and close the file.

对虚拟的“服务和部署”清单满意后，保存并关闭文件。

Then, create the Kubernetes resources using kubectl apply with the -f flag, specifying the file you just saved as a parameter:

然后，使用带有-f标志的kubectl apply创建Kubernetes资源，指定刚刚保存为参数的文件：

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
service/echo1 created
deployment.apps/echo1 created

Verify that the Service started correctly by confirming that it has a ClusterIP, the internal IP on which the Service is exposed:

通过确认服务具有一个ClusterIP(该服务公开在其上的内部IP)来验证该服务是否正确启动：

You should see the following output:

您应该看到以下输出：

   
   

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

This indicates that the echo1 Service is now available internally at 10.245.222.129 on port 80. It will forward traffic to containerPort 5678 on the Pods it selects.

这表明echo1服务现在可以在端口80上的10.245.222.129内部使用。 它将流量转发到5678上的containerPort 5678 。

Now that the echo1 Service is up and running, repeat this process for the echo2 Service.

现在echo1服务已启动并正在运行，请对echo2服务重复此过程。

Create and open a file called 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

Here, we essentially use the same Service and Deployment manifest as above, but name and relabel the Service and Deployment echo2. In addition, to provide some variety, we create only 1 Pod replica. We ensure that we set the text parameter to echo2 so that the web server returns the text echo2.

在这里，我们基本上使用与上述相同的Service and Deployment清单，但是命名并重新标记Service and Deployment echo2 。 此外，为了提供多种功能，我们仅创建1个Pod副本。 我们确保将text参数设置为echo2以便Web服务器返回文本echo2 。

Save and close the file, and create the Kubernetes resources using kubectl:

保存并关闭文件，并使用kubectl创建Kubernetes资源：

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
service/echo2 created
deployment.apps/echo2 created

Once again, verify that the Service is up and running:

再次确认服务已启动并正在运行：

You should see both the echo1 and echo2 Services with assigned ClusterIPs:

您应该同时看到带有分配的ClusterIP的echo1和echo2服务：

   
   

    
    Output
   
   
NAME         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

Now that our dummy echo web services are up and running, we can move on to rolling out the Nginx Ingress Controller.

现在我们的虚拟echo Web服务已启动并正在运行，我们可以继续部署Nginx Ingress Controller。

步骤2 —设置Kubernetes Nginx入口控制器 (Step 2 — Setting Up the Kubernetes Nginx Ingress Controller)

In this step, we’ll roll out v0.26.1 of the Kubernetes-maintained Nginx Ingress Controller. Note that there are several Nginx Ingress Controllers; the Kubernetes community maintains the one used in this guide and Nginx Inc. maintains kubernetes-ingress. The instructions in this tutorial are based on those from the official Kubernetes Nginx Ingress Controller Installation Guide.

在这一步中，我们将推出v0.26.1的Kubernetes维护的Nginx的入口控制 。 注意，有几个 Nginx入口控制器。 Kubernetes社区维护本指南中使用的那个，而Nginx Inc.维护kubernetes-ingress 。 本教程中的说明基于官方的《 Kubernetes Nginx Ingress Controller 安装指南》中的说明 。

The Nginx Ingress Controller consists of a Pod that runs the Nginx web server and watches the Kubernetes Control Plane for new and updated Ingress Resource objects. An Ingress Resource is essentially a list of traffic routing rules for backend Services. For example, an Ingress rule can specify that HTTP traffic arriving at the path /web1 should be directed towards the web1 backend web server. Using Ingress Resources, you can also perform host-based routing: for example, routing requests that hit web1.your_domain.com to the backend Kubernetes Service web1.

Nginx Ingress Controller由一个Pod组成，该Pod运行Nginx Web服务器并监视Kubernetes Control Plane中是否有新的和更新的Ingress Resource对象。 入口资源本质上是后端服务的流量路由规则的列表。 例如，一个Ingress规则可以指定到达路径/web1 HTTP通信应定向到web1后端Web服务器。 使用Ingress资源，您还可以执行基于主机的路由：例如，将命中web1.your_domain.com请求路由到后端Kubernetes服务web1 。

In this case, because we’re deploying the Ingress Controller to a DigitalOcean Kubernetes cluster, the Controller will create a LoadBalancer Service that spins up a DigitalOcean Load Balancer to which all external traffic will be directed. This Load Balancer will route external traffic to the Ingress Controller Pod running Nginx, which then forwards traffic to the appropriate backend Services.

在这种情况下，因为我们正在将入口控制器部署到DigitalOcean Kubernetes集群，所以控制器将创建一个LoadBalancer服务，以启动DigitalOcean负载平衡器，所有外部流量都将定向到该服务。 此负载均衡器会将外部流量路由到运行Nginx的Ingress Controller Pod，然后将流量转发到适当的后端服务。

We’ll begin by first creating the Kubernetes resources required by the Nginx Ingress Controller. These consist of ConfigMaps containing the Controller’s configuration, Role-based Access Control (RBAC) Roles to grant the Controller access to the Kubernetes API, and the actual Ingress Controller Deployment which uses v0.26.1 of the Nginx Ingress Controller image. To see a full list of these required resources, consult the manifest from the Kubernetes Nginx Ingress Controller’s GitHub repo.

首先，我们将创建Nginx Ingress Controller所需的Kubernetes资源。 其中包括包含控制器配置的ConfigMap，用于授予控制器对Kubernetes API的访问权限的基于角色的访问控制(RBAC)角色，以及使用Nginx Ingress Controller映像v0.26.1的实际Ingress Controller部署。 要查看这些必需资源的完整列表，请查阅Kubernetes Nginx Ingress Controller的GitHub存储库中的清单 。

To create these mandatory resources, use kubectl apply and the -f flag to specify the manifest file hosted on GitHub:

要创建这些强制性资源，请使用kubectl apply和-f标志来指定托管在GitHub上的清单文件：

We use apply here so that in the future we can incrementally apply changes to the Ingress Controller objects instead of completely overwriting them. To learn more about apply, consult Managing Resources from the official Kubernetes docs.

我们在此处使用apply ，以便将来我们可以apply更改增量地apply Ingress Controller对象，而不是完全覆盖它们。 要了解有关apply更多信息，请查阅Kubernetes官方文档中的管理资源 。

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
namespace/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.apps/nginx-ingress-controller created

This output also serves as a convenient summary of all the Ingress Controller objects created from the mandatory.yaml manifest.

该输出还用作所有入口控制器对象从所创建的一个方便的摘要mandatory.yaml清单。

Next, we’ll create the Ingress Controller LoadBalancer Service, which will create a DigitalOcean Load Balancer that will load balance and route HTTP and HTTPS traffic to the Ingress Controller Pod deployed in the previous command.

接下来，我们将创建Ingress Controller LoadBalancer服务，该服务将创建DigitalOcean负载均衡器，以实现负载均衡并将HTTP和HTTPS流量路由到上一条命令中部署的Ingress Controller Pod。

To create the LoadBalancer Service, once again kubectl apply a manifest file containing the Service definition:

要创建LoadBalancer服务，请再次kubectl apply包含服务定义的清单文件：

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
service/ingress-nginx created

Confirm that the Ingress Controller Pods have started:

确认Ingress Controller Pod已启动：

   
   

    
    Output
   
   
NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx   nginx-ingress-controller-7fb85bc8bb-lnm6z   1/1     Running   0          2m42s

Now, confirm that the DigitalOcean Load Balancer was successfully created by fetching the Service details with kubectl:

现在，通过使用kubectl提取服务详细信息，确认DigitalOcean负载均衡器已成功创建：

After several minutes, you should see an external IP address, corresponding to the IP address of the DigitalOcean Load Balancer:

几分钟后，您应该看到一个外部IP地址，该地址与DigitalOcean Load Balancer的IP地址相对应：

   
   

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

Note down the Load Balancer’s external IP address, as you’ll need it in a later step.

记下负载均衡器的外部IP地址，因为在后续步骤中将需要它。

Note: By default the Nginx Ingress LoadBalancer Service has service.spec.externalTrafficPolicy set to the value Local, which routes all load balancer traffic to nodes running Nginx Ingress Pods. The other nodes will deliberately fail load balancer health checks so that Ingress traffic does not get routed to them. External traffic policies are beyond the scope of this tutorial, but to learn more you can consult A Deep Dive into Kubernetes External Traffic Policies and Source IP for Services with Type=LoadBalancer from the official Kubernetes docs.

注意：默认情况下，Nginx Ingress LoadBalancer服务的service.spec.externalTrafficPolicy设置为Local ，它将所有负载均衡器流量路由到运行Nginx Ingress Pod的节点。 其他节点将故意使负载均衡器运行状况检查失败，以使Ingress流量不会被路由到它们。 外部流量策略不在本教程的讨论范围之内，但是要了解更多信息，请查阅Kubernetes官方文档中的“ 深入研究Kubernetes外部流量策略和具有Type = LoadBalancer的服务源IP” 。

This load balancer receives traffic on HTTP and HTTPS ports 80 and 443, and forwards it to the Ingress Controller Pod. The Ingress Controller will then route the traffic to the appropriate backend Service.

此负载平衡器在HTTP和HTTPS端口80和443上接收流量，并将其转发到Ingress Controller Pod。 然后，入口控制器会将流量路由到适当的后端服务。

We can now point our DNS records at this external Load Balancer and create some Ingress Resources to implement traffic routing rules.

现在，我们可以将DNS记录指向此外部负载均衡器，并创建一些入口资源来实现流量路由规则。

第3步-创建入口资源 (Step 3 — Creating the Ingress Resource)

Let’s begin by creating a minimal Ingress Resource to route traffic directed at a given subdomain to a corresponding backend Service.

让我们首先创建一个最小的Ingress资源，以将定向到给定子域的流量路由到相应的后端服务。

In this guide, we’ll use the test domain example.com. You should substitute this with the domain name you own.

在本指南中，我们将使用测试域example.com 。 您应该用您拥有的域名代替它。

We’ll first create a simple rule to route traffic directed at echo1.example.com to the echo1 backend service and traffic directed at echo2.example.com to the echo2 backend service.

首先，我们将创建一个简单的规则来路由指向echo1的流量。 example.com到echo1后端服务以及定向到echo2的流量。 example.com到echo2后端服务。

Begin by opening up a file called echo_ingress.yaml in your favorite editor:

首先在您喜欢的编辑器中打开一个名为echo_ingress.yaml的文件：

Paste in the following ingress definition:

粘贴以下入口定义：

apiVersion: networking.k8s.io/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

When you’ve finished editing your Ingress rules, save and close the file.

完成Ingress规则的编辑后，保存并关闭文件。

Here, we’ve specified that we’d like to create an Ingress Resource called echo-ingress, and route traffic based on the Host header. An HTTP request Host header specifies the domain name of the target server. To learn more about Host request headers, consult the Mozilla Developer Network definition page. Requests with host echo1.example.com will be directed to the echo1 backend set up in Step 1, and requests with host echo2.example.com will be directed to the echo2 backend.

在这里，我们指定了要创建一个名为echo-ingress的Ingress资源，并根据Host标头路由流量。 HTTP请求主机标头指定目标服务器的域名。 要了解有关主机请求标头的更多信息，请查阅Mozilla开发人员网络定义页面 。 带有主机echo1的请求。 example.com将定向到步骤1中设置的echo1后端，并向主机echo2发出请求。 example.com将定向到echo2后端。

You can now create the Ingress using kubectl:

现在，您可以使用kubectl创建Ingress：

You’ll see the following output confirming the Ingress creation:

您将看到以下输出确认Ingress的创建：

   
   

    
    Output
   
   
ingress.extensions/echo-ingress created

To test the Ingress, navigate to your DNS management service and create A records for echo1.example.com and echo2.example.com pointing to the DigitalOcean Load Balancer’s external IP. The Load Balancer’s external IP is the external IP address for the ingress-nginx Service, which we fetched in the previous step. If you are using DigitalOcean to manage your domain’s DNS records, consult How to Manage DNS Records to learn how to create A records.

要测试Ingress，请导航到您的DNS管理服务，并为echo1.example.com和echo2.example.com创建A记录，指向DigitalOcean负载均衡器的外部IP。 负载平衡器的外部IP是我们在上一步中获取的ingress-nginx服务的外部IP地址。 如果您使用DigitalOcean来管理域的DNS记录，请查阅如何管理DNS记录以了解如何创建A记录。

Once you’ve created the necessary echo1.example.com and echo2.example.com DNS records, you can test the Ingress Controller and Resource you’ve created using the curl command line utility.

创建必要的echo1.example.com和echo2.example.com DNS记录后，就可以使用curl命令行实用工具测试您创建的Ingress Controller和资源。

From your local machine, curl the echo1 Service:

在您的本地计算机上， curl echo1服务：

You should get the following response from the echo1 service:

您应该从echo1服务获得以下响应：

   
   

    
    Output
   
   
echo1

This confirms that your request to echo1.example.com is being correctly routed through the Nginx ingress to the echo1 backend Service.

这确认您对echo1.example.com的请求已通过Nginx入口正确路由到echo1后端服务。

Now, perform the same test for the echo2 Service:

现在，对echo2服务执行相同的测试：

You should get the following response from the echo2 Service:

您应该从echo2服务获得以下响应：

   
   

    
    Output
   
   
echo2

This confirms that your request to echo2.example.com is being correctly routed through the Nginx ingress to the echo2 backend Service.

这确认您对echo2.example.com的请求已通过Nginx入口正确路由到echo2后端服务。

At this point, you’ve successfully set up a minimal Nginx Ingress to perform virtual host-based routing. In the next step, we’ll install cert-manager to provision TLS certificates for our Ingress and enable the more secure HTTPS protocol.

至此，您已经成功设置了最小的Nginx Ingress来执行基于虚拟主机的路由。 在下一步中，我们将安装cert-manager为我们的Ingress设置TLS证书，并启用更安全的HTTPS协议。

步骤4 —安装和配置Cert-Manager (Step 4 — Installing and Configuring Cert-Manager)

In this step, we’ll install cert-manager into our cluster. cert-manager is a Kubernetes service that provisions TLS certificates from Let’s Encrypt and other certificate authorities and manages their lifecycles. Certificates can be requested and configured by annotating Ingress Resources with the cert-manager.io/issuer annotation, appending a tls section to the Ingress spec, and configuring one or more Issuers or ClusterIssuers to specify your preferred certificate authority. To learn more about Issuer and ClusterIssuer objects, consult the official cert-manager documentation on Issuers.

在此步骤中，我们将cert-manager安装到我们的集群中。 cert-manager是Kubernetes服务，它提供来自Let's Encrypt和其他证书颁发机构的TLS证书，并管理其生命周期。 可以通过以下方式来请求和配置证书：使用cert-manager.io/issuer注释对Ingress资源进行注释，在Ingress规范后附加tls部分，并配置一个或多个Issuers或ClusterIssuers以指定首选的证书颁发机构。 要了解有关Issuer和ClusterIssuer对象的更多信息，请查阅关于Issuers的官方cert-manager文档。

Before we install cert-manager, we’ll first create a Namespace for it to run in:

在安装cert-manager之前，我们将首先创建一个命名空间以使其在以下环境中运行：

Next, we’ll install cert-manager and its Custom Resource Definitions (CRDs) like Issuers and ClusterIssuers. Do this by applying the manifest directly from the cert-manager GitHub repository :

接下来，我们将安装cert-manager及其自定义资源定义 (CRD)，例如Issuers和ClusterIssuers。 通过直接从cert-manager GitHub存储库中 apply清单来执行此操作：

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
customresourcedefinition.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

To verify our installation, check the cert-manager Namespace for running pods:

要验证我们的安装，请检查cert-manager命名空间中正在运行的Pod：

   
   

    
    Output
   
   
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c47f46f57-jknnx              1/1     Running   0          27s
cert-manager-cainjector-6659d6844d-j8cbg   1/1     Running   0          27s
cert-manager-webhook-547567b88f-qks44      1/1     Running   0          27s

This indicates that the cert-manager installation succeeded.

这表明证书管理器安装成功。

Before we begin issuing certificates for our Ingress hosts, we need to create an Issuer, which specifies the certificate authority from which signed x509 certificates can be obtained. In this guide, we’ll use the Let’s Encrypt certificate authority, which provides free TLS certificates and offers both a staging server for testing your certificate configuration, and a production server for rolling out verifiable TLS certificates.

在开始为Ingress主机颁发证书之前，我们需要创建一个Issuer，该颁发者指定可以从中获取签名的x509证书的证书颁发机构。 在本指南中，我们将使用“让我们加密”证书颁发机构，该机构提供免费的TLS证书，并提供用于测试证书配置的登台服务器，以及用于推出可验证的TLS证书的生产服务器。

Let’s create a test Issuer to make sure the certificate provisioning mechanism is functioning correctly. Open a file named staging_issuer.yaml in your favorite text editor:

让我们创建一个测试颁发者，以确保证书供应机制正常运行。 在您喜欢的文本编辑器中打开一个名为staging_issuer.yaml的文件：

nano staging_issuer.yaml

Paste in the following ClusterIssuer manifest:

粘贴在以下ClusterIssuer清单中：

apiVersion: cert-manager.io/v1alpha2
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

Here we specify that we’d like to create a ClusterIssuer object called letsencrypt-staging, and use the Let’s Encrypt staging server. We’ll later use the production server to roll out our certificates, but the production server may rate-limit requests made against it, so for testing purposes it’s best to use the staging URL.

在这里，我们指定我们想要创建一个名为letsencrypt-staging的ClusterIssuer对象，并使用Let's Encrypt登台服务器。 稍后我们将使用生产服务器推出我们的证书，但是生产服务器可能会对针对它的请求进行速率限制，因此出于测试目的，最好使用登台URL。

We then specify an email address to register the certificate, and create a Kubernetes Secret called letsencrypt-staging to store the ACME account’s private key. We also enable the HTTP-01 challenge mechanism. To learn more about these parameters, consult the official cert-manager documentation on Issuers.

然后，我们指定一个电子邮件地址来注册证书，并创建一个名为letsencrypt-staging的Kubernetes Secret，以存储ACME帐户的私钥。 我们还启用了HTTP-01质询机制。 要了解有关这些参数的更多信息，请参阅Issuers上的官方cert-manager文档。

Roll out the ClusterIssuer using kubectl:

使用kubectl推出ClusterIssuer：

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
clusterissuer.cert-manager.io/letsencrypt-staging created

Now that we’ve created our Let’s Encrypt staging Issuer, we’re ready to modify the Ingress Resource we created above and enable TLS encryption for the echo1.example.com and echo2.example.com paths.

现在，我们已经创建了“让我们加密”登台颁发者，现在可以修改上面创建的Ingress资源，并为echo1.example.com和echo2.example.com路径启用TLS加密。

Open up echo_ingress.yaml once again in your favorite editor:

在您喜欢的编辑器中再次打开echo_ingress.yaml ：

Add the following to the Ingress Resource manifest:

将以下内容添加到Ingress资源清单中：

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

Here we add some annotations to specify the ingress.class, which determines the Ingress Controller that should be used to implement the Ingress Rules. In addition, we define the cluster-issuer to be letsencrypt-staging, the certificate Issuer we just created.

在这里，我们添加了一些注释以指定ingress.class ，该注释确定应该用于实现Ingress Rules的Ingress Controller。 另外，我们将cluster-issuer定义为letsencrypt-staging ，即我们刚刚创建的证书颁发者。

Finally, we add a tls block to specify the hosts for which we want to acquire certificates, and specify a secretName. This secret will contain the TLS private key and issued certificate.

最后，我们添加一个tls块以指定要为其获取证书的主机，并指定secretName 。 此机密将包含TLS私钥和已颁发的证书。

When you’re done making changes, save and close the file.

完成更改后，保存并关闭文件。

We’ll now update the existing Ingress Resource using kubectl apply:

现在，我们将使用kubectl apply更新现有的Ingress资源：

You should see the following output:

您应该看到以下输出：

   
   

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

You can use kubectl describe to track the state of the Ingress changes you’ve just applied:

您可以使用kubectl describe跟踪刚刚应用的Ingress更改的状态：

   
   

    
    Output
   
   
Events:
  Type    Reason             Age               From                      Message
  ----    ------             ----              ----                      -------
  Normal  CREATE             14m               nginx-ingress-controller  Ingress default/echo-ingress
  Normal  CreateCertificate  67s   cert-manager              Successfully created Certificate "echo-tls"
  Normal  UPDATE             53s   nginx-ingress-controller  Ingress default/echo-ingress

Once the certificate has been successfully created, you can run an additional describe on it to further confirm its successful creation:

成功创建证书后，可以在其上运行附加describe以进一步确认其成功创建：

You should see the following output in the Events section:

您应该在“ Events部分中看到以下输出：

   
   

    
    Output
   
   
Events:
  Type    Reason         Age   From          Message
  ----    ------         ----  ----          -------
  Normal  GeneratedKey  2m12s  cert-manager  Generated a new private key
  Normal  Requested     2m12s  cert-manager  Created new CertificateRequest resource "echo-tls-3768100355"
  Normal  Issued        47s    cert-manager  Certificate issued successfully

This confirms that the TLS certificate was successfully issued and HTTPS encryption is now active for the two domains configured.

这确认TLS证书已成功颁发，并且HTTPS加密现在对于配置的两个域是活动的。

We’re now ready to send a request to a backend echo server to test that HTTPS is functioning correctly.

现在，我们准备向后端echo服务器发送请求，以测试HTTPS是否正常运行。

Run the following wget command to send a request to echo1.example.com and print the response headers to STDOUT:

运行以下wget命令将请求发送到echo1.example.com并将响应标头打印到STDOUT ：

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
. . .
HTTP request sent, awaiting response... 308 Permanent Redirect
. . .
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'.

This indicates that HTTPS has successfully been enabled, but the certificate cannot be verified as it’s a fake temporary certificate issued by the Let’s Encrypt staging server.

这表明HTTPS已成功启用，但是该证书是由Let's Encrypt登台服务器颁发的虚假临时证书，因此无法验证。

Now that we’ve tested that everything works using this temporary fake certificate, we can roll out production certificates for the two hosts echo1.example.com and echo2.example.com.

现在，我们已经测试了使用此临时伪造证书可以正常运行的所有内容，接下来我们可以为两个主机echo1.example.com和echo2.example.com推出生产证书。

第5步-推出生产发行人 (Step 5 — Rolling Out Production Issuer)

In this step we’ll modify the procedure used to provision staging certificates, and generate a valid, verifiable production certificate for our Ingress hosts.

在此步骤中，我们将修改用于配置登台证书的过程，并为Ingress主机生成有效的，可验证的生产证书。

To begin, we’ll first create a production certificate ClusterIssuer.

首先，我们将首先创建生产证书ClusterIssuer。

Open a file called prod_issuer.yaml in your favorite editor:

在您喜欢的编辑器中打开一个名为prod_issuer.yaml的文件：

nano prod_issuer.yaml

Paste in the following manifest:

粘贴以下清单：

apiVersion: cert-manager.io/v1alpha2
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

Note the different ACME server URL, and the letsencrypt-prod secret key name.

请注意不同的ACME服务器URL，以及letsencrypt-prod密钥名称。

When you’re done editing, save and close the file.

完成编辑后，保存并关闭文件。

Now, roll out this Issuer using kubectl:

现在，使用kubectl发行此Issuer：

You should see the following output:

您应该看到以下输出：

   
   

    
    Output
   
   
clusterissuer.cert-manager.io/letsencrypt-prod created

Update echo_ingress.yaml to use this new Issuer:

更新echo_ingress.yaml以使用此新的发行者：

Make the following change to the file:

对文件进行以下更改：

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

Here, we update the ClusterIssuer name to letsencrypt-prod.

在这里，我们将ClusterIssuer名称更新为letsencrypt-prod 。

Once you’re satisfied with your changes, save and close the file.

对更改满意后，保存并关闭文件。

Roll out the changes using kubectl apply:

使用kubectl apply推出更改：

   
   

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

Wait a couple of minutes for the Let’s Encrypt production server to issue the certificate. You can track its progress using kubectl describe on the certificate object:

等待几分钟，让我们加密生产服务器颁发证书。 您可以使用certificate对象上的kubectl describe跟踪其进度：

Once you see the following output, the certificate has been issued successfully:

一旦看到以下输出，则证书已成功颁发：

   
   

    
    Output
   
   
Events:
  Type    Reason        Age                  From          Message
  ----    ------        ----                 ----          -------
  Normal  GeneratedKey  8m10s                cert-manager  Generated a new private key
  Normal  Requested     8m10s                cert-manager  Created new CertificateRequest resource "echo-tls-3768100355"
  Normal  Requested     35s                  cert-manager  Created new CertificateRequest resource "echo-tls-4217844635"
  Normal  Issued        10s (x2 over 6m45s)  cert-manager  Certificate issued successfully

We’ll now perform a test using curl to verify that HTTPS is working correctly:

现在，我们将使用curl进行测试以验证HTTPS是否正常运行：

You should see the following:

您应该看到以下内容：

   
   

    
    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>

This indicates that HTTP requests are being redirected to use HTTPS.

这表明HTTP请求被重定向为使用HTTPS。

Run curl on https://echo1.example.com:

在https://echo1.example.com上运行curl ：

You should now see the following output:

现在，您应该看到以下输出：

   
   

    
    Output
   
   
echo1

You can run the previous command with the verbose -v flag to dig deeper into the certificate handshake and to verify the certificate information.

您可以使用详细的-v标志运行前面的命令，以更深入地了解证书握手并验证证书信息。

At this point, you’ve successfully configured HTTPS using a Let’s Encrypt certificate for your Nginx Ingress.

至此，您已经使用Nginx Ingress的Let's Encrypt证书成功配置了HTTPS。

结论 (Conclusion)

In this guide, you set up an Nginx Ingress to load balance and route external requests to backend Services inside of your Kubernetes cluster. You also secured the Ingress by installing the cert-manager certificate provisioner and setting up a Let’s Encrypt certificate for two host paths.

在本指南中，您将设置一个Nginx Ingress来进行负载平衡，并将外部请求路由到Kubernetes集群内部的后端服务。 您还可以通过安装cert-manager证书提供程序并为两个主机路径设置Let's Encrypt证书来保护Ingress。

There are many alternatives to the Nginx Ingress Controller. To learn more, consult Ingress controllers from the official Kubernetes documentation.

Nginx入口控制器有很多替代方案。 要了解更多信息，请查阅Kubernetes官方文档中的Ingress控制器 。

For a guide on rolling out the Nginx Ingress Controller using the Helm Kubernetes package manager, consult How To Set Up an Nginx Ingress on DigitalOcean Kubernetes Using Helm.

有关使用Helm Kubernetes软件包管理器推出Nginx Ingress Controller的指南，请参阅如何使用Helm在DigitalOcean Kubernetes上设置Nginx Ingress 。

翻译自: https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes