概述

K8s资源管理

• 命令式对象管理：直接使用命令去操作kubernetes的资源

kubectl run nginx-pod --image=nginx:1.17.1 --port=80

• 命令式对象配置：通过命令配置和配置文件去操作kubernetes的资源

kubectl apply  -f nginx-pod.yaml

• 声明式对象配置：通过apply命令和配置文件去操作kubernetes的资源

kubectl apply -f nginx-pod.yaml

命令式对象管理

kubectl命令

kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装和部署。

● kubectl命令的语法如下：

kubectl [command] [type] [name] [flags]

● command：指定要对资源执行的操作，比如create、get、delete。

● type：指定资源的类型，比如deployment、pod、service。

● name：指定资源的名称，名称大小写敏感。

● flags：指定额外的可选参数

示例

kubectl get pods #查看所有的pod
kubectl get pod pod_name #查看某个pod
kubectl get pod pod_name -o yaml #查看某个pod，以yaml格式展示结果

操作（command）

kubernetes允许对资源进行多种操作，可以通过–help查看详细的操作命令：

kubectl --help

① 基本命令：

② 运行和调试：

③ 高级命令：

④ 其他命令：

资源类型（type）

kubernetes中所有的内容都抽象为资源，可以通过下面的命令进行查看：

kubectl api-resources

① 集群级别资源：

② Pod资源：

③ Pod资源控制器：

④ 服务发现资源：

⑤ 存储资源：

⑥ 配置资源：

应用示例

kubectl create namespace dev
kubectl get    namespace/ns 
kubectl get    pods -n dev

命令式对象配置

创建一个nginx-pod.yaml，内容如下：

apiVersion: v1
kind: Namespace
metadata:
  name: dev
---
apiVersion: v1
kind: Pod
metadata:
  name: nginxpod
  namespace: dev
spec:
  containers:
    - name: nginx-containers
      image: nginx:1.17.1

一系列命令

kubectl create 	-f 	nginx-pod.yaml
kubectl get 	-f 	nginx-pod.yaml
kubectl delete 	-f 	nginx-pod.yaml

总结：命令式对象配置的方式操作资源，可以简单的认为：命令+yaml配置文件（里面是命令需要的各种参数）

yaml(资源编排)

YAML 基本语法

• 使用空格做为缩进
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
• 低版本缩进时不允许使用Tab 键，只允许使用空格
• 使用#标识注释，从这个字符一直到行尾，都会被解释器忽略
• 使用 — 表示新的yaml文件开始
  YAML 支持的数据结构
  对象

键值对的集合，又称为映射(mapping) / 哈希（hashes） / 字典（dictionary）

# 对象类型：对象的一组键值对，使用冒号结构表示
name: Tom
age: 18

# yaml 也允许另一种写法，将所有键值对写成一个行内对象
hash: {name: Tom, age: 18}

数组

# 数组类型：一组连词线开头的行，构成一个数组
People
- Tom
- Jack

# 数组也可以采用行内表示法
People: [Tom, Jack]

快速编写yaml
使用kubectl create命令

这种方式一般用于资源没有部署的时候，我们可以直接创建一个YAML配置文件

# 尝试运行,并不会真正的创建镜像
kubectl create deployment web --image=nginx -o yaml --dry-run

或者我们可以输出到一个文件中

kubectl create deployment web --image=nginx -o yaml --dry-run > hello.yaml

然后我们就在文件中直接修改即可

使用kubectl get命令导出yaml文件

可以首先查看一个目前已经部署的镜像

kubectl get deploy

然后我们导出 nginx的配置

kubectl get deploy nginx -o=yaml --export > nginx.yaml

然后会生成一个 nginx.yaml 的配置文件

K8S实战入门

Label

控制器和service的selector中MatchLabels和lable的配置都是根据Pod的labels

Namespace

概述

● Namespace是kubernetes系统中一种非常重要的资源，它的主要作用是用来实现多套系统的资源隔离或者多租户的资源隔离。

● 默认情况下，kubernetes集群中的所有Pod都是可以相互访问的。但是在实际中，可能不想让两个Pod之间进行互相的访问，那么此时就可以将两个Pod划分到不同的Namespace下。kubernetes通过将集群内部的资源分配到不同的Namespace中，可以形成逻辑上的“组”，以方便不同的组的资源进行隔离使用和管理。

