• Pod可基于Service的DNS名称向其发起服务访问请求

http://www.magedu.com

Pod上的DNS解析策略

 Kubernetes支持在单个Pod资源规范上自定义DNS解析策略和配置，并组合生效

• ⚫ spec.dnsPolicy：解析策略

⚫ spec.dnsConfig：名称解析机制

• DNS解析策略

  • ⚫ Default：从运行在的节点继承DNS名称解析相关的配置

• ⚫ ClusterFirst：于集群DNS服务上解析集群域内的名称，其他域名的解析则交由从节点继承而来的上游名称服务器

• ⚫ ClusterFirstWithHostNet：专用于在设置了hostNetwork的Pod对象上使用的ClusterFirst策略

⚫ None：用于忽略Kubernetes集群的默认设定，而仅使用由dnsConfig自定义的配置

• DNS解析机制

• ⚫ nameservers <[]string>：DNS名称服务器列表，附加于由dnsPolicy生成的DNS名称服务器之后

• ⚫ searches <[]string>：DNS名称解析时的搜索域，附加由于dnsPolicy生成的搜索域之后

• ⚫ options <[]Object>：DNS解析选项列表，同dnsPolicy生成的解析选项合并成最终生效的定义

http://www.magedu.com

Headless Service

• Service的各类型中，ClusterIP、NodePort和LoadBalancer都为其Service配置一个ClusterIP，CoreDNS上，这些 Service对象的A记录也解析为它的ClusterIP；

• 广义上，那些没有ClusterIP的Service则称为Headless Service，它们又可以为分两种情形

  • ⚫ 有标签选择器，或者没有标签选择器，但有着与Service对象同名的Endpoint资源

    • Service的DNS名称直接解析为后端各就绪状态的Pod的IP地址

• 调度功能也将由DNS完成

• 各Pod IP相关PTR记录将解析至Pod自身的名称，假设Pod IP为a.b.c.d，则其名称为a-b-c-d...svc.

• 这种类型也就是狭义上的Headless Service

• ⚫ 无标签选择器且也没有与Service对象同名的Endpoint资源

◆

• Service的DNS名称将会生成一条CNAME记录，对应值由Service对象上的spec.externalName字段指定

http://www.magedu.com

示例

 Headless Service示例

 External Service示例

kind: Service apiVersion: v1 metadata: name: externalname-mageedu spec: type: ExternalName externalName: www.magedu.com ports: - protocol: TCP port: 80 targetPort: 80 selector: {}

kind: Service apiVersion: v1 metadata: name: demoapp-headless-svc spec: clusterIP: None selector: app: demoapp ports: - port: 80 targetPort: 80 name: http

http://www.magedu.com

4 Service流量转发简析

Service流量转发机制

 ClusterIP类型

• ⚫ 源自Pod

  • 没启动masquerade-all：请求报文的目标IP和目标端口由Service转为挑选出的后端Pod的IP和端口，并由后端Pod直接响应给客户端Pod

    • 发夹问题：Pod访问自身所属的Service后，由Service又调度回该Pod

    • 存在发夹问题（haripin）的场景中，需要启用源IP地址转换

• 启用masquerade-all：请求报文的源IP和目标IP都将由Service进行转换，原IP将转为客户端Pod所在节点在Pod网络中的IP地址

• ⚫ 源自非Pod网络中的请求流量

  • 接入流量的节点充当NAT网关，请求报文的源IP和目标IP都将由Service进行转换

• NodePort和LoadBalancer类型

  • ⚫ 流量来自集群外部，节点扮演网关的角色，请求报文的源IP和目标IP都将由Service进行转换，原IP将转为客户端Pod所在节点的IP地址，以确保响应报文能正确送达

http://www.magedu.com

Service流量转发机制（2）

• 流量转发示意图：请求报文，目标地址转换都会进行，未启用masquerade-all时，源地址转换将视情况进行 ⚫ Pod网络是虚拟网络，最终还是要通过节点网络完成报文传送，因此，SNAT通常会使用节点网络中的地址

http://www.magedu.com

