【翻译】用Kubernetes Ingress Controller管理Docker应用程序

CSDN-Ada助手

于 2022-11-19 03:13:08 发布

阅读量216

点赞数

分类专栏：翻译

翻译专栏收录该内容

296 篇文章 14 订阅

订阅专栏

作者：Alvin Lee 2021年9月17日

原文为Alvin Lee在Kong的博客上发表的客座文章

回想一下，当你的开发团队转换到Docker化容器时。曾经需要在虚拟机上提供多种服务的应用程序过渡到由多个整齐的Docker容器组成的应用程序。虽然结果是一个精简的系统，但这个过渡可能是令人生畏的。

现在，是时候进行另一次转型飞跃了：从单一的容器集转移到使用Kubernetes的复制集的高可用、协调的部署。这似乎是一个巨大的转变，但你可以通过使用开源的入口控制器来简化你的任务，并提供你可以根据需要定制的插件，从而减少道路上的颠簸。

在本教程中，我们将从一个由三个容器组成的Docker化应用程序开始：一个Web服务器、一个数据库和一个键值存储。我们将学习如何使用Kong的Kubernetes Ingress Controller（文档）在Kubernetes（K8s）上部署这个应用，以暴露容器的端口供外部访问。最后，我们将熟悉如何用ingress控制器设置一些Kong插件。

核心概念

在我们深入研究之前，让我们简单看看我们的演练的一些核心概念。

Docker

Docker通常用于平台即服务（PaaS）产品，通过将应用程序的各个部分隔离到容器中来进行应用开发。每个容器是一个标准化的软件单元，可以独立运行。

例如，一个与特定版本挂钩的Postgresql数据库可以完全在自己的Docker容器中运行。容器是标准的，可以在任何开发人员的机器上运行。不再有这样的问题："为什么查询在我的机器上可以运行，而在你的机器上不行？你的环境设置是什么？"当你在Docker容器内运行你的应用服务时，你确保每个人都在相同的环境中运行相同的应用。

Kubernetes (K8s)

应用程序很快从单一的Docker容器发展到多个容器共同工作的组合。人们可能会使用像Docker Compose这样的应用程序来部署一个多容器应用程序。

然而，下一步的进展是将同一应用的多个副本协调为一个集群，在集群内的副本节点之间分配负载，并在单个应用节点出现故障时提供后备节点。今天，这种协调和管理的事实标准是Kubernetes。许多云服务提供商--包括AWS、Azure和谷歌云--都提供Kubernetes。

Kong Kubernetes Ingress控制器

Ingress是K8s的一个关键部分，管理外部对Kubernetes集群内部服务的访问。在一个集群中，Web服务器容器可以与数据库容器对话，但如果外部世界不能与Web服务器对话，那有什么用呢？在K8s中，与外部世界的通信需要一个入口控制器。开源的Kong Kubernetes Ingress Controller包裹着Kong Gateway和Kong的各种插件来扮演这个关键的角色。

基本用例

在我们的基本用例中，我们有一个由Web服务器（NGINX）、数据库（PostgreSQL）和键值存储（Redis）组成的应用程序。这个应用通常以三个Docker容器的形式运行。我们需要将这个应用过渡到K8s，但我们需要设置一个入口，以便从K8s集群之外访问我们的服务。

我们的小型项目方法

对于我们的迷你项目演练，我们将采取这种方法。

使用谷歌Kubernetes引擎（GKE）创建一个简单、低成本的K8s集群。
使用kubectl来配置集群，以部署我们的多容器应用程序。
配置并集成Kong Kubernetes Ingress Controller，使我们能够从外部访问我们应用程序的服务。
添加使用一个支持HTTPS的cert-manager，以及用于外部日志和请求路由的Kong插件。

你需要什么？

要在这个演练中与我们并肩作战，你需要一个谷歌云平台账户，它有一个初始的免费层，有一个初始的使用信用。

在你的本地机器上，你需要能在命令行下工作，并安装以下工具。

kubectl- 用于在K8s集群上运行配置命令
Google Cloud SDK- 用于连接GKE集群，使其成为你的kubectl上下文。

你准备好深入了解容器和集群了吗？我们开始吧!

第一步：创建一个GKE集群

假设你已经建立了你的谷歌云平台账户，导航到控制台，通过左上角的项目列表下拉菜单创建一个新项目。

Screenshot of Google Cloud Platform dashboard clicking on "select a project"

