k8s教程（service篇）-总结（下）-阿里云开发者社区

2.2.6.2 LoadBalancer类型

通常在公有云环境中设置Service的类型为 “LoadBalancer‘” ，可以将Service映射到公有云提供的某个负载均衡器的IP地址上，客户端通过负载均衡器的IP和Service的端口号就可以访问到具体的服务，无须再通过kube-proxy提供的负载均衡机制进行流量转发。公有云提供的LoadBalancer可以直接将流量转发到后端Pod上，而负载分发机制依赖于公有云服务商的具体实现。

举例：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
type: LoadBalancer
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  clusterIP: 10.0.171.239

在服务创建成功之后，云服务商会在Service的定义中补充LoadBalancer的IP 地址（status字段)：

status:
  loadBalancer:
    ingress:
    - ip:192.0.2.127

2.2.6.3 ExternalName类型

ExternalName类型的服务用于将集群外的服务定义为Kubernetes的集群的Service，并且通过externalName字段指定外部服务的地址，可以使用域名或IP格式，集群内的客户端应用通过访问这个Service就能访问外部服务了。

这种类型的Service没有后端Pod，所以无须设置Label Selector。例如：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

在本例中设置的服务名为my-service，所在namespace为prod，客户端访问服务地址my-service.prod.svc.cluster.local时，系统将自动指向外部域名my.database.example.com。

2.2.7 Service支持的网络协议

目前Service支持的网络协议如下.

类型	描述
TCP	Service的默认网络协议，可用于所有类型的Service
UDP	可用于大多数类型的Service，LoadBalancer类型取决于云服务商对UDP的支持
HTTP	取决于云服务商是否支持HTTP和实现机制
PROXY	取决于云服务商是否支持HTTP和实现机制
SCTP	从Kubernetes1.12版本引入，到1.19版本时达到Beta阶段，默认启用，如需关闭该特性，则需要设置kube-apiserver的启动参数–feature- gates=-SCTPSupport=-false进行关闭

2.2.8 k8s的服务发现机制

2.2.8.1 环境变量的方式

在一个Pod运行起来的时候，系统会自动为其容器运行环境注入所有集群中有效Service的信息。

Service的相关信息包括服务IP、服务端口号、各端口号相关的协议等，通过{SVCNAME_SERVICE_HOST}和{SVCNAME_SERVICE_PORT}格式进行设置。

以webapp服务为例：

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec: 
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080
  selector:
    app: webapp

在一个新创建的Pod（客户端应用）中，可以看到系统自动设置的环境变量如下：

WEBAPP_SERVICE_HOST=169.169.81.175
WEBAPP_SERVICE_PORT=8080
WEBAPP_P0RT=tcp://169.169.81.175:8080
WEBAPP_P0RT_8080_TCP=tcp://169.169.81.175:8080
WEBAPP_PORT_8080_TCP_PROTO=tcp
WEBAPP_PORT_8080_TCP_PORT=8080
WEBAPP_PORT_8080_TCP_ADDR=169.169.81.175

然后，客户端应用就能够根据Service相关环境变量的命名规则，从环境变量中获取需要访问的目标服务的地址了，例如：

curl http://${WEBAPP_SERVICE_HOST}:${WEBAPP_SERVICE_HOST}

2.2.8.2 DNS的方式

Service在Kubernetes系统中遵循DNS命名规范，Service的DNS域名表示方法为<servicename>.<namespace>.svc.<clusterdomain>，其中：

字段	解析
servicename	服务的名称
namespace	所在namespace的名称
clusterdomain	Kubernetes集群设置的域名后缀（例如cluster.local)，服务名称的命名规则遵循RFC 1123规范的要求

以webapp服务为例，将其端口号命名为“http”：

apiversion: v1
kind: Service
metadata:
  name: webapp
spec:
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080
    name: http
  selector:
    app: webapp

解析名为 “http” 端口的DNS SRV记录

“_http._tcp.webapp.default.svc.cluster.local'”，可以查询到其端口号的值为8080。

2.2.9 headless service

在某些应用场景中，客户端应用不需要通过Kubernetes内置Service实现的负载均衡功能，需要自行完成对服务后端各实例的服务发现机制，或者需要自行实现负载均衡功能，此时可以通过创建一种特殊的名为 “Headless‘”的服务来实现。

服务名（DNS域名）的解析机制取决于该Headless Service是否设置了Label Selector。