应用编排

 讲师：马永亮（马哥）  http://www.magedu.com  https://github.com/ikubernetes/

本节大纲

• 控制器模式

  • 声明式API和控制器模式

◼ Kubernetes上常用的工作负载裁型控制器

• Deployment控制器及资源

  • Deployment控制器简介

  • ReplicaSet和Deployment资源规范

  • 更新策略

◼ 扩容和缩容

• DaemonSet控制器及资源

• DaemonSet控制器的应用编排特性

• 资源规范及更新策略

• Job和CronJob控制器、资源 ◼ Job及CronJob的应用编排机制

  • Job及并行式Job

  • CronJob及用法

http://www.magedu.com

1 Kubernetes控制器模式

声明式API

 API设计方法

• 命令式API

  • 也称为指令式API，用户需要一步步地告诉机器该如何做（How），机器自身不具有任何“智能”，只被动接受指令

  • ◆ 高度依赖用户自身理解和达成目标的能力和处理各类异常问题的经验，实现的是“命令式编程（Imperative Programming）”

• 声明式API

  • 也称为申明式API，用户只需要告诉机器想要的结果（What），机器自身需要确定如何达成该目标

  • ◆ 机器需要一定的“智能”，但通常只能支持事先预设和可被其理解的特定任务

  • 实现的是“声明式编程（Declarative Programming）”

Programming
Declarative Imperative
Logic Functional Object-oriented Procedural

http://www.magedu.com

声明式API和控制器模式

• 相较于命令式编程，声明式编程是一个更高的层次上的编程

  • 声明式API允许用户以给出最终期望目标的方式编写代码，但具体的执行过程（即机器智能的那部分代码），最终仍然需要以命令式编程实现，只不过，它们可由不同的人群完成

  • ◼ 类比来说，声明式编程的用户类似于企业的高管，只用关心和交待最终目标；而命令式编程的用户类似于企业部门经理，他需要理解目标的达成路径，并组织人力完成目标

• Kubernetes的声明式API

  • 用户能够以声明式定义资源对象的目标状态（spec）

  • 由控制器代码（机器智能组件）负责确保实际状态（status）与期望状态一致

    • 控制器即“部门经理”，负责确保部门内的各项具体任务得以落地

• 控制器通常由API的提供者负责编写

• 用户需要做的是根据资源类型及其控制器提供的DSL进行声明式编程

http://www.magedu.com

声明式API和控制器模式（2）

• 控制器模型（控制回路）

  • 初始，Controller负责根据Input（目标状态）控制System，并生成Output（结果状态）

  • Feedback根据Output生成Feedback Signal，而后由Error Detector基于Feedback Signal和Input来判定是否存在错误，并在有错误时生成Error Signal

  • Error Signal将驱动Controller生成Actuating Signal，并控制 System的行为与Input要求相同

• Kubernetes Controller的控制回路

  • Controller根据spec，控制System生成Status

  • Controller借助于Sensor持续监视System的Spec和Status，在每一次控制回路中都会对二者进行比较，并确保System的 Status不断逼近或完全等同Status

http://www.magedu.com

Kubernetes的控制器

 Kubernetes的控制器类型

• 打包于Controller Manager中内置提供的控制器，例如Service Controller、Deployment Controller等

  • 基础型、核心型控制器

  • 打包运行于kube-controller-manager中

• 插件或第三方应用的专用控制器，例如Ingress插件ingress-nginx的Controller，网络插件Project Calico的 Controller等

  • 高级控制器，通常需要借助于基础型控制器完成其功能

  • 以Pod形式托管运行于Kubernetes之上，而且这些Pod很可能会由内置的控制器所控制

• 以编排Pod化运行的应用为核心的控制器，通常被统称为工作负载型控制器

  • 无状态应用编排：ReplicaSet、Deployment

  • 有状态应用编排：StatefulSet、第三方专用的Operator

  • 系统级应用：DaemonSet

  • 作业类应用：Job和CronJob

http://www.magedu.com

应用编排