为你的项目选择一个名称（例如：k8s-with-kong）并创建它。在该项目中工作，通过左侧菜单侧边栏导航，找到 "Kubernetes引擎→集群"。

在出现的页面上，点击 "启用 "按钮，将GKE用于你的项目。这个过程可能需要一到两分钟，谷歌才会为你的项目启动一切。之后，你会发现自己在GKE的集群页面上。点击 "创建"。

Screenshot showing pop up window Kubernetes clusters, click create

选择配置一个 "标准 "集群。为你的集群设置一个名称，以及一个区域。

Screenshot showing cluster basics, type name "my-application", location type select "regional", region select "us-central1"

接下来，在左边的菜单栏，找到 "NODE POOLS"，点击 "default-pool:"。

Screenshot showing node pools, select default-pool

对于节点池，将其大小设置为1。我们将保持我们的集群的资源使用量很小，因为这只是一个演示的小项目。

Screenshot showing node pool details, type name: default-pool, size choose "1"

点击页面底部的 "创建"。

你的K8s集群将需要几分钟的时间来启动。

使用gcloud来配置kubectl的集群访问

随着我们的GKE集群的启动和运行，我们想通过本地机器上的kubectl来设置对集群的访问。要做到这一点，我们遵循GKE文档页面上的简单步骤。

~$ gcloud init # 按照提示登录到你的谷歌云账户。 # 选择你的云项目（在我们的例子中：k8s-with-kong） 你想配置一个默认的计算区域和区域吗？(Y/n)? n

接下来，我们将生成一个kubeconfig条目，对GKE集群运行我们的kubectl命令。在这个步骤中，你将需要在创建集群时指定的集群名称和区域。

~$ gcloud container clusters get-credentials my-application --region=us-central1 获取集群端点和认证数据，为my-application生成kubeconfig条目。

有了这些，我们就可以开始通过kubectl运行命令来配置我们的部署。

第二步：通过kubectl部署应用程序

为了部署我们的应用程序，我们将需要创建一个deployment.yml文件和一个service.yml文件。deployment.yml文件应该看起来像这样。

apiVersion: apps/v1 kind:部署元数据：名称：my-app 标签：应用：my-app 规格：replicas。1 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: server image: nginx:1.19-alpine imagePullPolicy:Always ports: - containerPort: 80 - name: postgres image: postgres:13.2-alpine imagePullPolicy:Always env: - name: POSTGRES_PASSWORD value: postgrespassword ports: - containerPort: 5432 - name: redis image: redis:6.2-alpine imagePullPolicy:Always ports: - containerPort: 6379 command:["redis-server"] args: ["-requirepass", "redispassword"]

我们的部署将运行我们应用程序的一个副本，它由三个容器组成。我们有一个nginx网络服务器，我们将其称为server。该服务器的容器端口是80端口。

接下来，我们有一个Postgresql数据库在一个叫做postgres的容器中运行。这个数据库容器镜像的默认用户是postgres。我们还将把该用户的密码设置为postgres。该数据库容器的端口是5432。

最后，我们有我们的Redis键值存储，它将在容器上暴露6379端口。在Redis服务器启动时，我们将设置密码为redis。

有了我们的部署配置，让我们把它应用于我们的集群。

~/project$ kubectl apply -f deployment.yml deployment.apps/my-app created

几分钟后，你可以验证你的部署已经启动。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ~/project$ kubectl get deployment my-app NAME READY UP-TO-DATE AVAILABLE AGE my-app 1/1 1 1 3m15s ~/project$ kubectl get pods NAME READY STATUS RESTARTS AGE my-app-55db7c65f5-qjxs8 3/3 Running 0 4m16 ~/project$ kubectl logs my-app-55db7c65f5-qjxs8 server 。.在/etc/nginx/conf.d/default.conf/docker-entrypoint.sh中启用了IPv6监听。配置完成；准备启动 ~/project$ kubectl logs my-app-55db7c65f5-qjxs8 postgres ... 数据库系统准备接受连接 ~/project$ kubectl logs my-app-55db7c65f5-qjxs8 redis ...准备接受连接

接下来，我们需要配置service.yml，以便我们集群的容器上的端口可以从集群外部访问。

apiVersion: v1 kind: Service metadata: name: my-app labels: app: my-app spec: selector: app: my-app ports: - name: server port:80 targetPort: 80 - name: postgres protocol:TCP端口。5432 targetPort: 5432 - name: redis protocol:TCP端口。6379 targetPort: 6379

