一 通过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: kubiaimage: luksa/kubiareadinessProbe: 就绪探针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: 80targetPort: 8080selector: 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 infinitykubectl 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.5kubectl 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 访问应用, 请确保应用不是仅绑定到本地主机