• 定义工作负载型控制器资源对象以编排应用

  • 内置的各工作负载型控制器都有对应的资源类型，控制器专用于管控其对应类型的资源对象

    • 例如，Deployment控制器对应有Deployment资源类型

    • 这些资源类型都是Kubernetes上标准的API资源，并遵循资源规范的通用格式

  • 用户需要编排某应用时，需要事先确认好应用的运行目标模式，例如实例数据及结束条件等，并根据模式选出对应的工作负载控制器类型

  • 而后根据相应控制器的资源类型的规范，编写资源配置，并提交给API Server即可

  • 相应控制器监视到API Server上新建的资源后，即会运行代码确保对象实例的实际状态（Status）与期望状态 （Spec）一致

• 注意：控制器对象仅负责确保API Server上有相应数量的符合标签选择器的Pod对象的定义，至于Pod 对象的Status如何与Spec保持一致，则要由相应节点上的kubelet负责保证

http://www.magedu.com

2 Deployment资源及控制器

Deployment控制器简介

• 负责编排无状态应用的基础控制器是ReplicaSet，相应的资源类型通过三个关键组件定义如何编排一个无状态应用

  • replicas：期望运行的Pod副本数

  • selector：标签选择器

  • podTemplate：Pod模板

• Deployment是建立在ReplicaSet控制器上层的更高级的控制器

  • 借助于ReplicaSet完成无状态应用的基本编排任务

  • 它位于ReplicaSet更上面一层，基于ReplicaSet提供了滚动更新 、 回滚等更为强大的应用编排功能

  • 是ReplicaSet资源的编排工具

    • Deployment编排ReplicaSet

    • ReplicaSet编排Pod

  • 但是，应该直接定义Deployment资源来编排Pod应用，ReplicaSet无须显式给出

http://www.magedu.com

ReplicaSet和Deployment资源规范

 ReplicaSet资源示例

apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-example spec: replicas: 2 selector: matchLabels: app: demoapp release: stable template: metadata: labels: app: demoapp release: stable 各Pod的名字以ReplicaSet名称为前缀，后缀随机生成 spec: containers: - name: demoapp image: ikubernetes/demoapp:v1.0

 Deployment资源示例

apiVersion: apps/v1 kind: Deployment metadata: name: deploy-example spec: replicas: 2 selector: matchLabels: app: demoapp release: stable template: ReplicaSet对象名称以 metadata: Deployment名称为前缀，后 labels: 缀是Pod模板的hash码 app: demoapp release: stable spec: 各Pod的名字以Deployment containers: 名称为前缀，中间是Pod模板的hash码，后缀随机生成 - name: demoapp image: ikubernetes/demoapp:v1.0

http://www.magedu.com

获取资源状态

 获取ReplicaSet资源对象的状态

~$ kubectl get replicasets/rs-example NAME DESIRED CURRENT READY AGE rs-example 2 2 2 115s

DESIRED：期望的Pod数量 CURRENT：当前的Pod数量 READY：就绪状态的Pod数量 AGE：当前资源的创建后生存时长

 获取Deployment资源对象的状态

~$ kubectl get deployment/deploy-example NAME READY UP-TO-DATE AVAILABLE AGE deploy-example 2/2 2 2 27s ⚫ Deployment自动创建的ReplicaSet被添加等同于Pod对象的标签 ~$ kubectl get replicasets -l app=demoapp,release=stable NAME DESIRED CURRENT READY AGE

READY：就绪的Pod数量/期望的Pod数量 UP-TO-DATE：到达期望的版本的Pod数量 AVAILABE：运行中并可用的Pod数量 AGE：当前资源的创建后生存时长

deploy-example-66db74fcfc 2 2 2 6m

http://www.magedu.com

更新策略

• Deployment控制器支持两种更新策略

  • 滚动式更新（rolling updates）

◆ 逐批次更新Pod的方式，支持按百分比或具体的数量定义批次规模，默认策略

• 触发条件：podTemplate的hash码变动

⚫ 仅podTemplate的配置变动才会导致hash码改变

• ⚫ replicas和selector的变更不会导致podTemplate的hash变动

• ◼ 重建式更新（recreate）

◆ 在Pod资源被删除时，使用新的模板定义被足缺失的Pod数量，完成更新

strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate

◆ 触发条件：现有Pod被删除

http://www.magedu.com

触发更新

• 触发滚动更新

  • 最为常见的更新需求是应用升级，即镜像文件更新，常用方法

    • ~$ kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ...

    • ~$ kubectl patch (-f FILENAME | TYPE NAME) [-p PATCH|--patch-file FILE] [options]

    • 直接更新原配置文件，而后使用“kubectl apply”命令触发更新

  • 上面第二和第三种方法可用于模板中任何必要配置的更新

• 查看更新

  • 更新状态：kubectl rollout status (TYPE NAME | TYPE/NAME) [flags] [options]

  • 更新历史：kubectl rollout history (TYPE NAME | TYPE/NAME) [flags] [options]

• 回滚

  • 回滚到前一版本：kubectl rollout undo (TYPE NAME | TYPE/NAME)

  • 回滚到指定版本：kubectl rollout undo (TYPE NAME | TYPE/NAME) --to-revision=X

http://www.magedu.com

配置滚动更新策略

• Deployment的滚动更新支持使用如下两个字段来配置相关的策略

  • maxSurge：指定升级期间存在的总Pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是相对于期望值的一个百分比

  • maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望值的个数，其值可以是0或正整数，也可以是相对于期望值的一个百分比，默认值为1

• 存在的问题：必须以Pod为原子单位切割规模比例，且无法控制流量路由比例；

http://www.magedu.com

扩容和缩容

 容量管理类型

◼ 横向伸缩：增加或减少Pod数量

◼ 纵向（垂直）伸缩：调整Pod上的资源需求和资源限制

 变动Deployment资源对象中的replicas字段的值即会触发应用规模的扩容或缩容 ◼ 扩容和缩容是ReplicaSet的功能，具体操作由ReplicaSet完成 ◼ 根据应用规模的需要进行手动配置

 操作方法

◼ patch命令

◆ kubectl patch (-f FILENAME | TYPE NAME) [-p PATCH|--patch-file FILE] [options]

◆ 例如：kubectl patch deployment deploy-example -p '{"spec":{"replicas":3}}'

◼ 直接更新原配置文件，而后使用“kubectl apply”命令触发更新

 扩展：自动扩容和缩容

◼ HPA（Horizontal Pod Autoscaler）控制器

◼ VPA（Vertical Pod Autoscaler）控制器

http://www.magedu.com

3 DaemonSet

DaemonSet的应用编排机制

• 使用DaemonSet编排应用

  • 同Deployment相似，DaemonSet基于标签选择器管控一组Pod副本；

  • 但是，DaemonSet用于确保所有或选定的工作节点上都运行有一个Pod副本

    • 提示：DaemonSet的根本目标在于让每个节点一个Pod

    • 有符合条件的新节点进入时，DaemonSet会将Pod自动添加至相应节点；而节点的移出，相应的Pod副本也将被回收；

• 常用场景

  • 特定类型的系统化应用，例如kube-proxy，以及Calico 网络插件的节点代理calico-node等

  • 集群存储守护进程、集群日志收集守护进程以及节点监控守护进程等

图源：https://medium.com/

http://www.magedu.com

apiVersion: apps/v1

DaemonSet的资源规范

 与Deployment相似，DaemonSet对象也使用标签选择器和Pod模板，区别之处在于，DaemonSet不需要定义replicas（Pod副本数量），其Pod数量随节点数量而定；

apiVersion: apps/v1 kind: DaemonSet metadata: name: daemonset-demo namespace: default spec: selector: matchLabels: app: prometheus component: node-exporter template: metadata: name: prometheus-node-exporter labels: app: prometheus component: node-exporter spec: containers: - image: prom/node-exporter:v1.2.0 name: prometheus-node-exporter ports:

apiVersion: apps/v1 # API群组及版本； kind: DaemonSet # 资源类型特有标识； metadata:

name # 资源名称，在作用域中要惟一； namespace # 名称空间；DaemonSet资源隶属名称空间级别； spec: minReadySeconds # Pod就绪后多少秒内任一容器无crash方可视为“就绪”； selector