【K8S in Action】服务：让客户端发现pod 并与之通信（2）

最新推荐文章于 2024-05-17 15:42:42 发布

偶入编程深似海

最新推荐文章于 2024-05-17 15:42:42 发布

阅读量221

点赞数

分类专栏：部署与运维篇数据结构与算法文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/qq_21438267/article/details/134982618

版权

部署与运维篇同时被 2 个专栏收录

17 篇文章 0 订阅

订阅专栏

数据结构与算法

4 篇文章 0 订阅

订阅专栏

一通过Ingress暴露服务

Ingress (名词）一一进入或进入的行为；进入的权利；进入的手段或地点；入口。一个重要的原因是每个 LoadBalancer 服务都需要自己的负载均衡器，以及
独有的公有 IP 地址，而 Ingress 只需要一个公网 IP 就能为许多服务提供访问。
Ingress 在网络栈 (HTTP) 的应用层操作。

1.1 Ingress 控制器是必不可少的

只有Ingress控制器在集群中运行，Ingress 资源才能正常工作。在 minikube 上启动 Ingress 的扩展功能。

# 确保已启用 Ingress 附加组件
$ minikube addons list
- default-storageclass: enabled
- kube-dns: enabled
- heapster: disabled
- ingress: disabled    # 没有启动
- registry-creds: disabled
- addon-manager: enabled 
- dashboard: enabled

# 启用 Ingress 附加组件
$ minikube addons enable ingress
ingress was successfully enabled

# 查看控制Pod
$ kubectl get po  --all-namespaces

1.2 创建 Ingress 资源

apiVersion: extensions/vlbetal
kind: Ingress 
metadata:
	name : kubia.example.com
spec : 
	rules: 
	- host: kubia.example.com    #将域名映射到对应的服务
		http : 
		paths 
		- path: /
		  backend: 
			serviceName: kubia-nodeport   # 将请求发送到kubia-nodeport 的80端口
			servicePort 80


要通过 http://kubi example.com 访问服务，需要确保域名解析为 ngress 控制器 IP
kubectl get ingresses
NAME   HOSTS                ADDRESS         PORTS AGE 
kubia  kubia.example.com  192.168.99.100    80   29m

通过配置 DNS 服务器将kubia.example.com解析为 IP地址，或者在 /ect/host文件（ Windows 系统为 \windows\system32\drivers\etc\hosts 中添加下面行内容
192.168.99.100 kubia.example.com

通过 Ingress 访问 pod: curl http: / /kubia.example.com

在这里插入图片描述

1.3 通过相同的Ingress 暴露多个服务

- host:kubia.example.com 
	http: 
		paths: 
		- path: /kubia 
			backend: 
				serviceName : kubia   # kubia.example.com/kubia 转发到kubia服务80端口
				servicePort: 80 
		- path: /foo 
			backend: 
				serviceName : bar  # kubia.example.com/foo 转发到bar服务80端口
				ser cePort: 80

二 pod 就绪后发出信号

还有一件关于 Service 和 Ingress 的事情。pod 可能需要时间来加载配置或数据。不要将请求转发到正在启动的 pod 中，到完全准备就绪。

像存活探针一样，就绪探针有三种类型：
• Exec 探针，执行进程的地方。容器的状态由进程的退出状态代码确定
•HTTP GET 探针，向容器发送 HTTP GET 请求，通过响应的 HTTP 状态代码
判断容器是否准备好
• TCP socket 探针，它打开 TCP 连接到容器的指定端口。如果连接己建立，
则认为容器己准备就绪

启动容器时，可以为 k8s 配置等待时间，经过等待时间后才可以执行第1次准备就绪检查。之后，它会周期性地调用探针，并根据就绪探针的结果采取行动。如果某个 po 报告它尚未准备就绪，则会从该服务中删除该 pod 。如果再次准备就绪，则重新添加 pod。

apiVersion: vl 
kind: ReplicationController
spec: 
	template:
		spec: 
			containers:
			- name: kubia
				image: luksa/kubia
				readinessProbe:        就绪探针
					exec:  
						- ls 
						- /var/ready   定期在容器内执行ls/var/ready命令，返回退出码0， 表示成功

务必定义就绪探针
不要将停止 pod 的逻辑纳入就绪探针中
只要删除该容器， Kubemetes就会从所有服务中移除该容器。

三使用 headless服务来发现独立的pod

如果客户端需要链接到所有的 pod 呢？如果后端的 pod 都需要连接到所有其他
pod如何处理。

一种选择是让客户端调用 Kubemetes API 服务器并通过 API调用获取 pod 及其 IP 地址列表。
但由于应始终努力保持应用程序与 Kubemetes 无关，因此使用 API 服务器并不理想。
Kubemetes 允许客户通过 DNS 查找发现 pod IP
当执行服务的 DNS 查找时， DNS 服务器会返回单个 IP一服务的集群 IP。但是，如果告诉Kubemetes, 不需要为服务提供集群 IP (通过在服务 spec 中将 clusterIP 字段设置为 None 来完成此操作），则 DNS 服务器将返回 podIP 而不是单个服务 IP。

3.1 创建headless服务

apiVersion: vl 
kind: Service 
metadata:
	name: kubia-headless 
spec: 
	clusterIP: None     服务成为handless的
	ports: 
	- port： 80
		targetPort： 8080
	selector: 
		app: kubia

kubectl create 创建服务之后，可以通过kubectl get和kubectl describe来查看服务，你会发现它没有集群IP,并且它的后端包含与pod选择器匹配的就绪 pod。

3.2 通过DNS发现pod

尝试执行DNS查找以查看是否获得了实际的podIP。需要从其中一个pod中执行查找。
注意： headless 服务仍然提供跨 pod 的负载平衡，但是通过 DNS 轮询机制不是通过服务代理

kubect1 run dnsutils --image=tutum/dnsutils --generator=run-pod/vl  --command -- sleep infinity

kubectl exec dnsutils nslookup kubia-headless    执行 DNS 查找
Name: kubia-headless.default.svc.cluster.local
Address: 10.108.1.4 
Name: kubia-headless.default.svc.cluster.local
Address: 10.108.2.5

kubectl exec dnsutils nslookup kubia      返回的IP是服务的集群 IP
Name: kubia.default.svc.cluster.local 
Address: 10.111.249.153

–generator=run-pod/vl 选项中，该选项让 kubec七1直接创建pod, 而不需要通过 ReplicationController 之类的资源来创建。

3.3 发现所有的pod一包括未就绪的pod

不必通过查询KubemetesAPI服务器，可以使用DNS查找机制来查找那些未准备好的pod。要告诉Kubemetes无论pod的准备状态如何，希望将所有pod 添加到服务中。必须将以下注解添加到服务中

kind: Service 
metadata: 
	annotations:
		service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"

警告：注解名称表明了这是一个alpha功能。Service AP I已经支待一个名为 publishNotReadyAddresses 的新服务规范字段。

4 排除服务故障

服务是Kubemetes的一个重要概念，也是让许多开发人员感到困扰的根源。许多开发人员为了弄清楚无法通过服务IP 或FQDN 连接到他们的pod的原因花费了
大量时间。
如果无法通过服务访问pod, 应该根据下面的列表进行排查：

确保从集群内连接到服务的集群IP,而不是从外部
不要通过ping服务IP 来判断服务是否可访问（请记住，服务的集群IP 是虚
拟IP, 是无法ping通的）
如果已经定义了就绪探针，请确保它返回成功；否则该pod不会成为服务的
一部分
要确认某个容器是服务的一部分，请使用kubectl ge七 endpoints来检
查相应的端点对象
如果尝试通过FQDN或其中一部分来访问服务（例如， myservice.
mynamespace.svc.cluster.local或 myservice.mynamespace), 但并不起作用，请查看是否可以使用其集群IP而不是FQDN来访问服务
检查是否连接到服务公开的端口，而不是目标端口
尝试直接连接到podIP以确认pod正在接收正确端口上的连接
如果甚至无法通过pod的IP 访问应用，请确保应用不是仅绑定到本地主机

偶入编程深似海

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【K8S in Action】服务：让客户端发现pod 并与之通信（2）

要告诉Kubemetes无论pod的准备状态如何，希望将所有pod 添加到服务中。kubectl create 创建服务之后，可以通过kubectl get和kubectl describe来查看服务，你会发现它没有集群IP,并且它的后端包含与pod选择器匹配的就绪 pod。–generator=run-pod/vl 选项中，该选项让 kubec七1直接创建pod, 而不需要通过 ReplicationController 之类的资源来创建。• Exec 探针，执行进程的地方。
复制链接

扫一扫