Kubernetes 实战——发现应用(Service) (3)

Kubernetes 实战——发现应用(Service)

1. 创建 Ingress 资源 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: kubia spec: rules: # 接收所有请求主机 kubia.example.com 的 HTTP 请求,转发到 kubia-nodeport 的 80 端口 - host: kubia.example.com # must be a DNS name, not an IP address http: paths: - path: / backend: serviceName: kubia-nodeport servicePort: 80 $ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE kubia <none> kubia.example.com 192.168.99.100 80 14s # 要将域名解析为 Ingress 控制器的 IP $ vi /etc/hosts 192.168.99.100 kubia.example.com $ curl You've hit kubia-5asi2 2. Ingress 工作原理

Kubernetes 实战——发现应用(Service)

客户端首先对 kubia.example.com 执行 DNS 查找,DNS 服务器(或本地操作系统)返回 Ingress 控制器的 IP

客户端向 Ingress 控制器发送 HTTP 请求,并在 Host 头中指定 kubia.example.com

控制器从该头部确定客户端尝试访问哪个服务,通过与服务关联的 EndPoint 查看 Pod IP,并将请求转发给其中一个 Pod

3. 暴露多个服务

将不同的服务映射到不同主机的不同路径

需要将两个域名都指向 Ingress 控制器的 IP 地址,通过 Host 头判断

spec: rules: - host: kubia.example.com http: paths: - path: /kubia backend: serviceName: kubia servicePort: 80 - path: /foo backend: serviceName: foo servicePort: 80 - host: bar.example.com http: paths: - path: / backend: serviceName: bar servicePort: 80 4. 处理 TLS 传输

Ingress 转发 HTTPS 流量

当客户端创建到 Ingress 控制器的 TLS 连接时,客户端和 Ingress 控制器之间的通信是加密的,而控制器和后端 Pod 之间的通信不是

kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key kind: Ingress spec: tls: # tls 配置 - hosts: # 接收主机的 tls 连接 - kubia.example.com serviceName: tls-secret # 私钥和证书 五、就绪探针

Pod 启动时可能需要加载配置或数据,此时不要将请求转发到这些 Pod,直到准备就绪

就绪探针被定期调用(默认 10s/次),来确定 Pod 是否可以接收客户端请求

启动容器时,可配置一个等待时间,等待后执行第一次就绪检查,之后周期性调用就绪探针

若 Pod 未准备就绪,则从服务中删除该 Pod,就绪后再添加 Pod

只要删除容器,K8s 就会从所有服务中移除该容器,此时无需用就绪探针

类型

Exec 探针:由进程的退出状态码确定

HTTP GET 探针:向容器发送请求,由响应状态码确定

TCP socket 探针:打开一个 TCP 连接到容器的指定端口,由连接是否建立来确定

对比

存活探针通过重启异常容器来保持 Pod 正常工作

就绪探针确保只有准备好的 Pod 才能接收请求

添加就绪探针

apiVersion: v1 kind: ReplicationController metadata: name: kubia spec: replicas: 2 template: metadata: labels: app: kubia spec: containers: - name: kubia image: luksa/kubia readinessProbe: exec: command: ["ls", "/var/ready"] ports: - containerPort: 8080 $ kubectl get pod NAME READY STATUS RESTARTS AGE kubia-5csgl 0/1 Running 0 2m5s kubia-qj7gz 0/1 Running 0 2m5s $ kubectl exec kubia-5csgl -- touch /var/ready $ kubectl get pod NAME READY STATUS RESTARTS AGE kubia-5csgl 1/1 Running 0 3m43s kubia-qj7gz 0/1 Running 0 3m43s 六、headless 服务

创建 headless 服务

apiVersion: v1 kind: Service metadata: name: kubia-headless spec: clusterIP: None # headless selector: app: kubia ports: - port: 80 targetPort: 8080

执行 DNS 查找

# 创建可支持 DNS 查找的 Pod $ kubectl run dnsutils --image=tutum/dnsutils --command -- sleep infinity pod/dnsutils created # headless 服务返回的是(就绪的)Pod IP $ kubectl exec dnsutils nslookup kubia-headless ... Name: kubia-headless.default.svc.cluster.local Address: 10.42.0.20 Name: kubia-headless.default.svc.cluster.local Address: 10.42.0.19 # 常规服务返回的是 Cluster IP $ kubectl exec dnsutils nslookup kubia ... Name: kubia.default.svc.cluster.local Address: 10.43.99.228

客户端也可通过 headless 服务的 DNS 名称直接连接到 Pod

headless 服务通过 DNS 轮询机制提供 Pod 的负载均衡,而非服务代理

可通过 DNS 查找机制查找未准备好的 Pod:使用 publishNotReadyAddresses 字段

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwxypz.html