这篇文章主要为大家展示了“怎么使用Traefik引导Kubernetes流量”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“怎么使用Traefik引导Kubernetes流量”这篇文章吧。
成都创新互联从2013年创立，是专业互联网技术服务公司，拥有项目网站设计制作、做网站网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元满城做网站,已为上家服务,为满城各地企业和个人服务,联系电话:18980820575
之前，我们使用 kubectl 进行了直接部署。但是，这不是典型的部署方法。一般情况都会使用 YAML 配置文件，这也是我们要在本文中使用的配置文件。我们将从顶部开始，并以自顶向下的方式创建该配置文件。
首先是部署配置。配置如下所示，并在下面进行说明。我通常以 Kubernetes 文档中的示例为起点，然后根据需要对其进行修改。例如，下面的配置是复制了部署文档中的示例后修改的。
创建一个文件 mysite.yaml，其内容如下：
apiVersion: apps/v1kind: Deploymentmetadata: name: mysite-nginx labels: app: mysite-nginxspec: replicas: 1 selector: matchLabels: app: mysite-nginx template: metadata: labels: app: mysite-nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80
其中大部分是样板。重要的部分，我们会将该部署命名为 mysite-nginx，并为其加上同名的 app 标签。我们指定了一个副本，这意味着将只创建一个 Pod。我们还指定了一个容器，我们将其命名为 nginx。我们将镜像指定为 nginx。这意味着在部署时，k3s 将从 DockerHub 下载 nginx 镜像并从中创建一个 Pod。最后，我们指定了容器端口为 80，这只意味着在容器内部 Pod 会监听 80 端口。
我在上面强调了“在容器内部”，因为这是一个重要的区别。由于我们是按容器配置的，因此只能在容器内部访问它，并且进一步将其限制为内部网络。这对于允许多个容器在同一容器端口上监听所是必要的。换句话说，通过这种配置，其他一些 Pod 也可以在其容器端口 80 上侦听，并且不会与此容器冲突。为了提供对该 Pod 的正式访问权限，我们需要一个服务配置。
在 Kubernetes 中，服务是一种抽象。它提供了一种访问 Pod 或 Pod 集合的方法。当连接到服务时，服务会路由到单个 Pod，或者如果定义了多个 Pod 副本，会通过负载均衡路由到多个 Pod。
可以在同一配置文件中指定该服务，这就是我们将在此处要做的。用 --- 分隔配置区域，将以下内容添加到 mysite.yaml 中：
---apiVersion: v1kind: Servicemetadata: name: mysite-nginx-servicespec: selector: app: mysite-nginx ports: - protocol: TCP port: 80
在此配置中，我们将服务命名为 mysite-nginx-service。我们提供了一个选择器：app: mysite-nginx。这是服务选择其路由到的应用程序容器的方式。请记住，我们为容器提供了 app 标签：mysite-nginx 。这就是服务用来查找我们的容器的方式。最后，我们指定服务协议为 TCP，在端口 80 上监听。
入口配置指定了如何将流量从集群外部传递到集群内部的服务。请记住，k3s 预先配置了 Traefik 作为入口控制器。因此，我们将编写特定于 Traefik 的入口配置。将以下内容添加到 mysite.yaml 中（不要忘了用 --- 分隔）：
---apiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata: 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 的注解。
在规则部分中，我们基本上是说，当 http 流量进入时，并且 path 匹配 /（或其下的任何内容），将其路由到由 serviceName mysite-nginx-service 指定的后端服务中，并将其路由到 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 的配置映射资源。这实际上是在 Kubernetes 资源中存储一个文件（或一组文件），我们可以在配置中调出该文件。它通常用于存储配置文件（因此而得名），我们在这里稍加滥用。在以后的文章中，我们将讨论 Kubernetes 中适当的存储解决方案。
创建配置映射后，让我们将其挂载在我们的 nginx 容器中。我们分两个步骤进行。首先，我们需要指定一个卷来调出配置映射。然后我们需要将该卷挂载到 nginx 容器中。通过在 mysite.yaml 中的 container 后面的 spec 标签下添加以下内容来完成第一步：
volumes: - name: html-volume configMap: name: mysite-html
这告诉 Kubernetes 我们要定义一个名为 html-volume 的卷，并且该卷应包含名为 html-volume（我们在上一步中创建的）的配置映射的内容。
接下来，在 nginx 容器规范中的端口下方，添加以下内容：
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/v1kind: Deploymentmetadata: name: mysite-nginx labels: app: mysite-nginxspec: 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 createdservice/mysite-nginx-service createdingress.networking.k8s.io/mysite-nginx-ingress created
这意味着 Kubernetes 为我们指定的三个配置分别创建了资源。使用以下方法检查 Pod 的状态：
kubectl get pods
如果看到状态为 ContainerCreating，请给它一些时间并再次运行 kubectl get pods。通常，第一次会花一些时间，因为 k3s 必须下载 nginx 镜像来创建 Pod。一段时间后，你应该看到 Running 的状态。
Pod 运行之后，就该尝试了。打开浏览器，然后在地址栏中输入 kmaster。
恭喜你！你已经在 k3s 集群上部署了一个网站！
因此，现在我们有了一个运行单个网站的整个 k3s 集群。但是我们可以有更多的网站！如果我们要在同一集群中提供另一个网站怎么办？让我们看看如何做到这一点。
同样，我们需要部署一些东西。碰巧我的狗有一条她想让全世界都知道的信息，她想了好久了。因此，我专门为她制作了一些 HTML（可从示例 zip 文件中获得）。同样，我们将使用配置映射的技巧来托管这些 HTML。这次我们将把整个目录（html 目录）放到配置映射中，但是调用是相同的。
kubectl create configmap mydog-html --from-file html
现在，我们需要为此站点创建一个配置文件。它几乎与用于 mysite.yaml 的完全相同，因此首先将 mysite.yaml 复制为 mydog.yaml。现在将 mydog.yaml 修改为：
apiVersion: apps/v1kind: Deploymentmetadata: name: mydog-nginx labels: app: mydog-nginxspec: 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: v1kind: Servicemetadata: name: mydog-nginx-servicespec: selector: app: mydog-nginx ports: - protocol: TCP port: 80---apiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata: name: mydog-nginx-ingress annotations: kubernetes.io/ingress.class: "traefik" traefik.frontend.rule.type: PathPrefixStripspec: 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
现在，我的狗的消息应该可以在 http://kmaster/mydog/ 上找到。
呼！消息发出去了！也许今晚我们都可以睡一觉。
因此，现在，我们有了一个 k3s 集群，该集群托管了两个网站，Traefik 根据路径名决定将请求传递给哪个服务！但是，不仅限于基于路径的路由，我们也可以使用基于主机名的路由，我们将在以后的文章中进行探讨。
另外，我们刚刚托管的网站是标准的未加密 HTML 网站，而如今的所有内容都使用 SSL/TLS 加密。在我们的下一篇文章中，我们将为 k3s 集群添加支持以托管 SSL/TLS HTTPS 站点！
在开始之前，由于本文主要涉及的是示例站点，因此我想向你展示如何删除内容，以防万一你不希望将这些示例丢在集群中。
对于大多数配置，只需使用与部署时使用的相同配置文件运行 delete 命令即可撤消配置。因此，让我们同时清理 mysite 和 mydog。
kubectl delete -f mysite.yamlkubectl delete -f mydog.yaml
由于我们是手动创建配置映射的，因此我们也需要手动删除它们。
kubectl delete configmap mysite-htmlkubectl delete configmap mydog-html
现在，如果我们执行 kubectl get pods，我们应该看到我们的 nginx Pod 不存在了。
$ kubectl get podsNo resources found in default namespace.
以上是“怎么使用Traefik引导Kubernetes流量”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！