Kubernetes学习笔记

一、Kubernetes基础

1.简介：Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

特点：

• 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

• 可扩展: 模块化，插件化，可挂载，可组合

• 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

2.相关组件介绍：

  Master节点：整个集群的控制中枢

  Kube-APIServer：集群的控制中枢，各个模块之间信息交互都需要通过APIServer，同时也是集群管理、资源配置、整个集群安全机制的入口。

  Controller-Manager：集群的状态管理器，保证Pod或其他资源达到期望值，通过与APIServer进行通讯，在需要的时候创建、更新、删除它所管理的资源。

  Scheduler：集群的调度中心，它根据指定的一系列条件，选择一个或一批最佳节点部署资源。

  Etcd：键值数据库，保存持久化的集群信息，一般生产环境中建议部署三个或以上节点（奇数个）。

  Node节点：工作节点（也称为Worker节点、minion节点）

  Kubelet：负责监听、上报节点以及节点上pod的状态，与master节点通讯并管理节点上的pod。

  Kube-proxy：负责pod之间的通讯和负载均衡，将指定的流量分发到后端正确的机器上。（查看kube-proxy工作模式：curl 127.0.0.1:port/proxyMode；工作模式1.IPVS：监听Master节点增加和删除server以及endpoint的消息，调用Netlink接口创建相应的IPVS规则；2.iptables：监听Master节点增加和删除以及endpoint的消息，对于每一个Service都会创建一个iptables规则，将service的clusterIP代理到后端对应的pod）

  Calico：符合CNI标准的网络插件，给每个pod生成唯一的IP地址，并且把每个节点当作一个路由器。

  Coredns：用于Kubernetes集群内部Service的解析，可以让pod把service名称解析成ip地址，然后通过service ip地址连接到对应的应用上。

  metrics-server：统计容器资源指标

3.POD

  Pod介绍：Pod是Kubernetes中最小的单元，它由一组、一个或多个容器组成，每个pod还包含了一个Pause容器，Pause容器是pod的父容器，主要负责僵尸进程的回收管理，并为多个容器共享pod中的存储、网络、PID、IPC等。

  Pod yaml：

apiversion: v1   # 必选，api的版本号
kind: Pod       # 必选，类型Pod
metadata:      # 必选，元数据name: nginx  # 必选，需要符合RFC 1035规范的pod名称namespace: default  # 可选，pod所在的命名空间，不指定默认为default，可以使用-n指定namespacelabels:           # 可选，标签选择器，一般用于过滤和区分podapp: nginxrole: frontend   #  可以写多个annotations:      #  可选，注释列表，可以选多个app: nginx
spec:              #  必选，用于定义容器的详细信息initContainers:    #  必选，初始化容器，在容器启动之前执行的一些初始化操作- command: # 可选，容器启动执行的命令 ENTRYPOINT，arg-->cmdw- sh- -c- echo "i am initContainer for init some configuration"imager: busyboximagerPullPolicy: IfNotPresentname: init-containercontainer:                # 必选，容器列表- name: nginx            # 必选，符合rfc 1035规范的容器名称image: nginx:latest     # 必选，容器所用的镜像的地址imagePullPolicy: Always    # 可选，镜像拉取策略command:                # 可选，容器启动执行的命令- nginx- -g- "daemon off;"workingDir: /usr/share/nginx/html   # 可选，容器的工作目录volumeMounts:                  # 可选，存储卷配置，可以配置多个- name: webrootmountPath: /usr/share/nginx/html   # 挂载目录readOnly: true                   # 只读ports:                             # 可选，容器需要暴漏的端口号列表- name: http                       # 端口名称containerPort: 80      # 端口号protocol: TCP         # 端口协议，默认TCPenv:                   # 可选，环境变量配置列表- name: TZ             # 变量名value: Asia/Shanghai  # 变量的值- name: LANGvalue: en_US.uft8resources:             # 可选，资源限制和资源请求限制limits:               # 最大限制设置cpu: 1000mmemory: 1024Mirequests:            # 启动所需的资源cpu: 100mmemory: 512mistartupProbe:          # 可选，检测容器内进程是否完成启动。注意三种检查方式只能同时使用一种httpGet:             #  httpGet检测方式，生产环境建议使用httpGet实现接口级别健康检查，健康检查由应用程序提供path: /api/check  # 检查路径port: 80readinessProbe:        # 可选，检测容器内进程是否完成启动。注意三种检查方式只能同时使用一种httpGet:            #  httpGet检测方式，生产环境建议使用httpGet实现接口级别健康检查，健康检查由应用程序提供path: /api/check  # 检查路径port: 80livenessProbe:          # 可选，检测容器内进程是否完成启动。注意三种检查方式只能同时使用一种exec:                # 执行容器命令检测方式command:- cat- /healthhttpGet:               #  httpGet检测方式，生产环境建议使用httpGet实现接口级别健康检查，健康检查由应用程序提供path: /api/check    # 检查路径port: 80httpHeaders:       #  检查请求的头- name: end-uservalue: JasontcpSocker:              # 端口检测方式port: 80initialDelaySeconds: 60     # 初始化时间timeoutSeconds: 2         #  超时时间periodSeconds: 5         #  检测间隔successThreshold: 1      #  检查成功为2次表示就绪failureThreshold: 2       #  检测失败1次表示未就绪lifecycle:postStart:    # 容器创建完成后执行的指令，可以是exec httpGet TCPSockerexec:command:- sh- -c- 'mkdir /data/ 'preStop:     # 容器退出前的执行的命令httpGet:path: /port: 80exec:command:- sh- -c- sleep 9restartPolicy: Always           # 可选，默认为always，出现异常后的重启策略nodeSelector:                 # 可选，指定node节点region: subnet7imagePullSecrets:              # 可选，拉取镜像使用的secret，可以配置多个- name: xxxxhostNetwork: false               # 可选，主机模式，开启会占用主机端口volumes:                       # 共享存储卷列表- name: webroot                # 名称，与上述对应emptyDir: {}                  # 挂载目录hostPath:                # 挂载本机路径path: /etc/hosts