2.2.9.1 已设置Label Selector

如果Headless Service设置了Label Selector，Kubernetes则将根据Label Selector查询后端Pod列表，自动创建Endpoint列表，将服务名（DNS域名）的解析机制设置为：当客户端访问该服务名时，得到的是全部Endpoint列表（而不是一个确定的IP地址)。

以下面的Headless Service为例，其设置了Label Selector：

apiversion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
  clusterIP: None
  selector:
    app: nginx

使用kubectl create命令创建完之后，可以查看该Headless Service的详细信息，可以看到后端的Endpoint列表：

当客户端通过DNS服务名 “nginx"和服务端口号访问该Headless服务(URL=nginx:80)时，将得到Service后端Endpoint列表"10.0.95.12:80,10.0.9513:80,10.0.95.14:80”，然后由客户端程序自行决定如何操作，例如：通过轮询机制访问各个Endpoint。

2.2.9.2 未设置Label Selector

如果headless Service没有设置Label Selector，则Kubernetes将不会自动创建对应的Endpoint列表。

DNS系统会根据下列条件尝试对该服务名设置DNS记录:

如果Service的类型为ExternalName，则对服务名的访问将直接被DNS系统转换为Service设置的外部名称（externalName）;
如果系统中存在与Service同名的Endpoint定义，则服务名将被解析为Endpoint定义中的列表,适用于非ExternalName类型的Service。

2.2.10 端点分片和服务拓扑

2.2.10.1 端点分片

EndpointSlice通过对Endpoint进行分片管理来实现降低Master和各Node之间的网络传输数据量及提高整体性能的目标。对于Deployment的滚动升级，可以实现仅更新部分Node上的Endpoint信息，Master与Node之间的数据传输量可以减少100倍左右，能够大大提高管理效率。

EndpointSlice根据Endpoint 所在Node的拓扑信息进行分片管理，如图所示：

Endpoint Slices要实现的第2个目标是为基于Node拓扑的服务路由提供支持，这需要与服务拓扑（Service Topology）机制共同实现。

2.2.10.2 服务拓扑

在默认情况下，发送到一个Service的流量会被均匀转发到每个后端Endpoint，但无法根据更复杂的拓扑信息设置复杂的路由策略。服务拓扑机制的引入就是为了实现基于Node拓扑的服务路由，允许Service创建者根据来源Node和目标Node的标签来定义流量路由策略。

通过对来源Node和目标Node标签的匹配，用户可以根据业务需求对Node进行分组，设置有意义的指标值来标识 “较近” 或者 “较远” 的属性：

例如：对于公有云环境来说，通常有区域（Zone或Region)的划分，云平台倾向于把服务流量限制在同一个区域内，这通常是因为跨区域网络流量会收取额外的费用。另一个例子是把流量路由到由DaemonSet管理的当前Node的Pod 上。又如希望把流量保持在相同机架内的Node上，以获得更低的网络延时。

2.3 dns服务搭建和配置

详情参考：《k8s教程（service篇）-DNS服务搭建和配置》

2.3.1 dns在k8s服务的发展

发展：SkyDNS => KubeDNS =>CoreDNS

CoreDNS架构图如下：

描述：

它是由go语言实现的一套高性能、插件式，易于扩展的DNS服务端；
解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains进行设置等等；
支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS；
它没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能。

2.3.2 coredns搭建

① 修改每个Node上kubelet的启动参数，在其中加上以下两个参数：

--cluster-dns=169.169.0.100：为DNS服务的ClusterIP地址。
--cluster-domain=cluster.local：为在DNS服务中设置的域名。

② 重启kubelet服务

③ 部署：需要创建3个资源对象：1个ConfigMap、1个Deployment和1个Service。

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system 
  labels: 
    addonmanager.kubernetes.io/mode: EnsureExists
data:
  Corefile: | 
    cluster.local{
      errors
      health{
        lameduck 5s 
      }
      ready
      kubernetes cluster.local 169.169.0.0/16{ 
        fallthrough in-addr.arpa ip6.arpa
      }
      prometheus: 9153
      forward ./etc/resolv.conf 
      cache 30 
      loop
      reload
      loadbalance
    }
    . {
      cache 30 
      loadbalance
      forward /etc/resolv.conf
    }