在这里，我们正在配置一个K8s服务，将我们pod上的传入端口映射到pod中各个容器的目标端口。为了简单起见，我们将使用相同的端口和目标端口的值。如果我们能在我们的K8s pod上得到一个80端口的请求，这个请求将被发送到服务器容器（我们的nginx容器）的80端口。同样，对5432端口的请求将被映射到postgres容器的5432端口，而对6379端口的请求将映射到redis容器的6379端口。

让我们用这个新的服务配置来更新我们的集群。

~/project$ kubectl apply -f service.yml service/my-app created

稍后，我们就可以检查我们的配置是否到位了。

~/project$ kubectl describe service my-app Name: my-app Namespace: default Labels: app=my-app Annotations: cloud.google.com/neg: {"ingress":true} Selector: app=my-app Type:              ClusterIP IP家族：<none> IP：10.72.128.227 IPs：<none> 端口：服务器 80/TCP 目标端口：80/TCP 端点。         10.72.0.130:80 端口：postgres 5432/TCP 目标端口：5432/TCP 端点。         10.72.0.130:5432 端口: redis 6379/TCP 目标端口: 6379/TCP 端点:         10.72.0.130:6379会话亲和力。  无事件：<无>。

这一切都很好，但你可能会注意到，虽然我们的端口都已暴露并被映射，但我们仍在一个私人网络中工作。我们需要将我们的整个K8s集群暴露给外部世界。为此，我们需要一个入口控制器。进入Kong。

第3步：配置Kong的Kubernetes入站控制器

配置Kong的Ingress控制器是相当简单的。让我们一个一个地完成这些步骤。

将Kong的Kubernetes入口控制器部署到GKE上

根据Kong Ingress Controller和GKE的文档页面的提示，我们首先需要创建一个ClusterRoleBinding，以便对我们即将进行的一些GKE集群配置有适当的管理权限。创建一个名为gke-role-binding.yml的文件，内容如下。

apiVersion: rbac.authorization.k8s.io/v1 kind:ClusterRoleBinding 元数据： name: cluster-admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind:ClusterRole name: cluster-admin subjects: - kind:用户名：[YOUR GOOGLE CLOUD ACCOUNT EMAIL ADDRESS] 命名空间：kube-system

让我们来应用这个角色绑定。

~/project$ kubectl apply -f gke-role-binding.yml clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-user created

接下来，我们部署Ingress控制器，使用Kong定制的部署和服务配置文件，并在https://bit.ly/k4k8s。

~/project$ kubectl apply -f https://bit.ly/k4k8s namespace/kong created ... service/kong-proxy created service/kong-validation-webhook created deployment.app/ingress-kong created

检查Ingress控制器是否部署。kong-proxy EXTERNAL_IP可能需要一分钟的时间来配置。

~/project$ kubectl get services -n kong NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kong-proxy LoadBalancer 10.72.130.214 34.71.43.9 80:32594/TCP,443:30982/TCP 71s kong-validation-webhook ClusterIP 10.72.130.92 <none> 443/TCP 70s

然后，我们设置一个环境变量，PROXY_IP，以保存与Kong代理相关的IP地址。

~/project$ export PROXY_IP=$(kubectl get -o \ jsonpath="{.status.loadBalancer.ingress[0].ip}"\ 服务 -n kong kong-proxy) ~/project$ echo $PROXY_IP 34.71.43.9 # 你的IP地址会有所不同 ~/project$ curl -i $PROXY_IP HTTP/1.1 404 Not Found Date:Tue, 18 May 2021 04:51:48 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Content-Length: 48 X-Kong-Response-Latency: 1 Server: kong/2.3.3 {"message": "no Route matched with those values"}.

很好。我们的Kong Kubernetes Ingress Controller已经部署完毕，并且可以通过PROXY_IP到达。它只需要被配置为正确的请求路由。

添加一个入口，将HTTP请求映射到Web服务器上

接下来，让我们配置Kong Kubernetes Ingress Controller来监听根/路径的HTTP请求，然后将这些请求映射到我们的K8s服务的80端口（它将该请求映射到NGINX服务器容器的80端口）。我们将创建一个名为http-ingress.yml的文件。

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app annotations: konghq.com/strip-path:"true" kubernetes.io/ingress.class: kong spec: rules: - http: paths: - path:/ pathType。前缀 backend: service: name: my-app port: number: 80