● 可以通过kubernetes的授权机制，将不同的Namespace交给不同租户进行管理，这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制，限定不同租户能占用的资源，例如CPU使用量、内存使用量等等，来实现租户可用资源的管理。

kubernetes在集群启动之后，会默认创建几个namespace。
命令式

kubectl get ns #查看所有命名空间
kubectl create namespace dev #创建命名空间
kubectl delete ns dev #删除命名空间dev

• default：所有未指定的Namespace的对象都会被分配在default命名空间。
• kube-node-lease：集群节点之间的心跳维护，v1.13开始引入。
• kube-public：此命名空间的资源可以被所有人访问（包括未认证用户）。
• kube-system：所有由kubernetes系统创建的资源都处于这个命名空间
  命令式对象配置
  ① 新建ns-dev.yaml：

apiVersion: v1
kind: Namespace
metadata:
  name: dev

② 通过命令式对象配置进行创建和删除：

kubectl create -f ns-dev.yaml
kubectl delete -f ns-dev.yaml

Pod

命令式对象配置

① 新建pod-nginx.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
spec:
  containers:
  - image: nginx:1.17.1
    imagePullPolicy: IfNotPresent
    name: pod
    ports: 
    - name: nginx-port
      containerPort: 80
      protocol: TCP

② 执行命令：

kubectl create -f pod-nginx.yaml
kubectl delete -f pod-nginx.yaml
kubectl describe pod nginx -n dev #查看名称为dev的namespace下的Pod的名称为nginx的详细信息
# 获取Pod的IP
kubectl get pods [-n dev] -o wide

Deployment

概述
● 在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。

● Pod控制器用于Pod的管理，确保Pod资源符合预期的状态，当Pod的资源出现故障的时候，会尝试进行重启或重建Pod。

● 在kubernetes中Pod控制器的种类有很多，本章节只介绍一种：Deployment。

命令式对象配置
① 创建一个deploy-nginx.yaml，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx:1.17.1
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP

② 执行创建和删除命令：

kubectl create -f deploy-nginx.yaml
kubectl delete -f deploy-nginx.yaml

语法：查看创建的Pod

kubectl get pods [-n 命名空间]
kubectl get pods -n dev    #示例：查看名称为dev的namespace下通过deployment创建的3个Pod
kubectl get deployment [-n 命名空间] #查看deployment的信息
kubectl get deploy [-n 命名空间]
kubectl describe deployment xxx [-n 命名空间] #查看deployment的详细信息

Service

概述
我们已经能够利用Deployment来创建一组Pod来提供具有高可用性的服务，虽然每个Pod都会分配一个单独的Pod的IP地址，但是却存在如下的问题：

○ Pod的IP会随着Pod的重建产生变化。

○ Pod的IP仅仅是集群内部可见的虚拟的IP，外部无法访问。

● 这样对于访问这个服务带来了难度，因此，kubernetes设计了Service来解决这个问题。

● Service可以看做是一组同类的Pod对外的访问接口，借助Service，应用可以方便的实现服务发现和负载均衡。

应用示例
语法：暴露Service

kubectl expose deployment xxx 
--name=服务名 --type=ClusterIP  #设置type类型，NodePort、ClusterIP  
--port=暴露的端口  ## pod暴露的端口
--target-port=镜像产生容器的端口 [-n 命名空间] #如nginx就是80，tomcat就是8080
# 会产生一个CLUSTER-IP，这个就是service的IP，在Service的生命周期内，这个地址是不会变化的

#暴露名为test的namespace下的名为nginx的deployment，并设置服务名为svc-nginx1
kubectl expose deployment nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n test
# 查看Service
kubectl get service [-n 命名空间] 
kubectl get svc [-n 命名空间] 
kubectl delete service svc-nginx1 -n test

对象配置方式
① 新建svc-nginx.yaml，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx
  namespace: dev
spec:
  clusterIP: 10.109.179.231
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: ClusterIP

② 执行命令：

kubectl  create  -f  svc-nginx.yaml
kubectl  delete  -f  svc-nginx.yaml
kubectl delete   service xxx [-n 命名空间]

Pod

Pod的结构

每个Pod中都包含一个或者多个容器，这些容器可以分为两类：

● ① 用户程序所在的容器，数量可多可少。

● ② Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：

○ 可以以它为依据，评估整个Pod的健康状况。