---
apiversion: apps/v1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system 
  labels:
    k8s-app: kube-dns
    kubernetes.io/name: "CoreDNS"
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  selector:
    matchLabels: 
      k8s-app: kube-dns
  template:
    metadata:
      labels:
        k8s-app: kube-dns
    spec:
    priorityClassName: system-cluster-critical 
    tolerations:
      - key: "CriticalAddonsonly"
        operator: "Exists"
    nodeSelector:
      kubernetes.io/os: linux 
    affinity:
      podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution: 
      - weight: 100
        podAffinityTerm:
          labelSelector:
          matchExpressions:
          - key: k8s-app
                operator: In
                values: ["kube-dns"]
          topologyKey: kubernetes.io/hostname
    containers:
    - name: coredns
      image: coredns/coredns:1.7.0 
      imagePullPolicy: IfNotPresent
      resources:
        limits:
          memory: 170Mi
        requests:
          cpu: 100m
          memory: 70Mi
      args: ["-conf","/etc/coredns/Corefile" ]
    volumeMounts:
    - name: config-volume 
      mountPath: /etc/coredns 
      readOnly: true
    ports:
    - containerPort: 53
      name: dns
      protocol: UDP
    - containerPort: 53
      name: dns-tcp
      protocol: TCP
    - containerPort: 9153
      name: metrics
      protocol: TCP
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
        - NET_BIND_SERVICE
        drop:
        - a11
      readOnlyRootFilesystem: true 
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
        scheme: HTTP
      initialDelaySeconds: 60 
      timeoutSeconds: 5
      successThreshold: 1
      failureThreshold: 5
    readinessProbe:
      httpGet:
        path: /ready
        port: 8181
        scheme: HTTP
    dnsPolicy: Default
    volumes:
    - name: config-volume
      configMap:
        name: coredns
        items:
        - key: Corefile
          path: Corefile
---
apiVersion: v1
kind: Service
metadata:
  name: kube-dns
  namespace: kube-system 
  annotations:
    prometheus.io/port: "9153" 
    prometheus.io/scrape: "true" 
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true" 
    kubernetes.io/name: "CoreDNS" 
spec:
  selector:
    k8s-app: kube-dns
  clusterIP: 169.169.0.100 
  ports:
  - name: dns
    port: 53
    protocol: UDP
  - name: dns-tcp
    port: 53
    protocol: TCP
  - name: metrics
    port: 9153
    protocol: TCP

使用kubectl create命令依次把资源对象创建，然后可以看到创建成功：

2.3.3 配置解析

CoreDNS的主要功能是通过插件系统实现的，CoreDNS实现了一种链式插件结构，将DNS的逻辑抽象成了一个个插件，能够灵活组合使用。常用的插件如下：

插件	描述
loadbalance	提供基于DNS的负载均衡功能
loop	检测在DNS解析过程中出现的简单循环问题
cache	提供前端缓存功能
health	对Endpoint进行健康检查
kubernetes	从Kubernetes中读取zone数据
etcd	从etcd中读取zone数据，可用于自定义域名记录
file	从RFC 1035格式文件中读取zone数据
hosts	使用/etc/hosts文件或者其他文件读取zone数据，可用于自定义域名记录
auto	从磁盘中自动加载区域文件
reload	定时自动重新加载Corefile配置文件的内容
forward	转发域名查询到上游DNS服务器上
prometheus	为Prometheus系统提供采集性能指标数据的URL
pprof	在URL路径/debug/pprof下提供运行时的性能数据
log	对DNS查询进行日志记录
errors	对错误信息进行日志记录

2.3.4 举例（自定义域名）

etcd和hosts插件都可以用于用户自定义域名记录。

下面是使用etcd插件的配置示例，将以“.com”结尾的域名记录配置为从etcd中获取，并将域名记录保存在/skydns路径下：

{
  etcd com{
    path /skydns
    endpoint http://192.168.18.3:2379 
    upstream /etc/resolv.conf 
  }
  cache 160 com 
  loadbalance
  proxy /etc/resolv.conf
}

如果用户在etcd中插入一条“10.1.1.1 mycompany” DNS记录：

$ ETCDCTL_API=3 etcdctl put "/skydns/com/mycompany" '["host":"10.1.1.","ttl":60]'

客户端应用就能访问域名"mycompany.com"了:

$ nslookup mycompany.com
Server:       169.169.0.100
Address:      169.169.0.100#53
Name:       mycompany.com
Address:      10.1.1.1

2.4 node本地dns缓存

详情参考：《k8s教程（service篇）-Node本地DNS缓存》