我们应用Ingress的配置。

~/project$ kubectl apply -f http-ingress.yml ingress.networking.k8s.io/my-app create

现在，当我们执行curl请求时。下面是结果。

~/project$ curl $PROXY_IP <! DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ... </html>

成功了!我们已经成功地配置了Kong Kubernetes Ingress Controller，以接收HTTP请求，并通过K8s服务将它们映射到NGINX容器。

如果我们想通过TCP连接而不是HTTP请求与容器和端口对话呢？为此，我们将使用Kong的自定义TCPIngress。

添加TCPIngress来映射连接请求

默认情况下，通过Kong Kubernetes Ingress Controller设置的Kong Proxy服务在80和443端口上进行监听。这就是为什么我们能够配置我们的Ingress来映射HTTP请求到我们的NGINX服务器，因为HTTP请求默认是去80端口。

对于我们的用例，我们需要Kong监听另外几个端口的TCP流量，我们将使用这些端口进行Postgres和Redis连接。早些时候，我们通过应用Kong提供的自定义配置（https://bit.ly/k4k8s），部署了Kong Kubernetes Ingress Controller。现在，我们要对该配置打两个补丁，以适应我们特定的TCP流需求。

首先，创建一个名为 patch-kong-deployment.yml 的文件，其中包含以下内容。

spec: template: spec: containers: - name: proxy env: - name: KONG_STREAM_LISTEN value:"0.0.0.0:1111, 0.0.0.0:22222" 端口： - containerPort: 11111 name: postgres-listen protocol:TCP - containerPort: 22222 name: redis-listen protocol:TCP

在这里，我们将Kong的TCP流配置为监听11111端口（我们将使用该端口进行postgres连接）和22222端口（我们将使用该端口进行Redis连接）。接下来，创建一个名为 patch-kong-service.yml 的文件，包含以下内容。

spec: ports: - name: postgres-listen port:11111 协议。TCP targetPort: 11111 - 名称: redis-listen port:22222协议。TCP targetPort: 22222

这个补丁修改了与Kong Kubernetes Ingress Controller相关的K8s服务，暴露了我们需要的端口。现在，我们应用这两个补丁。

~/project$ kubectl patch deploy -n kong ingress-kong \-patch-file=patch-kong-deployment.yml deployment.app/ingress-kong patched ~/project$ kubectl patch service -n kong kong-proxy \-patch-file=patch-kong-service.yml service/kong-proxy patched

现在我们已经给Kong打了补丁，让它在适当的端口上监听TCP连接，让我们来配置我们的TCPIngress资源。创建一个名为tcp-ingress.yml的文件。

apiVersion: configuration.konghq.com/v1beta1 kind:TCPIngress元数据： name: my-app annotations: kubernetes.io/ingress.class: kong spec: rules: - port:11111 后台： serviceName: my-app servicePort: 5432 - port:22222 后台: serviceName: my-app servicePort: 6379

这个配置在11111端口监听TCP流量。它将流量转发到5432端口的K8s服务。你可能记得，该服务将5432端口的流量映射到5432端口的postgres容器。同样，我们的TCPIngress将22222端口的流量转发到我们的服务的6379端口，随后到达6379端口的redis容器。

让我们来应用这个配置。

~/project$ kubectl apply -f tcp-ingress.yml tcpingress.conghq.com/my-app created

这应该就是一切了。现在，让我们测试一下。

~/project$ psql -h $PROXY_IP -p 11111 -U postgres 用户postgres的密码：postgrespassword psql (13.2 (Ubuntu 13.2-1.pgdg16.04+1)) 输入 "help" 获得帮助。 postgres=#

我们已经能够连接到postgres容器了!现在，让我们试试Redis。

~/project$ redis-cli -h $PROXY_IP -p 22222 -a redispassword 34.71.43.9:2222>

我们进去了!我们已经成功地配置了Kong Kubernetes Ingress Controller，将我们的HTTP请求映射到Web服务器，将我们的TCP连接映射到数据库和键值存储。在这一点上，你应该有一个很好的基础来定制Kong Kubernetes Ingress Controller来满足你自己的业务需求。

在我们结束演练之前，让我们通过将一些插件与我们的Ingress控制器集成来做一些实验。

第4步：将插件与Ingress控制器整合在一起

证书管理和HTTPS

