kubernetes文档知识点个人总结

Published on with 0 views and 0 comments

  

只是整理知识点,所有内容来自 http://docs.kubernetes.org.cn/251.html,如有侵权请发送邮件通知删除

架构

  图片.png

  K8s 主要组件

1etcd: 保存集群状态
2apiserver: 所有资源操作入口,认证授权,访问控制,API注册,服务发现
3controller-manager: 维护集群状态,故障检测,自动扩展,滚动更新
4scheduler: 资源调度
5kubelet: 维护容器的生命周期,CVI和CNI管理
6cri: 镜像管理和pod运行
7kube-proxy: 为Service提供cluster服务发现和负载均衡

  K8s addons

1kube-dns: 集群dns服务,多用cni
2IngressController: 外网入口
3Heapster: 资源监控
4Dashboard: GUI
5Federation: 跨区用集群
6Fluentd-elasticsearch: 日志采集存储查询

  图片.png

分层架构

  图片.png

  • 核心层:Kubernetes 最核心的功能,对外提供 API 构建高层的应用,对内提供插件式应用执行环境
  • 应用层:部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS 解析等)
  • 管理层:系统度量(如基础设施、容器和网络的度量),自动化(如自动扩展、动态 Provision 等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy 等)
  • 接口层:kubectl 命令行工具、客户端 SDK 以及集群联邦
  • 生态系统:在接口层之上的庞大容器集群管理调度的生态系统,可以划分为两个范畴
    • Kubernetes 外部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等
    • Kubernetes 内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

基础概念

  Pod: K8S 集群中 运行部署应用或服务的最小单元,支持很多容器。多个容器在一个 Pod 中共享网络地址和文件系统,可以通过进程间通信和文件共享方式组合完成服务。

  Pod:负责不同场景的应用服务:Long-Running,Batch,Node-daemon,Stateful application,对应控制器为 Deployment,Job,DaemonSet 和 PetSet

  Replication Controller(RC): 复制控制器,CURD POD 的一个 API 对象

  Replication Set(RS): 新的 RC

  Deployment: 部署 表述用户对 K8S 一次更新操作:创建新服务,更新服务,滚动升级,实际操作是创建 RS,然后使用 RS 渐进创建新的 POD 删除老的 POD 直到达到 命令行参数配置的指标

  Service: 服务,RC,RS 和 Deployment 保证 POD 数量,如果通过 ip 端口方式访问 POD,可能你在访问时,这个 POD 被删除迁移到另一个节点上就会出现错误,客户端访问需要的服务就是 Service 对象,每个 Service 对应一个集群内部有效的虚拟 IP,集群内通过虚拟 IP 访问服务。

  Job: 任务,控制 Batch 任务的 API 对象,这种任务通常是有头有尾,Job 管理的 Pod 根据用户设置完成任务后退出

  • .spec.completions: 指定 job 需要成功运行 Pods 的次数。默认值: 1
  • .spec.parallelism: 指定 job 在任一时刻应该并发运行 Pods 的数量。默认值: 1
  • .spec.activeDeadlineSeconds: 指定 job 可运行的时间期限,超过时间还未结束,系统将会尝试进行终止。
  • .spec.backoffLimit: 指定 job 失败后进行重试的次数。默认是 6 次,每次失败后重试会有延迟时间,该时间是指数级增长,最长时间是 6min。

  DaemonSet: 后台支撑服务集合,长期伺服型服务,只有开始然后等用户手动结束,要保证各每个节点都以一个此类型的服务在运行

  PetSet: 有状态服务集合,比如 DB

  Federation: 集群联邦 跨区主机,跨云主机分布式集群

  Volume: 存储卷,生命周期和作用范围是一个 POD

  PV: Persistent Volume,PV 持久存储卷,Persistent Volume Claim PVC 持久卷声明,PV 提供资源,PVC 和 POD 使用 PV

  Node: 节点 Mesos 和 Slave,Master 和 Node

  Secret: 密钥对象,保存和传递密码认证凭证 ssl 证书等

  Namespace: 命名空间,虚拟隔离

  RBAC: 用户角色权限

组件

Master

  kube-apiserver

  kube-controller-manager

  kube-scheduler

Node

  kubelet

  kube-proxy

对象

  Kubernetes 对象是持久实体类,用这些实体类来表示集群的状态,比如

  • 容器化应用正在运行在哪些节点上
  • 应用可用资源
  • 应用运行策略,升级策略,容错策略

  对象的规范和状态

  每个 Kubernetes 对象包含两个嵌套字段用于管理 Object 的配置:Object Spec 和 Object Status

  Sepc 表示对象所需的状态,希望对象具有的特性,Status 描述对象的实际状态由 K8S 提供和更新

  Demo:

 1apiVersion: apps/v1beta1
 2kind: Deployment
 3metadata:
 4  name: nginx-deployment
 5spec:
 6  replicas: 3
 7  template:
 8    metadata:
 9      labels:
10        app: nginx
11    spec:
12      containers:
13      - name: nginx
14        image: nginx:1.7.9
15        ports:
16        - containerPort: 80

  Object.kind = Deployment 部署类型的对象

  Object.metadata.name = nginx-deployment 名称

  Object.spec.replicas = 三个应用实例

  ......

  使用 kubectl create 命令创建这个 描述对象

1kubectl create -f docs/user-guide/nginx-deployment.yaml --record

Name

  Kubernetes REST API 中的所有对象都用 Name 和 UID 来明确标识

  Name 在一个对象中同一时间只能拥有单个 Name,如果对象被删除,也可以使用相同 Name 创建新的对象,Name 用于在资源引用 URL 中的对象,例如 /api/v1/pods/some-name。通常情况,Kubernetes 资源的 Name 能有最长到 253 个字符(包括数字字符、-.),但某些资源可能有更具体的限制条件,具体情况可以参考:标识符设计文档

Namespaces

  namespace 将一个集群提供不同的分组

