【K8S in Action】服务:让客户端发现pod 并与之通信(2)

2023-12-24 14:10:23

一 通过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 访问应用, 请确保应用不是仅绑定到本地主机

文章来源:https://blog.csdn.net/qq_21438267/article/details/134982618
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。