定义

最佳路径

云原生是一条使用户能低心智负担的、敏捷的、以可扩展、可复制的方式，最大化地利用云的能力，发挥云的价值的最佳路径

愿景

软件从诞生就生在云上、长在云上，全新的软件开发、发布和运维模式

技术范畴

云原生架构

Cloud Native App

Applications adopting the principles of Microservices packaged as Containers orchestracted by Platforms running on top of Cloud infrastructure, developed using practices such as Continous Delivery and DevOps.

云演进史

命令式 vs 声明式

命令式

1
2

# kubectl create -f nginx.yaml
# kubectl replace -f nginx.yaml

声明式

1

# kubectl apply -f nginx.yaml

1. 所谓声明式，即只需要提交一个定义好的API对象来声明所期待的状态即可
2. 声明式API允许多个API写端，以PATCH的方式对API对象进行修改，而无需关心本地原始YAML文件的内容
   • 声明式API最主要的能力：PATCH API
3. 声明式API是Kubernetes编排能力赖以生存的核心所在

本质区别

Kubernetes编程范式

使用控制器模式，与Kubernetes里API对象的『增、删、改、查』进行协作，进而完成用户业务逻辑的编写

编排对象

1. 在线业务：Deployment、StatefulSet、DaemonSet
2. 离线业务：Job、CronJob

Job

job.yaml

1. Job对象不需要定义spec.selector（借助UUID）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
        - name: pi
          image: resouer/ubuntu-bc
          command:
            - sh
            - '-c'
            - "echo 'scale=10000; 4*a(1)' | bc -l"
      restartPolicy: Never
  backoffLimit: 4

Daemon Pod

特征

1. 运行在Kubernetes集群的每个Node上
2. 每个Node有且仅有一个Daemon Pod
3. 新Node加入Kubernetes集群，Daemon Pod会自动在新Node上被创建
4. 旧Node被删除后，上面的Daemon Pod也会被回收

场景

1. 网络插件的Agent组件
2. 存储插件的Agent组件
3. 监控组件 + 日志组件

工作原理

1. 循环控制：遍历所有Node，根据Node上是否有被管理Pod的情况，来决定是否需要创建或者删除Pod
2. DaemonSet在创建每个Pod时，做了两件额外的事情
   • 自动给这个Pod加上一个nodeAffinity，来保证该Pod只会在指定节点上启动
   • 自动给这个Pod加上一个Toleration，从而忽略Node上的unschedulable污点

背景

1. Deployment的短板：Deployment认为一个应用的所有Pod，是完全一样的
2. 有状态应用（Stateful Application）
   • 实例之间有不对等的关系 – 拓扑
   • 实例对外部数据有依赖关系 – 存储
3. StatefulSet
   • Kubernetes在Deployment的基础上，扩展出对有状态应用的初步支持
   • StatefulSet是Kubernetes在作业编排的集大成者

状态抽象

1. 分类
   • 拓扑状态：应用的多个实例之间是不完全对等的关系
   • 存储状态：应用的多个实例分别绑定了不同的存储数据
2. 核心功能：通过某种方式记录状态，然后在Pod被重新创建时，能够为新Pod恢复这些状态

设计思想

1. StatefulSet是一种特殊的Deployment，独特之处：为每个Pod编号（代表创建顺序、网络标识等）
2. 编号 + Headless Service ==> 拓扑状态
3. 编号 + Headless Service + PV/PVC ==> 存储状态

基本概念

1. Deployment实现了Pod的水平伸缩（horizontal scaling out/in） – 滚动更新（rolling update）
2. 滚动更新依赖于ReplicaSet
3. Deployment控制ReplicaSet（版本），ReplicaSet控制Pod（副本数）！！

ReplicaSet

1. ReplicaSet的定义是Deployment的一个子集
2. Deployment控制器实际操纵对象是ReplicaSet，而非Pod，Deployment所管理的Pod的ownerReference为ReplicaSet

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-set
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: 'nginx:1.7.9'

控制器

kube-controller-manager是一系列控制器的集合，每一种控制器都以独有的方式负责某种编排功能

1
2
3
4
5
6
7

# cd kubernetes/pkg/controller

# ls -d */
apis/                   cronjob/                endpoint/               history/                nodelifecycle/          replication/            storageversiongc/       util/
bootstrap/              daemon/                 endpointslice/          job/                    podautoscaler/          resourcequota/          testutil/               volume/
certificates/           deployment/             endpointslicemirroring/ namespace/              podgc/                  serviceaccount/         ttl/
clusterroleaggregation/ disruption/             garbagecollector/       nodeipam/               replicaset/             statefulset/            ttlafterfinished/

控制循环

1. X为待编排的对象，实际状态来源于Kubernetes集群，而期望状态一般来自于用户提交的YAML文件
2. 别名：Reconcile、Reconcile Loop、Sync Loop、Control Loop
3. 控制器对象本身，负责定义被管理对象的期望状态！！
   • 被控制对象的定义，来源于模板，如Deployment.template与标准的Pod对象的API定义一致，称为PodTemplate

1
2
3
4
5
6
7
8
9

for {
  实际状态 := 获取集群中对象 X 的实际状态（Actual State）
  期望状态 := 获取集群中对象 X 的期望状态（Desired State）
  if 实际状态 == 期望状态{
    什么都不做
  } else {
    执行编排动作，将实际状态调整为期望状态
  }
}

基本概念

1. 在Kubernetes中，Pod是一等公民
2. Pod是Kubernetes的原子调度单位，Kubernetes统一按照Pod（而非容器）的资源需求进行计算
3. 容器的本质是进程
4. 容器的单进程模型
   • 并不是指容器里只能运行一个进程，而是指容器没有管理多个进程的能力
   • 原因
     • 容器里PID=1的进程是应用本身，其它进程都是PID=1进程的子进程
     • 用户编写的应用，并不能像正常OS里面的init进程或者systemd进程那样拥有进程管理的功能
5. 容器间具有『超亲密关系』的典型特征
   • 互相之间会发生直接的文件交换
   • 使用localhost或者Socket文件进行本地通信
   • 会发生非常频繁的远程调用
   • 需要共享某些Linux Namespace
6. 并不是所有有关系的容器都属于同一个Pod，如Java应用容器和MySQL更适合做成两个Pod
7. Pod在Kubernetes中的重要意义 – 容器设计模式