kubernetes如何访问pod服务

1、经过 Service 访问 Pod:

  咱们不该该指望 Kubernetes Pod 是健壮的,而是要假设 Pod 中的容器极可能由于各类缘由发生故障而死掉。Deployment 等 controller 会经过动态建立和销毁 Pod 来保证应用总体的健壮性。换句话说,Pod 是脆弱的,但应用是健壮的。node

每一个 Pod 都有本身的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时,新 Pod 会分配到新的 IP 地址。这样就产生了一个问题:nginx

若是一组 Pod 对外提供服务(好比 HTTP),它们的 IP 颇有可能发生变化,那么客户端如何找到并访问这个服务呢?算法

Kubernetes 给出的解决方案是 Service。后端

  在k8s里面,好比咱们运行了一个服务,这个服务是启动了3副本,客户端要访问这个服务的时候,不是直接访问你的pod,而是访问pod对外提供的表明,service,service会固定一个IP地址,即便你的pod怎么去销毁从新建立,不要紧,我service对外提供服务,你只要访问我service这个固定IP就好。(你访问service的时候,不是说三个pod同时对外提供服务,它会把你请求呢根据必定的算法,转发到你后端的三个pod里面,有可能你这个访问的是第一个pod给你提供的实际服务,有可能第二次就是第二个pod给你提供的服务,那api

建立 Service(也须要经过编排文件建立出来)

  Kubernetes Service 从逻辑上表明了一组 Pod,具体是哪些 Pod 则是由 label 来挑选。Service 有本身 IP,并且这个 IP 是不变的。客户端只须要访问 Service 的 IP,Kubernetes 则负责创建和维护 Service 与 Pod 的映射关系。不管后端 Pod 如何变化,对客户端不会有任何影响,由于 Service 没有变。服务器

来看个例子,建立下面的这个 Deployment:app

 

  咱们启动了两个 Pod,运行 httpd 镜像,label 是 run: httpd,Service 将会用这个 label 来挑选 Pod,怎么说,下图假如是一台主机,它里面运行了不少不少的pod,如上图的yml文件,咱们只起了两个httpd的pod,另外三个pod运行的假如是nginx,那么service怎么去选择启动的httpd的pod呢?就是由于这两个pod里定义了label,run:httpd,在我service的yml文件中selector(选择器)也会有一个label,挑选run:httpd的pod。负载均衡

Pod 分配了各自的 IP,这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问(这个IP是私有的IP,只能在我集群当中的节点来访问)。ide

接下来建立 Service,其配置文件以下:测试

 

① v1 是 Service 的 apiVersion。

② 指明当前资源的类型为 Service。

③ Service 的名字为 httpd-svc。

④ selector 指明挑选那些 label 为 run: httpd 的 Pod 做为 Service 的后端。

⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议。

执行 kubectl apply 建立 Service httpd-svc。

  httpd-svc 分配到一个 CLUSTER-IP 10.68.236.129。为何是这个IP呢,由于当初咱们部署的时候配置文件定义了service的IP,咱们看一下,能够经过该 IP 访问后端的 httpd Pod。

  根据前面的端口映射,这里要使用 8080 端口。另外,除了咱们建立的 httpd-svc,还有一个 Service kubernetes,Cluster 内部经过这个 Service 访问 kubernetes API Server。

经过 kubectl describe 能够查看 httpd-svc 与 Pod 的对应关系。

kubectl describe service httpd-svc

kubectl get pod -o wide

  Endpoints 罗列了两个 Pod 的 IP 和端口。咱们知道 Pod 的 IP 是在容器中配置的,那么 Service 的 Cluster IP 又是配置在哪里的呢?CLUSTER-IP 又是如何映射到 Pod IP 的呢?

答案是 iptables

2、Service IP 原理:

Service IP 原理

Service Cluster IP 是一个虚拟 IP,是由 Kubernetes 节点上的 iptables 规则管理的。

能够经过 iptables-save 命令打印出当前节点的 iptables 规则,由于输出较多,这里只截取与 httpd-svc Cluster IP 10.68.236.129 相关的信息:

这条规则的含义是:

若是 Cluster 内的 Pod要访问 httpd-svc,跳转到规则 KUBE-SVC-LLMSFKRLGJ6BVN7Z

KUBE-SVC-LLMSFKRLGJ6BVN7Z 规则以下:

上面两个跳转的规则以下:

即将请求分别转发到后端的两个 Pod。经过上面的分析,咱们获得以下结论:

iptables 将访问 Service 的流量转发到后端 Pod,并且使用相似轮询的负载均衡策略。

另外须要补充一点:Cluster 的每个节点都配置了相同的 iptables 规则,这样就确保了整个 Cluster 都可以经过 Service 的 Cluster IP 访问 Service。

  一个客户端要访问你的服务的时候,它先转发给了一条规则(Cluster_IP的规则),这条规则又分别转发给了两条规则(这两条规则分别是pod_ip的规则),这两条规则里具体写了pod的地址。

DNS 访问 Service:

在 Cluster 中,除了能够经过 Cluster IP 访问 Service,Kubernetes 还提供了更为方便的 DNS 访问。

DNS组件

kubeadm 部署时会默认安装 kube-dns 组件。

  coredns 是一个 DNS 服务器。每当有新的 Service 被建立,coredns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 能够经过 <SERVICE_NAME>.<NAMESPACE_NAME> 访问 Service。

好比能够用 httpd-svc.default 访问 Service httpd-svc。

kubectl run busybox --rm -ti --image=reg.yunwei.edu/learn/busybox:latest /bin/sh

wget httpd-svc:8080

3、外网访问 Service:

外网如何访问 Service?

除了 Cluster 内部能够访问 Service,不少状况咱们也但愿应用的 Service 可以暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service,默认是 ClusterIP。

ClusterIP 

Service 经过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 ClusterIP。

NodePort 

Service 经过 Cluster 节点的静态端口对外提供服务。Cluster 外部能够经过 <NodeIP>:<NodePort> 访问 Service。

LoadBalancer 

Service 利用 cloud provider 特有的 load balancer 对外提供服务,cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。

下面咱们来实践 NodePort,Service httpd-svc 的配置文件修改以下:

添加 type: NodePort,从新建立 httpd-svc。

Kubernetes 依然会为 httpd-svc 分配一个 ClusterIP,不一样的是:

一、EXTERNAL-IP 为 none,表示可经过 Cluster 每一个节点自身的 IP 访问 Service。

二、PORT(S) 为 8080:27449。8080 是 ClusterIP 监听的端口,27449 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口,每一个节点都会监听此端口并将请求转发给 Service。

下面测试 NodePort 是否正常工做。

经过节点 IP +20801  端口都可以访问 httpd-svc。

NodePort 默认是的随机选择,不过咱们能够用 nodePort 指定某个特定端口。

如今配置文件中就有三个 Port 了:

一、nodePort 是节点上监听的端口。

二、port 是 ClusterIP 上监听的端口。

三、targetPort 是 Pod 监听的端口。

  看一下type类型,原来是ClusterIP,如今变成了NodePort,在集群以内,咱们访问的是cluster-ip加8080端口。如今8080端口又映射给了node的20801端口,如今咱们能够在集群以外的节点任意访问nodeIP加20801端口,这样也就访问到了pod提供的http服务了。

相关文章
相关标签/搜索