《Linkerd官方文档》在Kubernetes中运行Linkerd

在Kubernetes中运行

如果您拥有Kubernetes群集或者甚至只是运行Minikube，那么将Linkerd作为服务网格部署是最快开始的方式。它不仅非常易于部署，而且还适用于大多数生产用例，提供服务发现，仪器，智能客户端负载均衡，断路器和动态路由即开即用。

Linkerd服务网格作为Kubernetes DaemonSet 来部署，在集群的每个节点上运行一个Linkerd网格。运行在Kubernetes上的应用程序可以通过其节点上运行的Linkerd发送其所有网络流量来利用服务网格。

部署Linkerd服务网格

使用以下命令部署Linkerd服务网格：

kubectl create ns linkerd

kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/servicemesh.yml

您可以通过运行验证Linkerd是否已成功部署

kubectl -n linkerd port-forward $(kubectl -n linkerd get pod -l app=l5d -o jsonpath={.items[0].metadata.name}) 9990 

然后在您的浏览器中，通过访问http://localhost:9990 查看Linkerd管理仪表板。

请注意，如果您的群集使用CNI，则需要对Linkerd配置进行一些小的更改以启用CNI兼容性。这些在配置文件本身中都被注释掉。您可以在我们的Kubernetes Flavors页面上了解有关CNI兼容性的更多信息 。

配置你的应用

要将应用程序配置为使用Linkerd进行HTTP通信，您可以将http_proxy环境变量设置 为$(NODE_NAME):4140其中NODE_NAME为运行应用程序实例的节点的名称。该 NODE_NAME环境变量可以通过使用Kubernetes downward API在实例的pod规范中来设置：

 env:

 - name: NODE_NAME

 valueFrom:

 fieldRef:

 fieldPath: spec.nodeName

 - name: http_proxy

 value: $(NODE_NAME):4140

查看我们的 hello world ， Kubernetes配置了一个完整的例子。

请注意，spec.nodeName在某些环境（如 Minikube）中不起作用。请参阅我们 的Kubernetes Flavors页面 了解变通方法。

如果您的应用程序不支持http_proxy环境变量，或者您想要将应用程序配置为使用Linkerd进行HTTP / 2或gRPC通信，则必须将应用程序配置为直接向Linkerd发送通信：

$(NODE_NAME):4140 为HTTP $(NODE_NAME):4240 对于HTTP / 2 $(NODE_NAME):4340 为gRPC

如果要发送HTTP或HTTP / 2流量直接到Linkerd，必须将主机/管理局头设置 service 或 service . namespace ，并且  service 和 namespace 是要代理服务和命名空间的名称。如果未指定，则 namespace 默认为 default。

如果您的应用程序接收HTTP，HTTP / 2，和/或GRPC通信，那么必须有一个端口名称分别为http，h2和/或grpc 的Kubernetes服务对象。

Linkerd服务网格也被配置为充当 入口控制器。只需创建一个定义所需路由的Ingress资源，然后将请求发送到集群入口地址的80端口（或端口8080，用于HTTP / 2）。在具有外部负载均衡器的云环境中，入口地址是外部负载均衡器的地址。否则，任何节点的地址都可以用作入口地址。

请参阅我们的Ingress博客文章了解更多详情。

这个配置是一个很好的起点，适用于广泛的用例。请查看我们 的Kubernetes博客系列的服务网格 ，了解如何启用更高级的Linkerd功能，如 服务到服务的加密， 持续部署和按请求路由。

原创文章，作者：kepupublish，如若转载，请注明出处：https://blog.ytso.com/93958.html

通信