Node本地DNS缓存（NodeLocal DNSCache）的工作流程如图所示，客户端Pod首先会通过本地DNS缓存进行域名解析，当缓存中不存在域名时，会将请求转发到集群DS服务进行解析。

部署Node本地DNS缓存工具，主要包括 ServiceAccount、Daemonset、ConfigMap和Service 几个资源对象，详情看原文。

2.5 pod的dns域名

详情参考：《k8s教程（service篇）-pod的dns域名》

对Pod来说，Kubernetes会为其设置一个<pod-ip>.<namespace>.pod.<cluster-domain>格式的DNS域名，其中Pod IP部分需要用 “-” 替换 “.” 符号，例如下面Pod的IP地址为10.0.95.63：

系统为这个Pod设置的DNS域名为10-0-95-63.default.pod.cluster.local，用 nslookup进行验证，便可以成功解析该域名的IP地址为10.0.95.63：

其它与Service差不多，详情参考原文。

2.6 ingress 7层路由机制

详情参考：《k8s教程（service篇）-ingress 7层路由机制》

Kubernetes 使用了一个Ingress策略定义和一个具体提供转发服务的Ingress Controller，两者结合，实现了基于灵活Ingress策略定义的服务路由功能。

如果是对Kubernetes集群外部的客户端提供服务，那么Ingress Controller实现的是类似于边缘路由器（Edge Router）的功能。

需要注意的是，Ingress只能以HTTP和 HTTPS提供服务，对于使用其他网络协议的服务，可以通过设置Service的类型 type为NodePort或LoadBalancer对集群外部的客户端提供服务。

举例：使用Ingress进行服务路由时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，这样会跳过kube-proxy设置的路由转发规则，以提高网络转发效率，下图是一个典型的HTTP层路由的例子：

其中:

对http:/mywebsite.com/api的访问将被路由到后端名为api的Service上；
对http:/mywebsite.com/web的访问将被路由到后端名为web的Service上；
对http:/mywebsite.com/docs的访问将被路由到后端名为docs的Service上。

主要流程：部署ingress controller -> 创建ingress策略 -> 客户端通过ingress controller访问后端web-app服务。

关系图大致如下：（图片来自：https://www.cnblogs.com/rancherlabs/p/12034075.html）

03 疑问

如果还是对service的一些概念不清晰，比如：kube-proxy与ingress的关系，可以参考阅读：《Using a Network Load Balancer (NLB) to Expose an Application Outside the Kubernetes Cluster》。

暴露k8s的服务的三种方式：

NodePort
Network Load Balancer (NLB)
Ingress (application load balancer, ALB)

原理图如下，以便于理解：

04 文末

本文主要总结k8s关于Service的一些学习笔记，以便后续的回顾，谢谢大家的阅读，本文完！

k8s教程（service篇）-总结（下）

2.2.6.2 LoadBalancer类型

2.2.6.3 ExternalName类型

2.2.7 Service支持的网络协议

2.2.8 k8s的服务发现机制

2.2.8.1 环境变量的方式

2.2.8.2 DNS的方式

2.2.9 headless service

2.2.9.1 已设置Label Selector

2.2.9.2 未设置Label Selector

2.2.10 端点分片和服务拓扑

2.2.10.1 端点分片

2.2.10.2 服务拓扑

2.3 dns服务搭建和配置

2.3.1 dns在k8s服务的发展

2.3.2 coredns搭建

2.3.3 配置解析

2.3.4 举例（自定义域名）

2.4 node本地dns缓存

2.5 pod的dns域名

2.6 ingress 7层路由机制

03 疑问

04 文末

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

k8s教程（service篇）-总结（下）

2.2.6.2 LoadBalancer类型

2.2.6.3 ExternalName类型

2.2.7 Service支持的网络协议

2.2.8 k8s的服务发现机制

2.2.8.1 环境变量的方式

2.2.8.2 DNS的方式

2.2.9 headless service

2.2.9.1 已设置Label Selector

2.2.9.2 未设置Label Selector

2.2.10 端点分片和服务拓扑

2.2.10.1 端点分片

2.2.10.2 服务拓扑

2.3 dns服务搭建和配置

2.3.1 dns在k8s服务的发展

2.3.2 coredns搭建

2.3.3 配置解析

2.3.4 举例（自定义域名）

2.4 node本地dns缓存

2.5 pod的dns域名

2.6 ingress 7层路由机制

03 疑问

04 文末

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像