【K8S in Action】服务：让客户端发现pod 并与之通信（2）
一 通过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 访问应用， 请确保应用不是仅绑定到本地主机