我们将首先配置我们的Ingress控制器以使用cert-manager，它管理SSL证书的部署。这将使我们的NGINX网络服务器能够通过HTTPS访问。

在GKE集群中安装cert-manager

为了安装cert-manager，我们遵循Kubernetes文档页面上的步骤。文档中提到，如果你使用的是GKE，就需要创建一个ClusterRoleBinding来进行集群管理访问。然而，我们在前面的演练中已经做了这个。

接下来，我们用cert-manager将CustomResourceDefinition安装到我们的集群中，然后验证安装。

~/project$ kubectl apply -f \ https://github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml ~/project$ kubectl get pods --namespace cert-manager NAME READY STATUS RESTARTS AGE cert-manager-7c5c945df9-5rvj5 1/1 Running 0 1m cert-manager-ainjector-7c67689588-n7db6 1/1 Running 0 1m cert-manager-webhook-5759dc48f-cfwd6 1/1 Running 0 1m

设置域名，使其指向kong-proxy的IP

你会记得，我们把kong-proxy的IP地址存储为PROXY_IP。假设你对一个域名有控制权，添加一个DNS记录，将你的域名解析到PROXY_IP。在这个例子中，我给我的域名（codingplus.coffee）添加一个A记录，将子域名kong-k8s.codingplus.coffee解析到我的kong-proxy IP地址。

有了我们的子域名的正确解析，我们需要修改我们的http-ingress.yml文件，为HTTP请求指定一个主机，而不是仅仅使用一个IP地址。当然，你将使用你所配置的域名。

apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-app annotations: konghq.com/strip-path:"true" kubernetes.io/ingress.class: kong spec: rules: - http: paths: - path:/ 后台： serviceName: my-app servicePort: 80 host: kong-k8s.codingplus.coffee

让我们应用更新后的http-ingress.yml文件。

~/project$ kubectl apply -f http-ingress.yml ingress.networking.k8s.io/my-app configured

现在，我们的curl请求使用我们的域名到达NGINX服务器。

~/project$ curl http://kong-k8s.codingplus.coffee <! DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ... </html>

申请SSL证书

接下来，我们为我们的cert-manager创建一个ClusterIssuer资源。创建一个名为cluster-issuer.yml的文件，内容如下（用你自己的电子邮件地址代替）。

apiVersion: cert-manager.io/v1alpha2 kind:ClusterIssuer 元数据: name: letsencrypt-prod namespace: cert-manager spec: acme: email:[你的电子邮件地址] privateKeySecretRef: name: letsencrypt-prod server: https://acme-v02.api.letsencrypt.org/directory solvers: - http01: ingress: class: kong

创建这个资源。

~/project$ kubectl apply -f cluster-issuer.yml clusterissuer.cert-manager.io/letsencrypt-prod created

最后，我们要再次更新http-ingress.yml，以提供一个证书并使用它。

apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-app annotations: konghq.com/strip-path:"true" kubernetes.io/ingress.class: kong kubernetes.io/tls-acme:"true" cert-manager.io/cluster-issuer: letsencrypt-prod spec: rules: - http: paths: - path:/ 后台： serviceName: my-app servicePort: 80 host: kong-k8s.codingplus.coffee tls: - secretName: my-ssl-cert-secret hosts: - kong-k8s.codingplus.coffee

让我们应用更新后的http-ingress.yml清单。

~/project$ kubectl get certificates NAME READY SECRET AGE my-ssl-cert-secret True my-ssl-cert-secret 24s

我们的证书已经配置好了。现在，我们可以使用HTTPS发送请求。

~/project$ curl https://kong-k8s.codingplus.coffee <! DOCTYPE html> <html> <head> <title>Welcome to nginx! </title> ...

第5步：添加插件

集成Kong的HTTP日志插件

接下来，让我们配置我们的Ingress控制器来使用Kong插件。我们将使用HTTP Log插件，它将请求和响应记录到一个单独的HTTP服务器。

创建一个Mockbin来接收日志数据

我们将使用Mockbin，它给我们一个端点来告诉我们的插件发送它的数据。在Mockbin，通过简单的步骤来创建一个新的bin。你最终会得到一个独特的URL作为你的bin。

创建HTTP日志插件资源

创建一个名为http-log-plugin.yml的文件，内容如下。请确保使用你自己的Mockbin端点URL。