1# 创建一个namespace
2kubectl create namespace spaceName 
3# 通过配置文件
4apiVersion: v1
5kind: Namespace
6metadata:
7  name: new-namespace
8
9kubectl create -f config.yml  
1kubectl delete namespaces new-namespace :删除一个命名空间,删除时会删除所有属于该命名空间的资源
2default 和 kube-system 命名空间无法删除
1kubectl get namespaces 查看命名空间
临时设置Request的Namespace: 
kubectl --namespace= run nginx --image=nginx
kubectl --namespace= get pods
1# 永久保存命名空间
2 kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>

  大多数 Kubernetes 资源(例如 pod、services、replication controllers 或其他)都在某些 Namespace 中,但 Namespace 资源本身并不在 Namespace 中。而低级别资源(如 Node 和 persistentVolumes)不在任何 Namespace 中。Events 是一个例外:它们可能有也可能没有 Namespace,具体取决于 Events 的对象。

Namespace 配额

  通过 ResourceQuota 对象配置 Namespace 配额

 1# 创建一个命名空间
 2kubectl create namespace quota-pod-example
 3
 4# ResourceQuota对象描述yaml
 5apiVersion: v1
 6kind: ResourceQuota
 7metadata:
 8  name: pod-demo
 9spec:
10  hard:
11    pods: "2"
12
13# 通过yaml在quota-pod-example namespace下创建一个 ResourceQuota 对象
14kubectl create -f quota-pod.yaml --namespace=quota-pod-example
15
16# 查看 resourcequota 对象的详细信息
17kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml
18
19# 状态 spec 期望 status 实际值由controller管理更新,未使用pods数量2个,已使用pods数量0个
20spec:
21  hard:
22    pods: "2"
23status:
24  hard:
25    pods: "2"
26  used:
27    pods: "0"
28
29# Deployment 对象,一次部署任务,期望创建3个pod
30apiVersion: apps/v1beta1
31kind: Deployment
32metadata:
33  name: pod-quota-demo
34spec:
35  replicas: 3
36  template:
37    metadata:
38      labels:
39        purpose: quota-demo
40    spec:
41      containers:
42      - name: pod-quota-demo
43        image: nginx
44
45# 在 quota-pod-example namespace 下 使用 deployment yaml 创建一个部署任务
46kubectl create -f quota-pod-deployment.yaml --namespace=quota-pod-example
47
48# 查看Deployment对象信息
49kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
50
51
52
53# 期望时3个,但是因为ResourceQuota对Namespace做出了限制,所以只有两个Pod
54spec:
55  ...
56  replicas: 3
57...
58status:
59  availableReplicas: 2
60...
61lastUpdateTime: 2017-07-07T20:57:05Z
62    message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
63      exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'

内存和 CUP 请求 限 额

  对象类型为 LimitRange

 1apiVersion: v1
 2kind: LimitRange
 3metadata:
 4  name: mem-limit-range
 5spec:
 6  limits:
 7  # 默认内存限额为 512M
 8  - default:
 9      memory: 512Mi
10 # 最大内存限额为 1G
11    max:
12      memory: 1Gi
13 # 最小内存限额为 500M
14    min:
15      memory: 500Mi
16  # 默认请求限额为 256M
17    defaultRequest:
18      memory: 256Mi
19    type: Container

  应用最小和最大内存限制

  LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。

  最小和最大内存限制的动因

  作为一个集群管理员,您可能希望为 Pod 能够使用的内存数量施加限制。例如:

  • 集群中每个节点拥有 2 GB 内存。您不希望任何 Pod 请求超过 2 GB 的内存,因为集群中没有节点能支持这个请求。
  • 集群被生产部门和开发部门共享。 您希望生产负载最多使用 8 GB 的内存而将开发负载限制为 512 MB。这种情况下,您可以为生产环境和开发环境创建单独的 namespace,并对每个 namespace 应用内存限制。

内存和 CPU 请求配额

  request: 容器使用的最小资源需求, 作为容器调度时资源分配的判断依赖。
limit: 容器能使用资源的最大值

  request 能保证 pod 有足够的资源来运行, 而 limit 则是防止某个 pod 无限制的使用资源, 导致其他 pod 崩溃。 两者的关系必须满足:

10 <= request <= limit
 1apiVersion: v1
 2// ResourceQuoa对象
 3kind: ResourceQuota
 4metadata:
 5  name: mem-cpu-demo
 6spec:
 7  hard:
 8   // 所有容器CPU请求总额 不超过1G
 9    requests.cpu: "1"
10   // 所有容器内存请求总额 不超过1G
11    requests.memory: 1Gi
12   // 所有容器CPU请求限额总额不能超过2G
13    limits.cpu: "2"
14   // 所有容器内存请求限额总额不能超过2G
15    limits.memory: 2Gi
 1apiVersion: v1
 2// Pod对象
 3kind: Pod
 4metadata:
 5  name: quota-mem-cpu-demo
 6spec:
 7  containers:
 8  - name: quota-mem-cpu-demo-ctr
 9    image: nginx
10    resources:
11      limits:
12        //内存总额 800MB
13        memory: "800Mi"
14        // CPU总额 800MB
15        cpu: "800m" 
16      requests:
17        // 内存请求限额总额600MB
18        memory: "600Mi"
19        // CPU请求限额总额
20        cpu: "400m"
 1apiVersion: v1
 2 // 第二个POD
 3kind: Pod
 4metadata:
 5  name: quota-mem-cpu-demo-2
 6spec:
 7  containers:
 8  - name: quota-mem-cpu-demo-2-ctr
 9    image: redis
10    resources:
11      limits:
12        memory: "1Gi"
13        cpu: "800m"  
14      requests:
15        memory: "700Mi"
16        cpu: "400m"

  当创建第二个 POD 时 发现当前 Namespace 配额的内存和 CPU 都不够用了,抛出了异常

1Error from server (Forbidden): error when creating "docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml":
2pods "quota-mem-cpu-demo-2" is forbidden: exceeded quota: mem-cpu-demo,
3requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.memory=1Gi