○ 可以在根容器上设置IP地址，其它容器都共享此IP（Pod的IP），以实现Pod内部的网络通信（这里是Pod内部的通讯，Pod之间的通讯采用虚拟二层网络技术来实现，我们当前环境使用的是Flannel）

Pod定义

• 下面是Pod的资源清单：

apiVersion: v1     #必选，版本号，例如v1
kind: Pod       　 #必选，资源类型，例如 Pod
metadata:       　 #必选，元数据
  name: string     #必选，Pod名称
  namespace: string  #Pod所属的命名空间,默认为"default"
  labels:       　　  #自定义标签列表
    - name: string      　          
spec:  #必选，Pod中容器的详细定义
  containers:  #必选，Pod中容器列表
  - name: string   #必选，容器名称
    image: string  #必选，容器的镜像名称
    imagePullPolicy: [ Always|Never|IfNotPresent ]  #获取镜像的策略 
    command: [string]   #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]      #容器的启动命令参数列表
    workingDir: string  #容器的工作目录
    volumeMounts:       #挂载到容器内部的存储卷配置
    - name: string      #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean #是否为只读模式
    ports: #需要暴露的端口库号列表
    - name: string        #端口的名称
      containerPort: int  #容器需要监听的端口号
      hostPort: int       #容器所在主机需要监听的端口号，默认与Container相同
      protocol: string    #端口协议，支持TCP和UDP，默认TCP
    env:   #容器运行前需设置的环境变量列表
    - name: string  #环境变量名称
      value: string #环境变量的值
    resources: #资源限制和请求的设置
      limits:  #资源限制的设置
        cpu: string     #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string  #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests: #资源请求的设置
        cpu: string    #Cpu请求，容器启动的初始可用数量
        memory: string #内存请求,容器启动的初始可用数量
    lifecycle: #生命周期钩子
		postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
		preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
    livenessProbe:  #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
      exec:       　 #对Pod容器内检查方式设置为exec方式
        command: [string]  #exec方式需要制定的命令或脚本
      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0       #容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0    　　    #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0     　　    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged: false
  restartPolicy: [Always | Never | OnFailure]  #Pod的重启策略
  nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
  nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
  imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
  - name: string
  hostNetwork: false   #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
  volumes:   #在该pod上定义共享存储卷列表
  - name: string    #共享存储卷名称 （volumes类型有很多种）
    emptyDir: {}       #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
    hostPath: string   #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
      path: string      　　        #Pod所在宿主机的目录，将被用于同期中mount的目录
    secret:       　　　#类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
      scretname: string  
      items:     
      - key: string
        path: string
    configMap:         #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
      name: string
      items:
      - key: string
        path: string

• 查看资源类型为pod的可配置项

kubectl explain pod #查看资源类型为pod的可配置项
kubectl explain pod.metadata # 查看资源类型为Pod的metadata的属性的可配置项

基本配置

• 创建pod-base.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-base
  namespace: dev
  labels:
    user: dhy
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1 # 容器需要的镜像地址
    - name: busybox # 容器名称
      image: busybox:1.30 # 容器需要的镜像地址

kubectl apply -f pod-base.yaml
kubectl get pod -n dev
# 此时已经运行起来了一个基本的Pod，虽然它暂时有问题
kubectl describe pod pod-base -n dev #通过describe查看内部的详情
kubectl get pod -n dev -o wide #查看ip

镜像拉取策略

• 创建pod-imagepullpolicy.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-imagepullpolicy
  namespace: dev
  labels:
    user: dhy
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1 # 容器需要的镜像地址
      imagePullPolicy: Always # 用于设置镜像的拉取策略
    - name: busybox # 容器名称
      image: busybox:1.30 # 容器需要的镜像地址

● imagePullPolicy：用于设置镜像拉取的策略，kubernetes支持配置三种拉取策略：

○ Always：总是从远程仓库拉取镜像（一直远程下载）。

○ IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就用本地，本地没有就使用远程下载）。

○ Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错（一直使用本地，没有就报错）。

默认值说明：
如果镜像tag为具体的版本号，默认策略是IfNotPresent。
如果镜像tag为latest（最终版本），默认策略是Always。

# 在容器中执行命令
# kubectl exec -it pod的名称 -n 命名空间 -c 容器名称 /bin/sh
kubectl exec -it pod-imagepullpolicy -n dev -c nginx /bin/sh

资源配额

