From 3b87db4c5ef239abf1575103960cb44d8b273189 Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Thu, 2 Apr 2020 13:04:09 +0800 Subject: [PATCH] TSL --- ...recting Kubernetes traffic with Traefik.md | 394 ------------------ ...recting Kubernetes traffic with Traefik.md | 381 +++++++++++++++++ 2 files changed, 381 insertions(+), 394 deletions(-) delete mode 100644 sources/tech/20200311 Directing Kubernetes traffic with Traefik.md create mode 100644 translated/tech/20200311 Directing Kubernetes traffic with Traefik.md diff --git a/sources/tech/20200311 Directing Kubernetes traffic with Traefik.md b/sources/tech/20200311 Directing Kubernetes traffic with Traefik.md deleted file mode 100644 index a76138274b..0000000000 --- a/sources/tech/20200311 Directing Kubernetes traffic with Traefik.md +++ /dev/null @@ -1,394 +0,0 @@ -[#]: collector: (lujun9972) -[#]: translator: (wxy) -[#]: reviewer: ( ) -[#]: publisher: ( ) -[#]: url: ( ) -[#]: subject: (Directing Kubernetes traffic with Traefik) -[#]: via: (https://opensource.com/article/20/3/kubernetes-traefik) -[#]: author: (Lee Carpenter https://opensource.com/users/carpie) - -Directing Kubernetes traffic with Traefik -====== -A step-by-step walkthrough on ingressing traffic into a -Kubernetes-Raspberry Pi cluster. -![Digital creative of a browser on the internet][1] - -In this article, we will deploy a couple of simple websites and learn how to ingress traffic from the outside world into our cluster using Traefik. After that, we will learn how to remove Kubernetes resources as well. Let’s get started! - -### Materials needed - -To follow along with the article, you only need [the k3s Raspberry Pi cluster][2] we built in a previous article. Since your cluster will be pulling images from the web, the cluster will need to be able to access the internet. - -Some configuration files and sample HTML files will be shown in this article for explanation purposes. All sample files can be downloaded [here][3]. - -### Deploying a simple website - -Previously, we did a direct deploy with **kubectl**. This is not the typical way to deploy things, however. Generally, YAML configuration files are used, and that is what we will use in this article. We will start at the top and create our configuration files in a top-down approach. - -### Deployment configuration - -First up is the deployment configuration. The configuration is shown below, and the explanation follows. I typically use the samples from the [Kubernetes documentation][4] as a starting point and then modify them to suit my needs. For example, the configuration below was modified after copying the sample from the [deployment docs][5]. - -Create a file, **mysite.yaml**, with the following contents: - - -``` -apiVersion: apps/v1 -kind: Deployment -metadata: -  name: mysite-nginx -  labels: -    app: mysite-nginx -spec: -  replicas: 1 -  selector: -    matchLabels: -      app: mysite-nginx -  template: -    metadata: -      labels: -        app: mysite-nginx -    spec: -      containers: -      - name: nginx -        image: nginx -        ports: -        - containerPort: 80 -``` - -Most of this is boilerplate. The important parts, we have named our deployment **mysite-nginx** with an **app** label of **mysite-nginx **as well. We have specified that we want one **replica** which means there will only be one pod created. We also specified **one container**, which we named **nginx**. We specified the **image** to be **nginx**. This means, on deployment, k3s will download the **nginx** image from DockerHub and create a pod from it. Finally, we specified a **containerPort** of **80**, which just means that inside the container the pod will listen on port **80**. - -I emphasized "inside the container" above because it is an important distinction. As we have the container configured, it is only accessible inside the container, and it is further restricted to an internal network. This is necessary to allow multiple containers to listen on the same container ports. In other words, with this configuration, some other pod could listen on its container port 80 as well and not conflict with this one. To provide formal access to this pod, we need a **service** configuration. - -### Service configuration - -In Kubernetes, a **service** is an abstraction. It provides a means to access a pod or set of pods. One connects to the service and the service routes to a single pod or load balances to multiple pods if multiple pod replicas are defined. - -The service can be specified in the same configuration file, and that is what we will do here. Separate configuration areas with **`---`**. Add the following to **mysite.yaml**: - - -``` -\--- -apiVersion: v1 -kind: Service -metadata: -  name: mysite-nginx-service -spec: -  selector: -    app: mysite-nginx -  ports: -    - protocol: TCP -      port: 80 -``` - -In this configuration, we have named our service **mysite-nginx-service**. We provided a `selector` of **app: mysite-nginx**. This is how the service chooses the application containers it routes to. Remember, we provided an **app** label for our container as **mysite-nginx**. This is what the service will use to find our container. Finally, we specified that the service protocol is **TCP** and the service listens on port **80**. - -### Ingress configuration - -The ingress configuration specifies how to get traffic from outside our cluster to services inside our cluster. Remember, k3s comes pre-configured with Traefik as an ingress controller. Therefore, we will write our ingress configuration specific to Traefik. Add the following to **mysite.yaml **( and don’t forget to separate with **`---`**): - - -``` -\--- -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: -  name: mysite-nginx-ingress -  annotations: -    kubernetes.io/ingress.class: "traefik" -spec: -  rules: -  - http: -      paths: -      - path: / -        backend: -          serviceName: mysite-nginx-service -          servicePort: 80 -``` - -In this configuration, we have named the ingress record **mysite-nginx-ingress**. And we told Kubernetes that we expect **traefik** to be our ingress controller with the **kubernetes.io/ingress.class** annotation. - -In the **rules** section, we are basically saying, when **http** traffic comes in, and the **path** matches **`/`** (or anything below that), route it to the **backend** service specified by the **serviceName mysite-nginx-service**, and route it to **servicePort 80**. This connects incoming HTTP traffic to the service we defined earlier. - -### Something to deploy - -That is really it as far as configuration goes. If we deployed now, we would get the default **nginx** page, but that is not what we want. Let’s create something simple but custom to deploy. Create the file **index.html** with the following contents: - - -``` -<html> -<head><title>K3S!</title> -  <style> -    html { -      font-size: 62.5%; -    } -    body { -      font-family: sans-serif; -      background-color: midnightblue; -      color: white; -      display: flex; -      flex-direction: column; -      justify-content: center; -      height: 100vh; -    } -    div { -      text-align: center; -      font-size: 8rem; -      text-shadow: 3px 3px 4px dimgrey; -    } -  </style> -</head> -<body> -  <div>Hello from K3S!</div> -</body> -</html> -``` - -We have not yet covered storage mechanisms in Kubernetes, so we are going to cheat a bit and just store this file in a Kubernetes config map. This is not the recommended way to deploy a website, but it will work for our purposes. Run the following: - - -``` -`kubectl create configmap mysite-html --from-file index.html` -``` - -This command creates a `configmap` resource named **mysite-html** from the local file **index.html**. This essentially stores a file (or set of files) inside a Kubernetes resource that we can call out in configuration. It is typically used to store configuration files (hence the name), so we are abusing it a bit here. In a later article, we will discuss proper storage solutions in Kubernetes. - -With the config map created, let’s mount it inside our **nginx** container. We do this in two steps. First, we need to specify a **volume**, calling out the config map. Then we need to mount the volume into the **nginx** container. Complete the first step by adding the following under the **spec** label, just after **containers** in **mysite.yaml**: - - -``` -      volumes: -      - name: html-volume -        configMap: -          name: mysite-html -``` - -This tells Kubernetes that we want to define a **volume**, with the name **html-volume** and that volume should contain the contents of the **configMap** named **html-volume** (which we created in the previous step). - -Next, in the **nginx** container specification, just under **ports**, add the following: - - -``` -        volumeMounts: -        - name: html-volume -          mountPath: /usr/share/nginx/html -``` - -This tells Kubernetes, for the **nginx** container, we want to mount a **volume** named **html-volume** at the path (in the container) **/usr/share/nginx/html**. Why **/usr/share/nginx/html**? That is where the **nginx** image serves HTML from. By mounting our volume at that path, we have replaced the default contents with our volume contents. - -For reference, the **deployment** section of the configuration file should now look like this: - - -``` -apiVersion: apps/v1 -kind: Deployment -metadata: -  name: mysite-nginx -  labels: -    app: mysite-nginx -spec: -  replicas: 1 -  selector: -    matchLabels: -      app: mysite-nginx -  template: -    metadata: -      labels: -        app: mysite-nginx -    spec: -      containers: -      - name: nginx -        image: nginx -        ports: -        - containerPort: 80 -        volumeMounts: -        - name: html-volume -          mountPath: /usr/share/nginx/html -      volumes: -      - name: html-volume -        configMap: -          name: mysite-html -``` - -### Deploy it! - -Now we are ready to deploy! We can do that with: - - -``` -`kubectl apply -f mysite.yaml` -``` - -You should see something similar to the following: - - -``` -deployment.apps/mysite-nginx created -service/mysite-nginx-service created -ingress.networking.k8s.io/mysite-nginx-ingress created -``` - -This means that Kubernetes created resources for each of the three configurations we specified. Check on the status of the pods with: - - -``` -`kubectl get pods` -``` - -If you see a status of **ContainerCreating**, give it some time and run **kubectl get pods** again. Typically, the first time, it will take a while because k3s has to download the **nginx** image to create the pod. After a while, you should get a status of **Running**. - -### Try it! - -Once the pod is running, it is time to try it. Open up a browser and type **kmaster** into the address bar. - -![][6] - -Congratulations! You’ve deployed a website on your k3s cluster! - -### Another one - -So now we have a whole k3s cluster running a single website. But we can do more! What if we have another website we want to serve on the same cluster? Let’s see how to do that. - -Again, we need something to deploy. It just so happens that my dog has a message she has wanted the world to know for some time. So, I crafted some HTML just for her (available from the samples zip file). Again, we will use the config map trick to host our HTML. This time we are going to poke a whole directory (the **html** directory) into a config map, but the invocation is the same. - - -``` -`kubectl create configmap mydog-html --from-file html` -``` - -Now we need to create a configuration file for this site. It is almost exactly the same as the one for **mysite.yaml**, so start by copying **mysite.yaml** to **mydog.yaml**. Now edit **mydog.yaml** to be: - - -``` -apiVersion: apps/v1 -kind: Deployment -metadata: -  name: mydog-nginx -  labels: -    app: mydog-nginx -spec: -  replicas: 1 -  selector: -    matchLabels: -      app: mydog-nginx -  template: -    metadata: -      labels: -        app: mydog-nginx -    spec: -      containers: -      - name: nginx -        image: nginx -        ports: -        - containerPort: 80 -        volumeMounts: -        - name: html-volume -          mountPath: /usr/share/nginx/html -      volumes: -      - name: html-volume -        configMap: -          name: mydog-html -\--- -apiVersion: v1 -kind: Service -metadata: -  name: mydog-nginx-service -spec: -  selector: -    app: mydog-nginx -  ports: -    - protocol: TCP -      port: 80 -\--- -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: -  name: mydog-nginx-ingress -  annotations: -    kubernetes.io/ingress.class: "traefik" -    traefik.frontend.rule.type: PathPrefixStrip -spec: -  rules: -  - http: -      paths: -      - path: /mydog -        backend: -          serviceName: mydog-nginx-service -          servicePort: 80 -``` - -We can do most of the edits by simply doing a search and replace of **mysite** to **mydog**. The two other edits are in the ingress section. We changed **path** to **/mydog **and we added an annotation, **traefik.frontend.rule.type: PathPrefixStrip**. - -The specification of the path **/mydog** instructs Traefik to route any incoming request that requests a path starting with **/mydog** to the **mydog-nginx-service**. Any other path will continue to be routed to **mysite-nginx-service.** - -The new annotation, **PathPrefixStrip**, tells Traefik to strip off the prefix **/mydog** before sending the request to **mydog-nginx-service**. We did this because the **mydog-nginx** application doesn’t expect a prefix. This means we could change where the service was mounted simply by changing the prefix in the ingress record. - -Now we can deploy like we did before: - - -``` -`kubectl apply -f mydog.yaml` -``` - -And now, my dog’s message should be available at . - -![][7] - -Phew! The message is out! Maybe we can all get some sleep tonight. - -So now, we have a k3s cluster hosting two websites with Traefik making decisions, based on path names, as to which service to pass the request to! We are not limited to path-based routing, however. We could use hostname based routing as well, which we will explore in a future article. - -Also, the websites we just hosted are standard unencrypted HTML sites. Everything these days is encrypted with SSL/TLS. In our next article, we will add support to our k3s cluster to host SSL/TLS HTTPS sites as well! - -### Cleaning up - -Before you go, since this article mostly dealt with sample sites, I would like to show you how to delete things in case you don’t want the samples hanging around on your cluster. - -For most configurations, you can undo the configuration simply by running the **delete** command with the same configuration file you deployed with. So let’s clean up both **mysite** and **mydog**. - - -``` -kubectl delete -f mysite.yaml -kubectl delete -f mydog.yaml -``` - -Since we manually created the config maps, we’ll need to delete those manually as well. - - -``` -kubectl delete configmap mysite-html -kubectl delete configmap mydog-html -``` - -Now if we do a **kubectl get pods**, we should see that our nginx pods are no longer around. - - -``` -$ kubectl get pods -No resources found in default namespace. -``` - -Everything is cleaned up. - -Tell me what thoughts you have on this project in the comments below. - --------------------------------------------------------------------------------- - -via: https://opensource.com/article/20/3/kubernetes-traefik - -作者：[Lee Carpenter][a] -选题：[lujun9972][b] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]: https://opensource.com/users/carpie -[b]: https://github.com/lujun9972 -[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/browser_web_internet_website.png?itok=g5B_Bw62 (Digital creative of a browser on the internet) -[2]: https://opensource.com/article/20/3/kubernetes-raspberry-pi -[3]: https://gitlab.com/carpie/ingressing_with_k3s/-/archive/master/ingressing_with_k3s-master.zip -[4]: https://kubernetes.io/docs/ -[5]: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment -[6]: https://opensource.com/sites/default/files/uploads/mysite.jpg -[7]: https://opensource.com/sites/default/files/uploads/mydog.jpg diff --git a/translated/tech/20200311 Directing Kubernetes traffic with Traefik.md b/translated/tech/20200311 Directing Kubernetes traffic with Traefik.md new file mode 100644 index 0000000000..bb35205ad2 --- /dev/null +++ b/translated/tech/20200311 Directing Kubernetes traffic with Traefik.md @@ -0,0 +1,381 @@ +[#]: collector: (lujun9972) +[#]: translator: (wxy) +[#]: reviewer: ( ) +[#]: publisher: ( ) +[#]: url: ( ) +[#]: subject: (Directing Kubernetes traffic with Traefik) +[#]: via: (https://opensource.com/article/20/3/kubernetes-traefik) +[#]: author: (Lee Carpenter https://opensource.com/users/carpie) + +使用 Traefik 引导 Kubernetes 流量 +====== + +> 将流量引入 Kubernetes 树莓派集群的分步指南。 + +![Digital creative of a browser on the internet][1] + +在本文中，我们将部署几个简单的网站，并学习如何使用 Traefik 将来自外部世界的流量引入到我们的集群中。之后，我们还将学习如何删除 Kubernetes 资源。让我们开始吧！ + +- [video](https://youtu.be/QcC-5fRhsM8) + +### 准备 + +要继续阅读本文，你只需要我们在上一篇文章中构建的 [k3s 树莓派集群][2]。由于你的集群将从网络上拉取图像，因此该集群需要能够访问互联网。 + +出于解释目的，本文将显示一些配置文件和示例 HTML 文件。所有示例文件都可以在[此处][3]下载。 + +### 部署一个简单的网站 + +之前，我们使用 `kubectl` 进行了直接部署。但是，这不是部署事物的典型方法。通常，会使用 YAML 配置文件，这就是我们将在本文中使用的配置文件。我们将从顶部开始，并以自顶向下的方式创建该配置文件。 + +### 部署配置 + +首先是部署配置。配置如下所示，并在下面进行说明。我通常以 [Kubernetes 文档][4]中的示例为起点，然后对其进行修改以适合我的需求。例如，从[部署文档][5]复制示例后，修改下面的配置。 + +创建一个文件 `mysite.yaml`，其内容如下： + +``` +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mysite-nginx + labels: + app: mysite-nginx +spec: + replicas: 1 + selector: + matchLabels: + app: mysite-nginx + template: + metadata: + labels: + app: mysite-nginx + spec: + containers: + - name: nginx + image: nginx + ports: + - containerPort: 80 +``` + +其中大部分是样板。重要的部分，我们会将该部署命名为 `mysite-nginx`，并加上 `mysite-nginx` 的 `app` 标签。我们已指定要一个副本replica，这意味着将只创建一个 Pod。我们还指定了一个容器，我们将其命名为 `nginx`。我们将镜像image指定为 `nginx`。这意味着在部署时，k3s 将从 DockerHub 下载 `nginx` 镜像并从中创建一个 Pod。最后，我们指定了容器端口containerPort为 `80`，这只意味着在容器内部 Pod 会监听 `80` 端口。 + +我在上面强调了“在容器内部”，因为这是一个重要的区别。由于我们是按容器配置的，因此只能在容器内部访问它，并且进一步将其限制为内部网络。这是允许多个容器在同一容器端口上监听所必需的。换句话说，通过这种配置，其他某些 Pod 也可以在其容器端口 80 上侦听，并且不会与此容器冲突。为了提供对该 Pod 的正式访问权限，我们需要一个服务service配置。 + +### 服务配置 + +在 Kubernetes 中，服务service是一种抽象。它提供了一种访问一个或一组 Pod 的方法。如果定义了多个 Pod 副本，则一个连接到服务，并且由服务路由到单个 Pod，或通过负载均衡路由到多个 Pod。 + +可以在同一配置文件中指定该服务，这就是我们将在此处执行的操作。用 `---` 分隔配置区域。将以下内容添加到 `mysite.yaml` 中： + +``` +--- +apiVersion: v1 +kind: Service +metadata: + name: mysite-nginx-service +spec: + selector: + app: mysite-nginx + ports: + - protocol: TCP + port: 80 +``` + +在此配置中，我们将服务命名为 `mysite-nginx-service`。我们提供了 `app: mysite-nginx` 的选择器selector。这是服务选择其路由到的应用程序容器的方式。请记住，我们为容器提供了一个内容为 `mysite-nginx` 的 `app` 标签。这就是服务用来查找我们的容器的方式。最后，我们指定服务协议为 `TCP`，在端口 `80` 上侦听。 + +### 入口配置 + +入口Ingress配置指定如何将流量从集群外部传递到集群内部的服务。请记住，k3s 预先配置了 Traefik 作为入口控制器。因此，我们将编写特定于 Traefik 的入口配置。将以下内容添加到 `mysite.yaml` 中（不要忘了用 `---` 分隔）： + +``` +--- +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: mysite-nginx-ingress + annotations: + kubernetes.io/ingress.class: "traefik" +spec: + rules: + - http: + paths: + - path: / + backend: + serviceName: mysite-nginx-service + servicePort: 80 +``` + +在此配置中，我们将入口记录命名为 `mysite-nginx-ingress`。我们告诉 Kubernetes，我们希望 `traefik` 成为我们的入口控制器，带有 `kubernetes.io/ingress.class` 的注解。 + +在规则rules部分中，我们基本上是说，当 `http` 流量进入时，并且 `path` 匹配 `/`（或其下的任何内容），将其路由到由 `serviceName mysite-nginx-service` 指定的后端backend服务中，并将其路由到 `servicePort 80`。这会将传入的 HTTP 流量连接到我们之前定义的服务。 + +### 部署的东西 + +就配置而言，确实如此。如果现在部署，我们将获得默认的 nginx 页面，但这不是我们想要的。让我们创建一些简单但可自定义的部署方式。创建具有以下内容的文件 `index.html`： + +``` + +K3S! + + + +
Hello from K3S!
+ + +``` + +我们尚未介绍 Kubernetes 中的存储机制，因此在这里我们偷懒一下，仅将该文件存储在 Kubernetes 配置映射中。这不是建议的网站部署方式，但可以满足我们的目的。运行以下命令： + +``` +kubectl create configmap mysite-html --from-file index.html +``` + +该命令从本地文件 `index.html` 创建名为 `mysite-html` 的配置映射configmap资源。这实际上是在 Kubernetes 资源中存储一个文件（或一组文件），我们可以在配置中调出该文件。它通常用于存储配置文件（因此而得名），因此我们在这里稍加滥用。在以后的文章中，我们将讨论 Kubernetes 中适当的存储解决方案。 + +创建配置映射后，让我们将其挂载在我们的 `nginx` 容器中。我们分两个步骤进行。首先，我们需要指定一个卷volume来调出配置映射。然后我们需要将该卷挂载到 `nginx` 容器中。通过在 `mysite.yaml` 中的 `container` 后面的 `spec` 标签下添加以下内容来完成第一步： + +``` +      volumes: +      - name: html-volume +        configMap: +          name: mysite-html +``` + +这告诉 Kubernetes 我们要定义一个名为 `html-volume` 的卷，并且该卷应包含名为 `html-volume`（我们在上一步中创建的）的配置映射的内容。 + +接下来，在 `nginx` 容器规范中的端口port下方，添加以下内容： + +``` +        volumeMounts: +        - name: html-volume +          mountPath: /usr/share/nginx/html +``` + +这告诉 Kubernetes，对于 `nginx` 容器，我们想在容器中的 `/usr/share/nginx/html` 路径中挂载名为 `html-volume` 的卷。 为什么要使用 `/usr/share/nginx/html`？那个位置就是 `nginx` 镜像提供 HTML 服务的地方。通过在该路径上挂载卷，我们用该卷内容替换了默认内容。 + +作为参考，配置文件的 `deployment` 部分现在应如下所示： + +``` +apiVersion: apps/v1 +kind: Deployment +metadata: +  name: mysite-nginx +  labels: +    app: mysite-nginx +spec: +  replicas: 1 +  selector: +    matchLabels: +      app: mysite-nginx +  template: +    metadata: +      labels: +        app: mysite-nginx +    spec: +      containers: +      - name: nginx +        image: nginx +        ports: +        - containerPort: 80 +        volumeMounts: +        - name: html-volume +          mountPath: /usr/share/nginx/html +      volumes: +      - name: html-volume +        configMap: +          name: mysite-html +``` + +### 部署它！ + +现在我们准备部署！ 我们可以这样做： + +``` +kubectl apply -f mysite.yaml +``` + +你应该看到类似于以下内容： + +``` +deployment.apps/mysite-nginx created +service/mysite-nginx-service created +ingress.networking.k8s.io/mysite-nginx-ingress created +``` + +这意味着 Kubernetes 为我们指定的三个配置分别创建了资源。使用以下方法检查 Pod 的状态： + +``` +kubectl get pods +``` + +如果看到状态为 `ContainerCreating`，请给它一些时间并再次运行 `kubectl get pods`。通常，第一次会花一些时间，因为 k3s 必须下载 `nginx` 镜像来创建 Pod。一段时间后，你应该看到 `Running` 的状态。 + +### 尝试一下！ + +Pod 运行之后，就该尝试了。 开浏览器，然后在地址栏中输入 `kmaster`。 + +![][6] + +恭喜你！你已经在 k3s 集群上部署了一个网站！ + +### 另一个 + +因此，现在我们有了一个运行单个网站的整个 k3s 集群。但是我们可以做更多！如果我们要在同一集群中提供另一个网站怎么办？让我们看看如何做到这一点。 + +同样，我们需要部署一些东西。碰巧我的狗有一条信息，她想让世界知道一段时间。因此，我专门为她制作了一些 HTML（可从示例 zip 文件中获得）。同样，我们将使用配置映射的技巧来托管这些 HTML。这次我们将把整个目录（`html` 目录）放到配置映射中，但是调用是相同的。 + +``` +kubectl create configmap mydog-html --from-file html +``` + +现在，我们需要为此站点创建一个配置文件。它几乎与用于 `mysite.yaml` 的完全相同，因此首先将 `mysite.yaml` 复制为 `mydog.yaml`。现在将 `mydog.yaml` 修改为： + +``` +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mydog-nginx + labels: + app: mydog-nginx +spec: + replicas: 1 + selector: + matchLabels: + app: mydog-nginx + template: + metadata: + labels: + app: mydog-nginx + spec: + containers: + - name: nginx + image: nginx + ports: + - containerPort: 80 + volumeMounts: + - name: html-volume + mountPath: /usr/share/nginx/html + volumes: + - name: html-volume + configMap: + name: mydog-html +--- +apiVersion: v1 +kind: Service +metadata: + name: mydog-nginx-service +spec: + selector: + app: mydog-nginx + ports: + - protocol: TCP + port: 80 +--- +apiVersion: networking.k8s.io/v1beta1 +kind: Ingress +metadata: + name: mydog-nginx-ingress + annotations: + kubernetes.io/ingress.class: "traefik" + traefik.frontend.rule.type: PathPrefixStrip +spec: + rules: + - http: + paths: + - path: /mydog + backend: + serviceName: mydog-nginx-service + servicePort: 80 +``` + +我们只需进行搜索并将 `mysite` 替换为 `mydog`即可完成大多数修改。其他两个修改在入口部分中。我们将 `path` 更改为 `/mydog`，并添加了一个注解 `traefik.frontend.rule.type: PathPrefixStrip`。 + +`/mydog` 路径的规范指示 Traefik 将以 `/mydog` 路径开头的所有传入请求路由到 `mydog-nginx-service`。任何其他路径将继续路由到 `mysite-nginx-service`。 + +新的注解 `PathPrefixStrip` 告诉 Traefik 在将请求发送到 `mydog-nginx-service` 之前先去除前缀 `/mydog`。我们这样做是因为 `mydog-nginx` 应用程序不需要前缀。这意味着我们可以简单地通过更改入口记录中的前缀来更改挂载的服务的位置。 + +现在我们可以像以前一样进行部署： + +``` +kubectl apply -f mydog.yaml +``` + +现在，我的狗的消息应该可以在 上找到。 + +![][7] + + +呼！消息出来了！也许今晚我们都可以睡一觉。 + +因此，现在，我们有了一个 k3s 集群，该集群托管了两个网站，Traefik 根据路径名决定将请求传递给哪个服务！但是，我们不仅限于基于路径的路由。我们也可以使用基于主机名的路由，我们将在以后的文章中进行探讨。 + +另外，我们刚刚托管的网站是标准的未加密 HTML 网站，如今的所有内容都使用 SSL/TLS 加密。在我们的下一篇文章中，我们将为 k3s 集群添加支持以托管 SSL/TLS HTTPS 站点！ + +### 清理 + +在开始之前，由于本文主要涉及的是示例站点，因此我想向你展示如何删除内容，以防万一你不希望将这些示例丢在集群中。 + +对于大多数配置，只需使用与部署时使用的相同配置文件运行 `delete` 命令即可撤消配置。因此，让我们同时清理 `mysite` 和 `mydog`。 + +``` +kubectl delete -f mysite.yaml +kubectl delete -f mydog.yaml +``` + +由于我们是手动创建配置映射的，因此我们也需要手动删除它们。 + +``` +kubectl delete configmap mysite-html +kubectl delete configmap mydog-html +``` + +现在，如果我们执行 `kubectl get pods`，我们应该看到我们的 nginx Pod 不存在了。 + +``` +$ kubectl get pods +No resources found in default namespace. +``` + +一切都清理了。 + +请在下面的评论中告诉我你对这个项目有什么想法。 + +-------------------------------------------------------------------------------- + +via: https://opensource.com/article/20/3/kubernetes-traefik + +作者：[Lee Carpenter][a] +选题：[lujun9972][b] +译者：[wxy](https://github.com/wxy) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]: https://opensource.com/users/carpie +[b]: https://github.com/lujun9972 +[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/browser_web_internet_website.png?itok=g5B_Bw62 (Digital creative of a browser on the internet) +[2]: https://opensource.com/article/20/3/kubernetes-raspberry-pi +[3]: https://gitlab.com/carpie/ingressing_with_k3s/-/archive/master/ingressing_with_k3s-master.zip +[4]: https://kubernetes.io/docs/ +[5]: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment +[6]: https://opensource.com/sites/default/files/uploads/mysite.jpg +[7]: https://opensource.com/sites/default/files/uploads/mydog.jpg