Label 和 Selectors

  Labels 就是 键值对集合 筛选对象用
单个对象中 Label 唯一,但多个对象中 Label 不唯一

List & Watch

  LIST 和 WATCH 操作可以指定标签选择器来过滤使用查询参数返回的对象集。

1# 根据 environment 和environmentde值筛选POD
2kubectl get pods -l environment=production,tier=frontend
3kubectl get pods -l 'environment in (production),tier in (frontend)'
4kubectl get pods -l 'environment in (production, qa)'
5kubectl get pods -l 'environment,environment notin (frontend)'

Volume

  硬盘挂载,有云方式和各种不同的方式,具体可以参见 http://docs.kubernetes.org.cn/429.html#hostPath

emptyDir

  Node 上的 Pod 一直运行,Volume 就会一直存,Pod 删除 Volume 删除

 1apiVersion: v1
 2// Pod对象
 3kind: Pod
 4metadata:
 5  name: test-pd
 6// 期望
 7spec:
 8  containers:
 9  - image: gcr.io/google_containers/test-webserver
10    name: test-container
11   // volume挂载地址 /cache目录
12    volumeMounts:
13    - mountPath: /cache
14   // 名称 cache-volume
15      name: cache-volume
16  // 实际的卷
17  volumes:
18  // 名称
19  - name: cache-volume
20   // 挂载模式
21    emptyDir: {}

hostPath

  hostPath 挂载机器上的文件到 Pod 里

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: test-pd
 5spec:
 6  containers:
 7  - image: gcr.io/google_containers/test-webserver
 8    name: test-container
 9    volumeMounts:
10    - mountPath: /test-pd
11      name: test-volume
12  volumes:
13  - name: test-volume
14    hostPath:
15      path: /data
16

Annotations

  描述,可以应用于检索对象,类似标签

1"annotations": {
2  "key1" : "value1",
3  "key2" : "value2"
4}

Nodes

  集群节点,工作节点

  节点包含的状态信息

  • Address
  • Condition
  • Capacity
  • Info

Address

  • Hostname
  • ExternalIP
  • InternalIP

Condition

  • OutOfDisk
  • Ready
  • MemoryPressure
  • DiskPressure

Capacity

  节点上的可用资源:CPU,内存,可调度最大 pod 数量

info

  节点的基础信息,版本信息等

kubelet Self-Registration of Nodes

  通过 kubelet 向 Master 节点注册自己

  • --api-servers - Location of the apiservers.
  • --kubeconfig - Path to credentials to authenticate itself to the apiserver.
  • --cloud-provider - How to talk to a cloud provider to read metadata about itself.
  • --register-node - Automatically register with the API server.
  • --register-with-taints - Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if register-node is false.
  • --node-ip IP address of the node.
  • --node-labels - Labels to add when registering the node in the cluster.
  • --node-status-update-frequency - Specifies how often kubelet posts node status to master.

Pod

  Pod 是 Kubernetes 创建或部署的最小/最简单的基本单位,一个 Pod 代表集群上正在运行的一个进程。

  一个 Pod 封装一个应用容器(也可以有多个容器),存储资源、一个独立的网络 IP 以及管理控制容器运行方式的策略选项。Pod 代表部署的一个单位:Kubernetes 中单个应用的实例,它可能由单个容器或多个容器共享组成的资源。

安全策略

  Pod 安全策略 是集群级别的资源,它能够控制 Pod 运行的行为,以及它具有访问什么的能力。 PodSecurityPolicy 对象定义了一组条件,指示 Pod 必须按系统所能接受的顺序运行。 它们允许管理员控制如下方面:

  图片.png

demo

  PodSecurityPolicy 对象 YAML 配置文件

 1apiVersion: extensions/v1beta1
 2kind: PodSecurityPolicy
 3metadata:
 4  name: permissive
 5spec:
 6  seLinux:
 7    rule: RunAsAny
 8  supplementalGroups:
 9    rule: RunAsAny
10  runAsUser:
11    rule: RunAsAny
12  fsGroup:
13    rule: RunAsAny
14  hostPorts:
15  - min: 8000
16    max: 8080
17  volumes:
18  - '*'

  创建 PodSecurityPolicy 对象

1kubectl create -f  demo.yaml

  查看所有配置的安全策略

1kubectl get psp

  修改安全策略

1kubectl edit psp permissive

  删除安全策略

1kubectl delete psp permissive

生命周期

pause

  • Pending 挂起
  • Running 运行中
  • Succeeded 成功
  • Failed 失败
  • Unkonw 未知

容器探针

  kubelet 定期对容器进行检测和诊断,执行诊断时 kubelet 调用容器的三种 Handler

  • ExecAction:在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
  • TCPSocketAction:对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开,则诊断被认为是成功的。
  • HTTPGetAction:对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400,则诊断被认为是成功的。

  每次探测都将获得以下三种结果之一:

  • 成功:容器通过了诊断。
  • 失败:容器未通过诊断。
  • 未知:诊断失败,因此不会采取任何行动。

  Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应:

  • livenessProbe:指示容器是否正在运行。如果存活探测失败,则 kubelet 会杀死容器,并且容器将受到其 重启策略 的影响。如果容器不提供存活探针,则默认状态为 Success。
  • readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败,端点控制器将从与 Pod 匹配的所有 Service
    的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针,则默认状态为 Success。

  restartPolicy: Always 或 OnFailure,Never 容器在探测失败时被杀死并重新启动

init 容器

  • Init 容器总是运行到成功完成为止。
  • 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成。

  如果 Pod 的 Init 容器失败,Kubernetes 会不断地重启该 Pod,直到 Init 容器成功为止。然而,如果 Pod 对应的 restartPolicy 为 Never,它不会重新启动。

  demo
创建两个 service myservice 和 mydb

 1kind: Service
 2apiVersion: v1
 3metadata:
 4  name: myservice
 5spec:
 6  ports:
 7    - protocol: TCP
 8      port: 80
 9      targetPort: 9376