● 容器中的程序要运行，肯定会占用一定的资源，比如CPU和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量的资源，导致其他的容器无法运行。针对这种情况，kubernetes提供了对内存和CPU的资源进行配额的机制，这种机制主要通过resources选项实现，它有两个子选项：

○ limits：用于限制运行的容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启。

○ requests：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动。

● 可以通过上面的两个选项设置资源的上下限。

● 创建pod-resoures.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-resoures
  namespace: dev
  labels:
    user: dhy
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1 # 容器需要的镜像地址
      imagePullPolicy: IfNotPresent # 设置镜像拉取策略
      ports: # 端口设置
        - name: nginx-port # 端口名称，如果执行，必须保证name在Pod中是唯一的
          containerPort: 80 # 容器要监听的端口 （0~65536）
          protocol: TCP # 端口协议
      resources: # 资源配额
        limits: # 限制资源的上限
          cpu: "2" # CPU限制，单位是core数
          memory: "10Gi" # 内存限制
        requests: # 限制资源的下限
          cpu: "1" # CPU限制，单位是core数 
          memory: "10Mi" # 内存限制

• cpu：core数，可以为整数或小数。
• memory：内存大小，可以使用Gi、Mi、G、M等形式。

一系列命令

kubectl create -f pod-resoures.yaml # 创建Pod
kubectl get pod pod-resoures -n dev #查看发现Pod运行正常
kubectl delete -f pod-resoures.yaml # 接下来，停止Pod

编辑Pod，修改resources.requests.memory的值为10Gi：

apiVersion: v1
kind: Pod
metadata:
  name: pod-resoures
  namespace: dev
  labels:
    user: dhy
spec:
  containers:
    - name: nginx # 容器名称
      image: nginx:1.17.1 # 容器需要的镜像地址
      imagePullPolicy: IfNotPresent # 设置镜像拉取策略
      ports: # 端口设置
        - name: nginx-port # 端口名称，如果执行，必须保证name在Pod中是唯一的
          containerPort: 80 # 容器要监听的端口 （0~65536）
          protocol: TCP # 端口协议
      resources: # 资源配额
        limits: # 限制资源的上限
          cpu: "2" # CPU限制，单位是core数
          memory: "10Gi" # 内存限制
        requests: # 限制资源的下限
          cpu: "1" # CPU限制，单位是core数 
          memory: "10Gi" # 内存限制

kubectl create -f pod-resource.yaml # 再次启动Pod：
kubectl get pod pod-resoures -n dev -o wide # 查看Pod状态，发现Pod启动失败：
kubectl describe pod pod-resoures -n dev #查看Pod详情会发现，如下提示：

创建和终止

● 初始化容器是在Pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：
○ ① 初始化容器必须运行完成直至结束，如果某个初始化容器运行失败，那么kubernetes需要重启它直至成功完成。
○ ② 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行。

● 初始化容器有很多的应用场景，下面列出的是最常见的几个：
○ 提供主容器镜像中不具备的工具程序或自定义代码。
○ 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足。

● 接下来做一个案例，模拟下面这个需求：
○ 假设要以主容器来运行Nginx，但是要求在运行Nginx之前要能够连接上MySQL和Redis所在的服务器。
○ 为了简化测试，事先规定好MySQL和Redis所在的IP地址分别为192.168.18.103和192.168.18.104（注意，这两个IP都不能ping通，因为环境中没有这两个IP）。

● 创建pod-initcontainer.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-initcontainer
  namespace: dev
  labels:
    user: xudaxian
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
      resources:
        limits:
          cpu: "2"
          memory: "10Gi"
        requests:
          cpu: "1"
          memory: "10Mi"
  initContainers: # 初始化容器配置
    - name: test-mysql
      image: busybox:1.30
      command: ["sh","-c","until ping 192.168.18.103 -c 1;do echo waiting for mysql ...;sleep 2;done;"]
      securityContext:
        privileged: true # 使用特权模式运行容器
    - name: test-redis
      image: busybox:1.30
      command: ["sh","-c","until ping 192.168.18.104 -c 1;do echo waiting for redis ...;sleep 2;done;"]

钩子函数