pod探针：

  StartupProbe: k8s1.16版本后新加的探测方式，用于判断容器内应用程序是否启动，如果配置了StartupProbe，就会禁止其他的探针，直到它检测成功为止，成功后不再探测。

  LivenessProbe: 用于探测容器是否允许，如果探测失败，kubelet会根据配置的重启策略进行相应的处理。如没有配置该探针，默认success。

  ReadinessProbe: 一般用于探测容器内的程序是否健康，它的返回值如是success，那么就代表容器已经完成启动，并且程序是可以接收流量的状态。

Pod探针的探测方式：

  ExecAction：在容器内执行一个命令，如果返回值是0，则认为容器健康；

  TCPSockerAction: 通过TCP连接容器端口，确认健康状态；

  HTTPGetAction: 通过应用程序暴漏的api地址确认程序的健康状态（返回200~400）。

探针的参数配置：

  initialDelaySeconds: 60    #初始化时间timeoutSeconds: 2        #超时时间periodSeconds: 5         #检测间隔successThreshold: 1       #检测成功1次表示就绪failureThreshold: 2        #检测失败2次表示未就绪

pod健康退出：

  使用Prestop先去请求eureka接口，下线自己的ip地址和端口号，eureka从注册表中删除该应用的ip地址，然后在容器中进行sleep；kill操作。（查看事件event）

4.控制器：

  Replication Controller：

概念：RC可确保Pod副本数达到期望值，也就是RC定义的数量。换句话说，RC可确保一个pod或一组同类pod总是可用。

如果存在的pod大于设定的值，则RC将终止额外的pod。如果太少，RC将启动更多的Pod用于保证达到期望值。与手动创建的pod不同的是，用RC维护的pod在失败、删除或终止后会自动替换。因此即使应用程序只需要一个pod，也应该使用RC或其他方式管理。RC类似于进程管理程序，但是RC不是监控单个节点上的各个进程，而是监视多个节点上的多个pod。RC是实现弹性伸缩、动态扩容和滚动升级的核心。

定义一个RC的示例如下：

apiVersion: v1
kind: ReplicationController
metadata:name: my-nginx
spec:replicas: 2template:metadata:labels:app: nginxspec:containers:- name: nginximage: daocloud.io/library/nginxports:- containerPort: 80

和定义一个pod的YAML文件相比，不同的只是kind的值为ReplicationController，replicas的值需要指定，pod的相关定义在template中，pod的名字不需要显式地指定，因为它们会在rc中创建并赋予名字

  ReplicaSet：

概念：ReplicaSet是支持基于集合的标签选择器的下一代RC，它主要用作Deployment协调、删除和更新Pod，和RC唯一的区别是，RS支持标签选择器。在实际的应用中，虽然RS可以单独使用，但是一般建议使用Deployment来自动管理ReplicaSet，除非自定义的pod不需要更新或有其他编排等。

定义一个RS的示例如下：

apiVersion: apps/v1
kind: ReplicaSet
metadata:name: frontend
spec:replicas: 3selector:matchLabels:tier: frontendtemplate:metadata:labels:tier: frontendspec:containers:- name: nginximage: registry.cn-beijing.aliyuncs.com/google_registry/nginx:1.17imagePullPolicy: IfNotPresentports:- name: httpdcontainerPort: 80

Deployment：

概念：用于部署无状态的服务，这个是最常用的控制器，企业内部无状态的微服务，比如configserver、zuul、springboot。他可以管理多个副本的pod实现无缝迁移、自动灾难恢复、一键回滚等功能。

Deployment示例：