10---
11kind: Service
12apiVersion: v1
13metadata:
14  name: mydb
15spec:
16  ports:
17    - protocol: TCP
18      port: 80
19      targetPort: 9377
 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: myapp-pod
 5  labels:
 6    app: myapp
 7spec:
 8  containers:
 9 // 最下面两个init跑完了才跑这个
10  - name: myapp-container
11    image: busybox
12    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
13
14
15 // init容器
16  initContainers:
17  - name: init-myservice
18    image: busybox
19   // 等待myservice
20    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
21  - name: init-mydb
22    image: busybox
23  // 等待mydb
24    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
25

Pod 配置服务质量等级

  当 Kubernetes 创建一个 Pod 时,它就会给这个 Pod 分配一个 QoS 等级:

  • Guaranteed
  • Burstable
  • BestEffort

  QoS 等级为 Guaranteed:

  • Pod 里的每个容器都必须有内存限制和请求,而且必须是一样的。
  • Pod 里的每个容器都必须有 CPU 限制和请求,而且必须是一样的。

  QoS 等级为 Burstable :

  • 该 Pod 不满足 QoS 等级 Guaranteed 的要求。
  • Pod 里至少有一个容器有内存或者 CPU 请求。

  Pod BestEffort 等级, Pod 里的容器必须没有任何内存或者 CPU 的限制或请求。

  QOS 对象 Kind name : Pod

优先级和抢占

  为了启用该功能,需要在 API server 和 scheduler 的启动参数中设置

1--feature-gates=PodPriority=true

  在 API server 中还需要设置如下启动参数:

1--runtime-config=scheduling.k8s.io/v1alpha1=true

  kind PriorityClass 优先级,通过 value 指定,数值越大优先级越高

1apiVersion: v1
2kind: PriorityClass
3metadata:
4  name: high-priority
5value: 1000000
6globalDefault: false
7description: "This priority class should be used for XYZ service pods only."

  Pod 生成后进入等待队列等待进行调度,如果没有一个节点能满足 Pod 的要求,那么会清除优先级较低的然后把 Pod 调度到那个节点上运行

PodPreset 将信息注入 Pods

  将额外的运行时需求信息注入 pod。 使用标签选择器(label selector)来指定 Pod Preset 所适用的 pod。

  正常 Pod YAML

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: website
 5  labels:
 6    app: website
 7   // 标签role = frontend
 8    role: frontend
 9spec:
10  containers:
11    - name: website
12      image: ecorp/website
13      ports:
14        - containerPort: 80

  Pod Preset

 1kind: PodPreset
 2apiVersion: settings.k8s.io/v1alpha1
 3metadata:
 4  name: allow-database
 5  namespace: myns
 6spec:
 7  selector:
 8// 根据标签来选择准入POD
 9    matchLabels:
10      role: frontend
11  env:
12    - name: DB_PORT
13      value: "6379"
14  volumeMounts:
15    - mountPath: /cache
16      name: cache-volume
17  volumes:
18    - name: cache-volume
19      emptyDir: {}
20

  两者组合

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: website
 5  labels:
 6    app: website
 7    role: frontend
 8  annotations:
 9    podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
10spec:
11  containers:
12    - name: website
13      image: ecorp/website
14      volumeMounts:
15        - mountPath: /cache
16          name: cache-volume
17      ports:
18        - containerPort: 80
19      env:
20        - name: DB_PORT
21          value: "6379"
22  volumes:
23    - name: cache-volume
24      emptyDir: {}

  另有 ConfigMap 配置方法,多 PodPreset 配置方法
Pod Preset 与原 Pod 存在冲突时,Pod spec 不会被修改。

RS

  ReplicaSet(RS)是 Replication Controller(RC)的升级版本。ReplicaSet 和 Replication Controller 之间的唯一区别是对选择器的支持。

  ReplicaSet 能确保运行指定数量的 pod。然而,Deployment 是一个更高层次的概念,它能管理 ReplicaSets,并提供对 pod 的更新等功能。

 1apiVersion: extensions/v1beta1
 2kind: ReplicaSet
 3metadata:
 4  name: frontend
 5  # these labels can be applied automatically
 6  # from the labels in the pod template if not set
 7  # labels:
 8    # app: guestbook
 9    # tier: frontend
10spec:
11  # this replicas value is default
12  # modify it according to your case
13  replicas: 3
14  # selector can be applied automatically
15  # from the labels in the pod template if not set,
16  # but we are specifying the selector here to
17  # demonstrate its usage.
18  selector:
19    matchLabels:
20      tier: frontend
21    matchExpressions:
22      - {key: tier, operator: In, values: [frontend]}
23  template:
24    metadata:
25      labels:
26        app: guestbook
27        tier: frontend
28    spec:
29      containers:
30      - name: php-redis
31        image: gcr.io/google_samples/gb-frontend:v3
32        resources:
33          requests:
34            cpu: 100m
35            memory: 100Mi
36        env:
37        - name: GET_HOSTS_FROM
38          value: dns
39          # If your cluster config does not include a dns service, then to
40          # instead access environment variables to find service host
41          # info, comment out the 'value: dns' line above, and uncomment the
42          # line below.
43          # value: env
44        ports:
45        - containerPort: 80

Deployment

  Deployment 为 PodReplica Set(升级版的 Replication Controller)提供声明式更新。

  • 使用 Deployment 来创建 ReplicaSet。ReplicaSet 在后台创建 pod。检查启动状态,看它是成功还是失败。
  • 通过更新 Deployment 的 PodTemplateSpec 字段来声明 Pod 的新状态。这会创建一个新的 ReplicaSet,Deployment 会按照控制的速率将 pod 从旧的 ReplicaSet 移动到新的 ReplicaSet 中。
  • 如果当前状态不稳定,回滚到之前的 Deployment revision。每次回滚都会更新 Deployment 的 revision。
  • 扩容 Deployment 以满足更高的负载。
  • 暂停 Deployment 来应用 PodTemplateSpec 的多个修复,然后恢复上线。
  • 根据 Deployment 的状态判断上线是否 hang 住了。
  • 清除旧的不必要的 ReplicaSet。

  demo

  创建三个 Nginx 的 Deployment

1kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record

  查看 Deployment

1kubectl get deployments

  预期是 3 个 Replica,当前是 0 个,最新的是 0 个,可用 0 个

1NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
2nginx-deployment   3         0         0            0           1s
3

  查看 RS

1$ kubectl get rs
2NAME                          DESIRED   CURRENT   READY   AGE
3nginx-deployment-2035384211   3         3         0       18s

  查看当前 POD

1$ kubectl get pods --show-labels
2NAME                                READY     STATUS    RESTARTS   AGE       LABELS
3nginx-deployment-2035384211-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
4nginx-deployment-2035384211-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
5nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211

  Deployment 的 rollout 当且仅当 Deployment 的 pod template(例如。spec.template)中的 label 更新或者镜像更改时被触发。其他更新,例如扩容 Deployment 不会触发 rollout。

更新 Deployment

1$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

  查看 rollout 状态

1$ kubectl rollout status deployment/nginx-deployment
2Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
3deployment "nginx-deployment" successfully rolled out

  我们通过执行 kubectl get rs 可以看到 Deployment 更新了 Pod,通过创建一个新的 ReplicaSet 并扩容了 3 个 replica,同时将原来的 ReplicaSet 缩容到了 0 个 replica。

1$ kubectl get rs
2NAME                          DESIRED   CURRENT   READY   AGE
3nginx-deployment-1564180365   3         3         0       6s
4nginx-deployment-2035384211   0         0         0       36s

  执行 get pods 只会看到当前的新的 pod:

1$ kubectl get pods
2NAME                                READY     STATUS    RESTARTS   AGE
3nginx-deployment-1564180365-khku8   1/1       Running   0          14s
4nginx-deployment-1564180365-nacti   1/1       Running   0          14s
5nginx-deployment-1564180365-z9gth   1/1       Running   0          14s

  当新的 Pod 创建出来之前不会杀掉旧的 Pod。这样能够确保可用的 Pod 数量至少有 2 个,Pod 的总数最多 4 个。

 1$ kubectl describe deployments
 2Name:           nginx-deployment
 3Namespace:      default
 4CreationTimestamp:  Tue, 15 Mar 2016 12:01:06 -0700
 5Labels:         app=nginx
 6Selector:       app=nginx
 7Replicas:       3 updated | 3 total | 3 available | 0 unavailable
 8StrategyType:       RollingUpdate
 9MinReadySeconds:    0
10RollingUpdateStrategy:  1 max unavailable, 1 max surge
11OldReplicaSets:     <none>
12NewReplicaSet:      nginx-deployment-1564180365 (3/3 replicas created)
13Events:
14  FirstSeen LastSeen    Count   From                     SubobjectPath   Type        Reason              Message
15  --------- --------    -----   ----                     -------------   --------    ------              -------
16  36s       36s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
17  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
18  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
19  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
20  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
21  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3

回退

  默认情况下,kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录

  假设我们在更新 Deployment 的时候犯了一个拼写错误,将镜像的名字写成了 nginx:1.91,而正确的名字应该是 nginx:1.9.1:

1$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
2deployment "nginx-deployment" image updated

  Rollout 将会卡住。

1$ kubectl rollout status deployments nginx-deployment
2Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

  按住 Ctrl-C 停止上面的 rollout 状态监控。

  您会看到旧的 replica(nginx-deployment-1564180365 和 nginx-deployment-2035384211)和新的 replica (nginx-deployment-3066724191)数目都是 2 个。

1$ kubectl get rs
2NAME                          DESIRED   CURRENT   READY   AGE
3nginx-deployment-1564180365   2         2         0       25s
4nginx-deployment-2035384211   0         0         0       36s
5nginx-deployment-3066724191   2         2         2       6s

  看下创建 Pod,您会看到有两个新的 ReplicaSet 创建的 Pod 处于 ImagePullBackOff 状态,循环拉取镜像。

1$ kubectl get pods
2NAME                                READY     STATUS             RESTARTS   AGE
3nginx-deployment-1564180365-70iae   1/1       Running            0          25s
4nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
5nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
6nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s

  注意,Deployment controller 会自动停止坏的 rollout,并停止扩容新的 ReplicaSet。

 1$ kubectl describe deployment
 2Name:           nginx-deployment
 3Namespace:      default
 4CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
 5Labels:         app=nginx
 6Selector:       app=nginx
 7Replicas:       2 updated | 3 total | 2 available | 2 unavailable
 8StrategyType:       RollingUpdate
 9MinReadySeconds:    0
10RollingUpdateStrategy:  1 max unavailable, 1 max surge
11OldReplicaSets:     nginx-deployment-1564180365 (2/2 replicas created)
12NewReplicaSet:      nginx-deployment-3066724191 (2/2 replicas created)
13Events:
14  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
15  --------- --------    -----   ----                    -------------   --------    ------              -------
16  1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
17  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
18  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
19  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
20  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
21  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
22  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
23  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
24  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2

  检查下 Deployment 的 revision:

1$ kubectl rollout history deployment/nginx-deployment
2deployments "nginx-deployment":
3REVISION    CHANGE-CAUSE
41           kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml--record
52           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
63           kubectl set image deployment/nginx-deployment nginx=nginx:1.91

  查看单个 revision 的详细信息:

 1$ kubectl rollout history deployment/nginx-deployment --revision=2
 2deployments "nginx-deployment" revision 2
 3  Labels:       app=nginx
 4          pod-template-hash=1159050644
 5  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
 6  Containers:
 7   nginx:
 8    Image:      nginx:1.9.1
 9    Port:       80/TCP
10     QoS Tier:
11        cpu:      BestEffort
12        memory:   BestEffort
13    Environment Variables:      <none>

  回退到历史版本