apiVersion: v1
kind: Pod
metadata:
  name: pod-hook-exec
  namespace: dev
  labels:
    user: dhy
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
      resources:
        limits:
          cpu: "2"
          memory: "10Gi"
        requests:
          cpu: "1"
          memory: "10Mi"
      lifecycle: # 生命周期配置
        postStart: # 容器创建之后执行，如果失败会重启容器
          exec: # 在容器启动的时候，执行一条命令，修改掉Nginx的首页内容
            command: ["/bin/sh","-c","echo postStart ... > /usr/share/nginx/html/index.html"]
        preStop: # 容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作
          exec: # 在容器停止之前停止Nginx的服务
            command: ["/usr/sbin/nginx","-s","quit"]

创建Pod：

kubectl create -f pod-hook-exec.yaml

查看Pod：

kubectl get pod pod-hook-exec -n dev -o wide

访问Pod：

curl 10.244.1.11

容器探测

● 容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例“摘除”，不承担业务流量。kubernetes提供了两种探针来实现容器探测，分别是：

○ liveness probes：存活性探测，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器。

○ readiness probes：就绪性探测，用于检测应用实例是否可以接受请求，如果不能，k8s不会转发流量。

• livenessProbe：存活性探测，决定是否重启容器。
• readinessProbe：就绪性探测，决定是否将请求转发给容器。
  k8s在1.16版本之后新增了startupProbe探针，用于判断容器内应用程序是否已经启动。如果配置了startupProbe探针，就会先禁止其他的探针，直到startupProbe探针成功为止，一旦成功将不再进行探测。

exec方式

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-exec
  namespace: dev
  labels:
    user: dhy
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
      livenessProbe: # 存活性探针
        exec:
          command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令，必须失败，因为根本没有这个文件

tcpSocket方式

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-tcpsocket
  namespace: dev
  labels:
    user: dhy
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
      livenessProbe: # 存活性探针
        tcpSocket:
          port: 8080 # 尝试访问8080端口，必须失败，因为Pod内部只有一个Nginx容器，而且只是监听了80端口

httpGet方式

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-httpget
  namespace: dev
  labels:
    user: dhy
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
      livenessProbe: # 存活性探针
        httpGet: # 其实就是访问http://127.0.0.1:80/hello
          port: 80 # 端口号
          scheme: HTTP # 支持的协议，HTTP或HTTPS
          path: /hello # URI地址
          host: 127.0.0.1 # 主机地址

FIELDS:
exec
tcpSocket
httpGet
initialDelaySeconds # 容器启动后等待多少秒执行第一次探测
timeoutSeconds # 探测超时时间。默认1秒，最小1秒
periodSeconds # 执行探测的频率。默认是10秒，最小1秒
failureThreshold # 连续探测失败多少次才被认定为失败。默认是3。最小值是1
successThreshold # 连续探测成功多少次才被认定为成功。默认是1

重启策略

● 在容器探测中，一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由Pod的重启策略决定的，Pod的重启策略有3种，分别如下：

○ Always：容器失效时，自动重启该容器，默认值。

○ OnFailure：容器终止运行且退出码不为0时重启(异常终止时重启)。

○ Never：不论状态如何，都不重启该容器。

● 重启策略适用于Pod对象中的所有容器，首次需要重启的容器，将在其需要的时候立即进行重启，随后再次重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大的延迟时长。

● 创建pod-restart-policy.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-restart-policy
  namespace: dev
  labels:
    user: dhy
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
      livenessProbe: # 存活性探测
        httpGet:
          port: 80
          path: /hello
          host: 127.0.0.1
          scheme: HTTP
  restartPolicy: Never # 重启策略

调度策略

定向调度

定向调度，指的是利用在Pod上声明的nodeName或nodeSelector，以此将Pod调度到期望的Node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过Pod运行失败而已。

nodeName
● nodeName用于强制约束将Pod调度到指定的name的Node节点上。这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。

● 创建一个pod-nodename.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodename
  namespace: dev
  labels:
    user: dhy
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  nodeName: k8s-node1 # 指定调度到k8s-node1节点上

• 创建Pod：

kubectl create -f pod-nodename.yaml

• 查看Pod：

kubectl get pod pod-nodename -n dev -o wide

nodeSelector
nodeSelector用于将Pod调度到添加了指定标签的Node节点上，它是通过kubernetes的label-selector机制实现的，换言之，在Pod创建之前，会由Scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将Pod调度到目标节点，该匹配规则是强制约束。

首先给node节点添加标签：

kubectl label node k8s-node1 nodeenv=pro
kubectl label node k8s-node2 nodeenv=test

