崔婧雯 译 分布式实验室

Kubernetes网络基础介绍_Java


如果你读过该系列的前一篇文章,那么在你的集群里应该已经成功运行着Gitea的deployment了。下一步是能够通过Web浏览器访问它。本文会介绍一些Kubernetes的网络基础知识,并且可以让外部网络可以访问Gitea容器。
打开容器端口

Kubernetes网络基础介绍_Java_02


Pod默认是和外部隔离的。为了能够将流量导入应用程序,我们需要打开该容器计划使用的一系列端口。
Gitea容器内的软件会监听3000端口上的http请求,以及22端口上的SSH链接。可以通过如下YAML文件打开这些端口

Kubernetes网络基础介绍_Java_03

在集群里应用这个更新过的文件:

$ kubectl apply -f gitea.yaml

这时,就可以运行命令kubectl describe deployment来查看新打开的端口了。Pod应该已经打开了3000和22端口。Kubernetes网络基础介绍_Java_04

使用端口转发进行调试

Kubernetes网络基础介绍_Java_02


容器上的端口应该已经开启了,但是我们仍然需要能够和集群里的pod通信。为了调试的方便,我们可以使用kubectl port-forward来连接Pod。Kubernetes网络基础介绍_Java_06

这样,kubectl就会将本机3000端口的所有连接转发到云上的pod里。在浏览器打开 http://localhost:3000,你就可以和服务器交互了,服务器就像运行在本地一样。Kubernetes网络基础介绍_Java_07Kubernetes网络基础介绍_Java_08
创建外部LoadBanlancer

Kubernetes网络基础介绍_Java_02


既然已经验证了Pod工作正常,就可以暴露到公网上了。我们需要添加一个新的Kubernetes资源,它会预配一个公网IP地址并且将入站请求路由到Pod上。可以使用称为Service(服务)的Kubernetes资源来达到这一目的。可以使用好几种不同类型的服务,但是这里我们使用LoadBalancer。

Kubernetes网络基础介绍_Java_10

和Deployment一样,Service使用选择器(第29-30行)。这个选择器告诉LoadBanlancer将流量路由到哪些Pod里。当LoadBanlancer收到请求时,它会智能地将负载分发给匹配这个选择器的所有Pod。这里,因为我们仅有一个Pod,所以负载均衡很简单。
LoadBanlancer管理的端口定义在31-39行。除了定义一个唯一名称以及协议类型(TCP/UDP)之外,用户还必须定义“port”和“targetPort”。这两个字段定义了外部IP的端口(port)和容器使用端口(targetPort)的映射。在33和34行里,LoadBanlancer会监听80端口的请求(Web浏览器查看网页的默认端口),并且将请求转发给Pod的3000端口。
我们再次需要将更改应用到集群里:

$ kubectl apply -f gitea.yaml

等待几分钟变更生效后,检查服务:Kubernetes网络基础介绍_Java_11

几分钟后,就能看到一个外部IP自动添加到了服务上。在web浏览器里打开这个IP就可以和pod上的web服务器交互了。Kubernetes网络基础介绍_Java_12Pod间通信:ClusterIP服务

Kubernetes网络基础介绍_Java_02


如果你尝试打开Gitea的注册页面,会看到还缺了一些东西:Gitea要求一个数据库才能提供这个功能。要解决这个问题,我们可以选择在Gitea Pod里以side-car[1]的形式添加一个MySQL容器,或者单独创建一个MySQL的Pod。这两种方法都有各自的优势和缺点,选择哪一个取决于具体的需求。本文我们创建一个新的Pod。
我们创建一个名为mysql.yaml的新YAML文件来管理数据库:Kubernetes网络基础介绍_Java_14

大部分内容很类似。我们声明了一个Deployment来管理这个pod,通过Service管理网络连接。这里,service的类型是“ClusterIP”;这意味着这个IP仅仅暴露在集群内部,这和之前使用LoadBanlancer将Gitea服务暴露到外部不一样。
在集群里应用这个新YAML文件:

$ kubectl apply -f mysql.yaml

这时你可以看到集群里新加了一个Pod、Deployment和Service。
Kubernetes网络基础介绍_Java_15

Kubernetes网络基础介绍_Java_16ClusterIP服务会自动生成一个内部IP地址,显示在上面控制台输出的“CLUSTER-IP”一栏。集群内的任何容器都可以使用这一地址访问MySQL pod。但是,并不推荐直接使用内部IP地址。Kubernetes提供了更为简单的方式来访问这个新服务:可以在地址字段输入“mysql-service”即可。这是因为内建了“kube-dns[2]”Pod,它为所有服务管理内部的DNS解析。这样,用户可以忽略随机生成的内部IP地址,仅仅使用静态的,可读的服务名称就可以了。
要让Gitea能够和MySQL Pod通信,仅仅需要在Web UI的“host”字段输入服务的名称和端口就可以了。如果一切和预期一样,就会看到“access denied”的错误。这意味着Pod可以成功通信了,但是它们需要更多的配置信息才能完成认证。下一篇博客会继续介绍如何完成认证。
Kubernetes网络基础介绍_Java_17
下一步

Kubernetes网络基础介绍_Java_02


本文介绍了Kubernetes网络的基础知识,包括容器端口,端口转发,LoadBanlancer以及ClusterIP服务和kube-dns。当然,网络是一个很大的领域,没有讨论的还有很多。如果你想了解Kubernetes的底层网络实现,可以参考这个系列[3]。如果你对控制集群里的哪些Pod可以通信感兴趣,可以阅读网络策略[4]。如果你想更好地控制服务间的相互通信,可以研究服务网格产品,比如Istio。
备注

Kubernetes网络基础介绍_Java_02


  1. LoadBanlancer在云服务,比如GCP上工作很好,但是如果你在Docker或者Minikube上运行本地集群,就需要使用NodePort服务代替。

  2. 外部端口可以设置成任意值,但是要记住如果你想访问非标准的东西,在GKE上需要设置防火墙规则。

  3. 这里使用MySQL因为Gitea是这么设计的。MySQL是一种遗留服务,并非Kubernetes原生的,如果你想从头开始设计应用程序,可能别的存储方案更为适合。

  4. Kubernetes管理一些隐藏的Pod和服务。可以运行kubectl get pods --namespace=kube-system查看它们。


相关链接:
  1. https://www.voxxed.com/2015/01/use-container-sidecar-microservices/

  2. https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

  3. https://medium.com/google-cloud/understanding-kubernetes-networking-pods-7117dd28727

  4. https://github.com/ahmetb/kubernetes-network-policy-recipes


原文链接:https://medium.com/google-cloud/kubernetes-120-networking-basics-3b903f13093a