1kubectl rollout undo deployment/nginx-deployment
2kubectl rollout undo deployment/nginx-deployment --to-revision=2

  您可以通过设置。spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision;如果将该项设置为 0,Deployment 就不允许回退了。

Deployment 扩容

  您可以使用以下命令扩容 Deployment:

1$ kubectl scale deployment nginx-deployment --replicas 10

  暂停

1kubectl rollout pause deployment/nginx-deployment

  恢复

1kubectl rollout resume deploy nginx

Deployment 状态

  progressing

  • Deployment 正在创建新的 ReplicaSet 过程中。
  • Deployment 正在扩容一个已有的 ReplicaSet。
  • Deployment 正在缩容一个已有的 ReplicaSet。
  • 有新的可用的 pod 出现。

  complete

  • Deployment 最小可用。最小可用意味着 Deployment 的可用 replica 个数等于或者超过 Deployment 策略中的期望个数。
  • 所有与该 Deployment 相关的 replica 都被更新到了您指定版本,也就说更新完成。
  • 该 Deployment 中没有旧的 Pod 存在。

  失败状态

  • 无效的引用
  • 不可读的 probe failure
  • 镜像拉取错误
  • 权限不够
  • 范围限制
  • 程序运行时配置错误

Service

  负责网络转发地址解析 Pod 访问等

 1kind: Service
 2apiVersion: v1
 3metadata:
 4  name: my-service
 5spec:
 6  selector:
 7    app: MyApp
 8  ports:
 9    - protocol: TCP
10      port: 80
11      targetPort: 9376

  上述配置将创建一个名称为 “my-service” 的 Service 对象,它会将请求代理到使用 TCP 端口 9376,并且具有标签 "app=MyApp" 的 Pod 上。

  在任何这些场景中,都能够定义没有 selector 的 Service :

1kind: Service
2apiVersion: v1
3metadata:
4  name: my-service
5spec:
6  ports:
7    - protocol: TCP
8      port: 80
9      targetPort: 9376

  由于这个 Service 没有 selector,就不会创建相关的 Endpoints 对象。可以手动将 Service 映射到指定的 Endpoints:

1kind: Endpoints
2apiVersion: v1
3metadata:
4  name: my-service
5subsets:
6  - addresses:
7      - ip: 1.2.3.4
8    ports:
9      - port: 9376

  Endpoint IP 地址不能是 loopback(127.0.0.0/8)、 link-local(169.254.0.0/16)、或者 link-local 多播(224.0.0.0/24)。

  ExternalName Service 是 Service 的特例,它没有 selector,也没有定义任何的端口和 Endpoint。 相反地,对于运行在集群外部的服务,它通过返回该外部服务的别名这种方式来提供服务。

1kind: Service
2apiVersion: v1
3metadata:
4  name: my-service
5  namespace: prod
6spec:
7  type: ExternalName
8  externalName: my.database.example.com

Service 代理

  在 Kubernetes 集群中,每个 Node 运行一个 kube-proxy 进程。

userspace 代理模式

  图片.png

iptables 代理模式

  图片.png

  多端口

 1kind: Service
 2apiVersion: v1
 3metadata:
 4  name: my-service
 5spec:
 6    selector:
 7      app: MyApp
 8    ports:
 9      - name: http
10        protocol: TCP
11        port: 80
12        targetPort: 9376
13      - name: https
14        protocol: TCP
15        port: 443
16        targetPort: 9377
17

服务发现

  Kubernetes 支持 2 种基本的服务发现模式 —— 环境变量和 DNS。

环境变量

  一个名称为 "redis-master" 的 Service 暴露了 TCP 端口 6379,同时给它分配了 Cluster IP 地址 10.0.0.11,这个 Service 生成了如下环境变量:

1REDIS_MASTER_SERVICE_HOST=10.0.0.11
2REDIS_MASTER_SERVICE_PORT=6379
3REDIS_MASTER_PORT=tcp://10.0.0.11:6379
4REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
5REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
6REDIS_MASTER_PORT_6379_TCP_PORT=6379
7REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

DNS

  DNS 服务器监视着创建新 Service 的 Kubernetes API,从而为每一个 Service 创建一组 DNS 记录。 如果整个集群的 DNS 一直被启用,那么所有的 Pod 应该能够自动对 Service 进行名称解析。

服务类型

  Kubernetes ServiceTypes 允许指定一个需要的类型的 Service,默认是 ClusterIP 类型。

  • ClusterIP:通过集群的内部 IP 暴露服务,选择该值,服务只能够在集群内部可以访问,这也是默认的 ServiceType。
  • NodePort:通过每个 Node 上的 IP
    和静态端口(NodePort)暴露服务。NodePort 服务会路由到 ClusterIP 服务,这个 ClusterIP 服务会自动创建。通过请求 :,可以从集群的外部访问一个 NodePort 服务。
  • LoadBalancer:使用云提供商的负载局衡器,可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
  • ExternalName:通过返回 CNAME 和它的值,可以将服务映射到 externalName 字段的内容(例如, foo.bar.example.com)。
    没有任何类型代理被创建,这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

外部 IP

 1kind: Service
 2apiVersion: v1
 3metadata:
 4  name: my-service
 5spec:
 6  selector:
 7    app: MyApp
 8  ports:
 9    - name: http
10      protocol: TCP
11      port: 80
12      targetPort: 9376
13  externalIPs: 
14    - 80.11.12.10

Service 查错

  查看 Service 是否存在

1kubectl get svc ServiceName

  创建一个 service,kubectl creat -f xxx.yml

 1apiVersion: v1
 2kind: Service
 3metadata:
 4  name: hostnames
 5spec:
 6  selector:
 7    app: hostnames
 8  ports:
 9  - name: default
10    protocol: TCP
11    port: 80
12    targetPort: 9376

  查看 service 是否通过 DNS 工作