创建pod-nodeselector.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector
  namespace: dev
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  nodeSelector:
    nodeenv: pro # 指定调度到具有nodeenv=pro的Node节点上

亲和性调度

● 虽然定向调度的两种方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用的Node列表也不行，这就限制了它的使用场景。

● 基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在nodeSelector的基础之上进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使得调度更加灵活。

● Affinity主要分为三类：

○ nodeAffinity（node亲和性）：以Node为目标，解决Pod可以调度到哪些Node的问题。

○ podAffinity（pod亲和性）：以Pod为目标，解决Pod可以和那些已存在的Pod部署在同一个拓扑域中的问题。

○ podAntiAffinity（pod反亲和性）：以Pod为目标，解决Pod不能和那些已经存在的Pod部署在同一拓扑域中的问题。

关于亲和性和反亲和性的使用场景的说明：

亲和性：如果两个应用频繁交互，那么就有必要利用亲和性让两个应用尽可能的靠近，这样可以较少因网络通信而带来的性能损耗。
反亲和性：当应用采用多副本部署的时候，那么就有必要利用反亲和性让各个应用实例打散分布在各个Node上，这样可以提高服务的高可用性。
nodeAffinity
查看nodeAffinity的可选配置项：

pod.spec.affinity.nodeAffinity
  requiredDuringSchedulingIgnoredDuringExecution  Node节点必须满足指定的所有规则才可以，相当于硬限制
    nodeSelectorTerms  节点选择列表
      matchFields   按节点字段列出的节点选择器要求列表  
      matchExpressions   按节点标签列出的节点选择器要求列表(推荐)
        key    键
        values 值
        operator 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
  preferredDuringSchedulingIgnoredDuringExecution 优先调度到满足指定的规则的Node，相当于软限制 (倾向)     
    preference   一个节点选择器项，与相应的权重相关联
      matchFields 按节点字段列出的节点选择器要求列表
      matchExpressions   按节点标签列出的节点选择器要求列表(推荐)
        key 键
        values 值
        operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt  
    weight 倾向权重，在范围1-100。

关系符的使用说明:

- matchExpressions:
	- key: nodeenv # 匹配存在标签的key为nodeenv的节点
	  operator: Exists   
	- key: nodeenv # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点
	  operator: In    
      values: ["xxx","yyy"]
    - key: nodeenv # 匹配标签的key为nodeenv,且value大于"xxx"的节点
      operator: Gt   
      values: "xxx"

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-required
  namespace: dev
spec:
  containers: # 容器配置
    - name: nginx
      image: nginx:1.17.1
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port
          containerPort: 80
          protocol: TCP
  affinity: # 亲和性配置
    nodeAffinity: # node亲和性配置
      requiredDuringSchedulingIgnoredDuringExecution: # Node节点必须满足指定的所有规则才可以，相当于硬规则，类似于定向调度
        nodeSelectorTerms: # 节点选择列表
          - matchExpressions:
              - key: nodeenv # 匹配存在标签的key为nodeenv的节点，并且value是"xxx"或"yyy"的节点
                operator: In
                values:
                  - "xxx"
                  - "yyy"

污点和容忍

污点（Taints）

● 前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否运行Pod调度过来。

● Node被设置了污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。

● 污点的格式为：key=value:effect，key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

○ PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可以调度。

○ NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但是不会影响当前Node上已经存在的Pod。

○ NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已经存在的Pod驱逐。

● 语法：

kubectl taint node xxx key=value:effect #设置污点：
kubectl taint node xxx key:effect- #去除污点
kubectl taint node xxx key- #去除所有污点
kubectl describe node 节点名称 #查看指定节点上的污点

问题

0/2 nodes are available: 1 Insufficient memory, 1 node(s) had taint

通过查看yaml中的资源需求，确定了待部署的deployment所需内存仅有1G。

   resources:
     limits:
       cpu: "1"
       memory: 2Gi
     requests:
       cpu: 500m
       memory: 1Gi

查看集群的CPU和内存资源的申明占用情况

kubectl describe node |grep -E '((Name|Roles):\s{6,})|(\s+(memory|cpu)\s+[0-9]+\w{0,2}.+%\))'

解决

• 清理已安装的k8s对象，既可以删除一部分，也可以将某些对象的requests的值换成一个更小的数。
• 扩容k8s集群。
• 修改待安装的deployment的requests的值，减少申明的所需内存。