Kubernetes 学习笔记(四):详解 k8s 的各项资源

Service

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

DNS

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

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

全限定域名的格式如下:

# 格式
..svc.cluster.local  # 域名 .svc.cluster.local 是可自定义的

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

如果两个服务在同一个名字空间内,可以省略掉后面的 ..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 记录。

最佳实践

  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 之间的流量分配不均。

你可能感兴趣的:(Kubernetes 学习笔记(四):详解 k8s 的各项资源)