apiVersion: apps/v1  # 指定api版本，此值必须在kubectl api-versions中  
kind: Deployment  # 指定创建资源的角色/类型   
metadata:  # 资源的元数据/属性 name: demo  # 资源的名字，在同一个namespace中必须唯一namespace: default # 部署在哪个namespace中labels:  # 设定资源的标签app: demoversion: stable
spec: # 资源规范字段replicas: 1 # 声明副本数目revisionHistoryLimit: 3 # 保留历史版本selector: # 选择器matchLabels: # 匹配标签app: demoversion: stablestrategy: # 策略rollingUpdate: # 滚动更新maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数
maxUnavailable: 30% # 在更新过程中能够进入不可用状态的 Pod 的最大值，可以为百分比，也可以为整数type: RollingUpdate # 滚动更新策略template: # 模版metadata: # 资源的元数据/属性 annotations: # 自定义注解列表sidecar.istio.io/inject: "false" # 自定义注解名字labels: # 设定资源的标签app: demoversion: stablespec: # 资源规范字段containers:- name: demo # 容器的名字   image: demo:v1 # 容器使用的镜像地址   imagePullPolicy: IfNotPresent # 每次Pod启动拉取镜像策略，三个选择（Always、Never、IfNotPresent）# Always，每次都检查；#Never，每次都不检查（不管本地是否有）；#IfNotPresent，如果本地有就不检查，如果没有就拉取 resources: # 资源管理limits: # 最大使用cpu: 300m # CPU，1核心 = 1000m
memory: 500Mi # 内存，1G = 1024Mirequests:  # 容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行cpu: 100mmemory: 100MilivenessProbe: # pod 内部健康检查的设置httpGet: # 通过httpget检查健康，返回200-399之间，则认为容器正常path: /healthCheck # URI地址port: 8080 # 端口scheme: HTTP # 协议# host: 127.0.0.1 # 主机地址initialDelaySeconds: 30 # 表明第一次检测在容器启动后多长时间后开始timeoutSeconds: 5 # 检测的超时时间periodSeconds: 30 # 检查间隔时间successThreshold: 1 # 成功门槛failureThreshold: 5 # 失败门槛，连接失败5次，pod杀掉，重启一个新的podreadinessProbe: # Pod 准备服务健康检查设置httpGet:path: /healthCheckport: 8080
scheme: HTTP # 协议# host: 127.0.0.1 # 主机地址initialDelaySeconds: 30 # 表明第一次检测在容器启动后多长时间后开始timeoutSeconds: 5 # 检测的超时时间periodSeconds: 30 # 检查间隔时间successThreshold: 1 # 成功门槛failureThreshold: 5 # 失败门槛，连接失败5次，pod杀掉，重启一个新的podreadinessProbe: # Pod 准备服务健康检查设置httpGet:path: /healthCheckport: 8080scheme: HTTPinitialDelaySeconds: 30timeoutSeconds: 5
periodSeconds: 10successThreshold: 1failureThreshold: 5#也可以用这种方法   #exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常   #  command:   #    - cat   #    - /tmp/health   #也可以用这种方法   #tcpSocket: # 通过tcpSocket检查健康  #  port: number ports:- name: http # 名称containerPort: 8080 # 容器开发对外的端口 protocol: TCP # 协议imagePullSecrets: # 镜像仓库拉取密钥- name: harbor-certificationaffinity: # 亲和性调试nodeAffinity: # 节点亲和力requiredDuringSchedulingIgnoredDuringExecution: # pod 必须部署到满足条件的节点上nodeSelectorTerms: # 节点满足任何一个条件就可以- matchExpressions: # 有多个选项，则只有同时满足这些逻辑选项的节点才能运行 pod- key: beta.kubernetes.io/archoperator: Invalues:- amd64

状态解析：

NAME            ：Deployment名称
READY           ：pod状态，已经Readly的个数
UP-TO-DATE      ：达到期望状态的副本个数
AVAILABLE       ：已经可以使用的副本个数
AGE             ：pod启动时间
CONTAINERS      ：容器名称
IMAGES          ：容器使用的镜像                                                       SELECTOR        ：管理的pod的标签

升级回滚：

升级版本： kubectl set image deploy nginx nginx=nginx:1.16.2 –record
查看历史版本： kubectl rollout history deploy nginx
回滚上一版本： kubectl rollout undo deploy nginx
查看指定版本详细信息： kubectl rollout deploy nginx --revision=5
回滚到指定版本： kubectl rollout undo deploy nginx --to -revision=5
扩容缩容： kubectl scale –replicas=3 deployment nginx
暂停更新： kubectl rollout pause deployment nginx
开启更新： kubectl rollout resume deployment nginx

注意事项：

.spec.revisionHistoryLimit: 保留RS revision的个数，设置0则不保留历史数据

.spec.minReadySeconds: 可选参数，指定新创建的的pod在没有任何容器崩溃的情况下视为Ready最小的秒数，默认为0，即一旦被创建就视为可用

滚动更新策略：1.spec.strategy.type：更新deployment的方式（a.”默认”RolingUpdate：滚动更新，可以指定maxSurge（最大额外可以存在的副本数，可以为百分比，也可以为整数）和maxUnavailabe（在更新过程中能够进入不可用状态的 Pod 的最大值，可以为百分比，也可以为整数））

Recreate：重建，先删除旧的pod，再创建新的pod