apiVersion: configuration.konghq.com/v1 kind:KongPlugin 元数据： 名称： http-log-plugin 插件： http-log 配置： http_endpoint: https://mockbin.org/bin/ENTER-YOUR-OWN-BIN-ID-HERE 方法。POST

使用该清单文件创建该插件。

~/project$ kubectl apply -f http-log-plugin.yml kongplugin.configuration.konghq.com/add-http-log-plugin created

更新Ingress清单

接下来，我们将再次更新http-ingress.yml，确保我们的Ingress控制器在处理对Nginx服务器的HTTP请求时知道要使用我们的新插件。

apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-app annotations: konghq.com/strip-path:"true" kubernetes.io/ingress.class: kong kubernetes.io/tls-acme:"true" cert-manager.io/cluster-issuer: letsencrypt-prod konghq.com/plugins:"http-log-plugin<strong>"</strong> ...

应用更新的文件。

~/project$ kubectl apply -f http-ingress.yml ingress.networking.k8s.io/my-app configured

发送请求，检查Mockbin

现在我们添加了我们的插件，我们可以向我们的网络服务器发送另一个请求。

~/project$ curl https://kong-k8s.codingplus.coffee

我们可以在Mockbin检查我们的bin的请求历史。我们看到我们最近的请求被发布到了Mockbin，以及Mockbin请求体中关于我们请求的数据。

看起来我们的HTTP日志插件已经启动并运行了!

apiVersion: configuration.konghq.com/v1 kind:KongPlugin元数据: name: correlation-id-plugin plugin: correlation-id config: header_name: my-unique-id generator: uuid echo_downstream: false

集成Kong的相关ID插件

最后，我们再整合一个Kong插件。Correlation ID。这个插件会在每个请求的头文件中附加一个唯一的值（通常是UUID）。首先，我们创建Correlation ID Plugin资源。创建一个名为correlation-id-plugin.yml的文件。

在我们的插件配置中，我们要在所有的请求中添加一个名为my-unique-id的头。它将包含一个UUID。安装该插件。

~/project$ kubectl apply -f correlation-id-plugin.yml kongplugin.configuration.konghq.com/add-correlation-id-plugin configured

接下来，我们把这个插件和我们的HTTP日志插件一起添加到http-ingress.yml清单中。

apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-app annotations: konghq.com/strip-path:"true" kubernetes.io/ingress.class: kong kubernetes.io/tls-acme:"true" cert-manager.io/cluster-issuer: letsencrypt-prod konghq.com/plugins:"http-log-plugin,correlation-id-plugin" ...

将这些变化应用到Ingress控制器。

~/project$ kubectl apply -f http-ingress.yml ingress.networking.k8s.io/my-app configured

配置好我们的插件后，我们再发送一个curl请求。

~/project$ curl https://kong-k8s.codingplus.coffee

再一次，我们检查Mockbin的历史，查看最新的请求。这一次，当我们仔细查看头信息时，我们看到了my-unique-id，它来自我们的Correlation ID插件。

Screenshot of Mockbin history showing "my-unique-id"

成功了!我们的Correlation ID插件正在工作!

总结

在这个演练中，我们已经涵盖了很多内容。我们从一个由三个Docker容器组成的简单应用开始。我们一步一步地用Kubernetes部署我们的容器，并部署了开源的Kong Kubernetes Ingress Controller来管理外部对我们集群容器的访问。最后，我们通过整合支持HTTPS的cert-manager和一些Kong插件来进一步定制我们的Ingress控制器。

有了这些，你现在有了一个全面的基础，可以在Kong的Kubernetes Ingress Controller的帮助下将你的Docker化应用程序部署到Kubernetes。你可以根据自己的业务应用需求来定制你的部署了。👍

如果你有任何其他问题，请在Kong Nation上发表。要保持联系，请加入Kong社区。

你可能会发现这些其他的Kubernetes教程有帮助。

CSDN-Ada助手

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【翻译】用Kubernetes Ingress Controller管理Docker应用程序

作者：Alvin Lee2021年9月17日原文为Alvin Lee在Kong的博客上发表的客座文章回想一下，当你的开发团队转换到Docker化容器时。曾经需要在虚拟机上提供多种服务的应用程序过渡到由多个整齐的Docker容器组成的应用程序。虽然结果是一个精简的系统，但这个过渡可能是令人生畏的。现在，是时候进行另一次转型飞跃了：从单一的容器集转移到使用Kubernetes的复制集的高...
复制链接

扫一扫