Kubernetes 学习笔记（四）：详解 k8s 的各项资源

个人笔记，写得不详细。。。

Service

Service 通过标签选择 pod，将各 pod 的 ip 保存到它的 endpoints 属性中。Service 的收到的请求会被均摊到这一组 endpoints 上。

DNS

在 k8s 中做服务发现，最常用的方式是通过 DNS 解析。

在我们的 k8s 集群配置了 dns 服务（最常用的是 coredns）的前提下，我们就可以直接通过全限定域名（FQDN）来访问别的服务。

全限定域名的格式如下：

# 格式
<service-name>.<namespace>.svc.cluster.local  # 域名 .svc.cluster.local 是可自定义的

# 举例：访问 default 名字空间下的 nginx 服务
nginx.default.svc.cluster.local

如果两个服务在同一个名字空间内，可以省略掉后面的 .<namespace>.svc.cluster.local，直接以服务名称为 DNS 访问别的服务

P.S. DNS 服务发现的实现方式：修改每个容器的 /etc/resolv.conf，使容器访问 k8s 自己的 dns 服务器。而该 dns 服务器知道系统中的所有服务，所以它能给出正确的响应。

SRV 记录

Service 除了会使用最常见的 A 记录做 Pod 的负载均衡外，还提供一种 SRV 记录，这种类型的服务被称为 Headless Service.

将 Service 的 spec.ClusterIP 设为 None，得到的就是一个 Headless Service。

普通的 Service 拥有自己的 ClusterIP 地址，service name 会被 DNS 解析到这个虚拟的 ClusterIP（A 记录或 CNAME 记录），然后被 kubectl proxy 转发到具体的 Pod。

而 Headless Service 没有自己的 ClusterIP（这个值被指定成了 None），service name 只提供 SRV 记录的 DNS 解析，返回一个 Pods 的 ip/dns 列表。

SRV 记录最常见的用途，是在有状态集群中，给集群的所有 Pod 提供互相发现的功能。

最佳实践

1. 总是使用 Deployment，避免直接使用 ReplicaSet/Pod
2. 为 Pod 的 Port 命名（比如命名成 http/https），然后在 Service 的 targetPort 中通过端口名称（http/https）来指定目标端口（容器端口）。
   • 更直观，也更灵活
3. 应用通过 dns 查找/发现其他服务
   • 同一名字空间下的应用，可以直接以服务名称为域名发现别的服务，如通过 http://nginx 访问 nginx
4. Service 配置会话亲和性为 ClientIP 可能会更好（会话将被同一个 pod 处理，不会发生转移）
5. 配置 externalTrafficPolicy: Local 可以防止不必要的网络跳数，但是可能会导致 pod 之间的流量分配不均。