1nslookup hostnames

  查看 service 的配置是否配置有误

 1$ kubectl get service hostnames -o json
 2{
 3    "kind": "Service",
 4    "apiVersion": "v1",
 5    "metadata": {
 6        "name": "hostnames",
 7        "namespace": "default",
 8        "selfLink": "/api/v1/namespaces/default/services/hostnames",
 9        "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc",
10        "resourceVersion": "347189",
11        "creationTimestamp": "2015-07-07T15:24:29Z",
12        "labels": {
13            "app": "hostnames"
14        }
15    },
16    "spec": {
17        "ports": [
18            {
19                "name": "default",
20                "protocol": "TCP",
21                "port": 80,
22                "targetPort": 9376,
23                "nodePort": 0
24            }
25        ],
26        "selector": {
27            "app": "hostnames"
28        },
29        "clusterIP": "10.0.1.175",
30        "type": "ClusterIP",
31        "sessionAffinity": "None"
32    },
33    "status": {
34        "loadBalancer": {}
35    }
36}

  是否写入了 Iptables 规则

1iptables-save | grep hostnames

  根据 label 查看 pod 信息

1 kubectl get pods -l run=my-nginx -o wide

  检查 Pod 的 IP 地址:

1kubectl get pods -l run=my-nginx -o yaml | grep podIP

  某个节点死掉时,Pod 会终止,Deployment 将创建新的 Pod,使用不同的 IP,当创建时,每个 Service 被分配一个 clusterIP 集群内地址,如下

1$ kubectl get svc my-nginx
2NAME       CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
3my-nginx   10.0.162.149   <none>        80/TCP    21s

  然后添加到 Service 的 Endpoints 中

 1$ kubectl describe svc my-nginx
 2Name:                my-nginx
 3Namespace:           default
 4Labels:              run=my-nginx
 5Selector:            run=my-nginx
 6Type:                ClusterIP
 7IP:                  10.0.162.149
 8Port:                <unset> 80/TCP
 9Endpoints:           10.244.2.5:80,10.244.3.4:80
10Session Affinity:    None
11No events.
12
13$ kubectl get ep my-nginx
14NAME       ENDPOINTS                     AGE
15my-nginx   10.244.2.5:80,10.244.3.4:80   1m

  当 Pod 在 Node 上运行时,kubelet 会为每个活跃的 Service 添加一组环境变量。
查看 Pod 的环境变量

1$ kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
2KUBERNETES_SERVICE_PORT=443
3MY_NGINX_SERVICE_HOST=10.0.162.149
4KUBERNETES_SERVICE_HOST=10.0.0.1
5MY_NGINX_SERVICE_PORT=80
6KUBERNETES_SERVICE_PORT_HTTPS=443

  Kubernetes 提供了一个 DNS 插件 Service,它使用 skydns 自动为其它 Service 指派 DNS 名字。 如果它在集群中处于运行状态,可以通过如下命令来检查:

1$ kubectl get services kube-dns --namespace=kube-system
2NAME       CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
3kube-dns   10.0.0.10    <none>        53/UDP,53/TCP   8m

  关于 Service 的安全问题

  • https 自签名证书(除非已经有了一个识别身份的证书)
  • 使用证书配置的 Nginx server
  • 使证书可以访问 Pod 的秘钥

  配置证书的 Service YAML

  • 它在相同的文件中包含了 Deployment 和 Service 的规格
  • Nginx server 处理 80 端口上的 http 流量,以及 443 端口上的 https 流量,Nginx Service 暴露了这两个端口。
  • 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。
 1apiVersion: v1
 2kind: Service
 3metadata:
 4  name: my-nginx
 5  labels:
 6    run: my-nginx
 7spec:
 8  type: NodePort
 9  ports:
10  - port: 8080
11    targetPort: 80
12    protocol: TCP
13    name: http
14  - port: 443
15    protocol: TCP
16    name: https
17  selector:
18    run: my-nginx
19---
20apiVersion: apps/v1beta1
21kind: Deployment
22metadata:
23  name: my-nginx
24spec:
25  replicas: 1
26  template:
27    metadata:
28      labels:
29        run: my-nginx
30    spec:
31      volumes:
32      - name: secret-volume
33        secret:
34          secretName: nginxsecret
35      containers:
36      - name: nginxhttps
37        image: bprashanth/nginxhttps:1.0
38        ports:
39        - containerPort: 443
40        - containerPort: 80
41        volumeMounts:
42       // 证书挂载目录
43        - mountPath: /etc/nginx/ssl
44          name: secret-volume

DNS Pod

  DNS 是内置的服务,通过插件管理器 集群插件 自动被启动。
Kubernetes DNS 在集群中调度 DNS Pod 和 Service ,配置 kubelet 以通知个别容器使用 DNS Service 的 IP 解析 DNS 名字。

支持的 DNS 模式

  • A 记录
  • SRV 记录

  查看 Pod 的 DNS 状态

1kubectl exec -ti podName -- nslookup kubernetes.default
2
3kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
4
5kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
6
7kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
8
9kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c healthz

垃圾收集

  一些 Kubernetes 对象是其它一些的 Owner。例如,一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner
的对象被称为是 Owner 的 Dependent。每个 Dependent
对象具有一个指向其所属对象的 metadata.ownerReferences 字段。

控制垃圾收集器删除 Dependent

  当删除对象时,可以指定是否该对象的 Dependent 也自动删除掉。自动删除 Dependent 也称为 级联删除。Kubernetes 中有两种 级联删除 的模式:background 模式和 foreground 模式。

  如果删除对象时,不自动删除它的 Dependent,这些 Dependent 被称作是原对象的 孤儿。

Background 级联删除

  在 background 级联删除 模式下,Kubernetes 会立即删除 Owner 对象,然后垃圾收集器会在后台删除这些 Dependent。

Foreground 级联删除

  在 foreground 级联删除 模式下,根对象首先进入 “删除中” 状态。在 “删除中” 状态会有如下的情况:

  • 对象仍然可以通过 REST API 可见
  • 会设置对象的 deletionTimestamp 字段
  • 对象的 metadata.finalizers 字段包含了值 “foregroundDeletion”

  一旦被设置为 “删除中” 状态,垃圾收集器会删除对象的所有 Dependent。垃圾收集器删除了所有 “Blocking” 的 Dependent 之后,它会删除 Owner 对象。

K8s 配置文件解析

 1apiVersion: v1 # 【必须】版本号
 2kind: Pod # 【必选】Pod
 3metadata: # 【必选-Object】元数据
 4  name: String # 【必选】 Pod的名称
 5  namespace: String # 【必选】 Pod所属的命名空间
 6  labels: # 【List】 自定义标签列表
 7    - name: String
 8  annotations: # 【List】 自定义注解列表
 9    - name: String
10spec: # 【必选-Object】 Pod中容器的详细定义
11  containers: # 【必选-List】 Pod中容器的详细定义
12    - name: String # 【必选】 容器的名称
13      image: String # 【必选】 容器的镜像名称
14      imagePullPolicy: [Always | Never | IfNotPresent] # 【String】 每次都尝试重新拉取镜像 | 仅使用本地镜像 | 如果本地有镜像则使用,没有则拉取
15      command: [String] # 【List】 容器的启动命令列表,如果不指定,则使用镜像打包时使用的启动命令
16      args: [String] # 【List】 容器的启动命令参数列表
17      workingDir: String # 容器的工作目录
18      volumeMounts: # 【List】 挂载到容器内部的存储卷配置
19        - name: String # 引用Pod定义的共享存储卷的名称,需使用volumes[]部分定义的共享存储卷名称
20          mountPath: Sting # 存储卷在容器内mount的绝对路径,应少于512个字符
21          readOnly: Boolean # 是否为只读模式,默认为读写模式
22      ports: # 【List】 容器需要暴露的端口号列表
23        - name: String  # 端口的名称
24          containerPort: Int # 容器需要监听的端口号
25          hostPort: Int # 容器所在主机需要监听的端口号,默认与containerPort相同。设置hostPort时,同一台宿主机将无法启动该容器的第二份副本
26          protocol: String # 端口协议,支持TCP和UDP,默认值为TCP
27      env: # 【List】 容器运行前需设置的环境变量列表
28        - name: String # 环境变量的名称
29          value: String # 环境变量的值
30      resources: # 【Object】 资源限制和资源请求的设置
31        limits: # 【Object】 资源限制的设置
32          cpu: String # CPU限制,单位为core数,将用于docker run --cpu-shares参数
33          memory: String # 内存限制,单位可以为MB,GB等,将用于docker run --memory参数
34        requests: # 【Object】 资源限制的设置
35          cpu: String # cpu请求,单位为core数,容器启动的初始可用数量
36          memory: String # 内存请求,单位可以为MB,GB等,容器启动的初始可用数量
37      livenessProbe: # 【Object】 对Pod内各容器健康检查的设置,当探测无响应几次之后,系统将自动重启该容器。可以设置的方法包括:exec、httpGet和tcpSocket。对一个容器只需要设置一种健康检查的方法
38        exec: # 【Object】 对Pod内各容器健康检查的设置,exec方式
39          command: [String] # exec方式需要指定的命令或者脚本
40        httpGet: # 【Object】 对Pod内各容器健康检查的设置,HTTGet方式。需要指定path、port
41          path: String
42          port: Number
43          host: String
44          scheme: String
45          httpHeaders:
46            - name: String
47              value: String
48        tcpSocket: # 【Object】 对Pod内各容器健康检查的设置,tcpSocket方式
49          port: Number
50        initialDelaySeconds: Number # 容器启动完成后首次探测的时间,单位为s
51        timeoutSeconds: Number  # 对容器健康检查的探测等待响应的超时时间设置,单位为s,默认值为1s。若超过该超时时间设置,则将认为该容器不健康,会重启该容器。
52        periodSeconds: Number # 对容器健康检查的定期探测时间设置,单位为s,默认10s探测一次
53        successThreshold: 0
54        failureThreshold: 0
55      securityContext:
56        privileged: Boolean
57  restartPolicy: [Always | Never | OnFailure] # Pod的重启策略 一旦终止运行,都将重启 | 终止后kubelet将报告给master,不会重启 | 只有Pod以非零退出码终止时,kubelet才会重启该容器。如果容器正常终止(退出码为0),则不会重启。
58  nodeSelector: object # 设置Node的Label,以key:value格式指定,Pod将被调度到具有这些Label的Node上
59  imagePullSecrets: # 【Object】 pull镜像时使用的Secret名称,以name:secretkey格式指定
60    - name: String
61  hostNetwork: Boolean # 是否使用主机网络模式,默认值为false。设置为true表示容器使用宿主机网络,不再使用docker网桥,该Pod将无法在同一台宿主机上启动第二个副本
62  volumes: # 【List】 在该Pod上定义的共享存储卷列表
63    - name: String # 共享存储卷的名称,volume的类型有很多emptyDir,hostPath,secret,nfs,glusterfs,cephfs,configMap
64      emptyDir: {} # 【Object】 类型为emptyDir的存储卷,表示与Pod同生命周期的一个临时目录,其值为一个空对象:emptyDir: {}
65      hostPath: # 【Object】 类型为hostPath的存储卷,表示挂载Pod所在宿主机的目录
66        path: String # Pod所在主机的目录,将被用于容器中mount的目录
67      secret: # 【Object】类型为secret的存储卷,表示挂载集群预定义的secret对象到容器内部
68        secretName: String
69        items:
70          - key: String
71            path: String
72      configMap: # 【Object】 类型为configMap的存储卷,表示挂载集群预定义的configMap对象到容器内部
73        name: String
74        items:
75          - key: String
76            path: String

标题:kubernetes文档知识点个人总结
作者:fe
地址:https://blog.eiyouhe.com/articles/2020/03/29/1585493374857.html