K8S -- 相关操作-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_44962906/article/details/145893806

命令行工具 -- kubectl

在任意节点使用kubectl

将 master 节点中 /etc/kubernetes/admin.conf 拷贝到需要运行的服务器的 /etc/kubernetes 目录中
```
[root@hcss-ecs-9883 /]# scp /etc/kubernetes/admin.conf root@k8s-node:/etc/kubernetes
```

在对应的服务器上配置环境变量

[root@hcss-ecs-9883 /]# echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
[root@hcss-ecs-9883 /]# source ~/.bash_profile

资源操作

创建对象

创建资源

[root@hcss-ecs-9883 /]# kubectl create -f ./my-manifest.yaml

使用多个文件创建资源

[root@hcss-ecs-9883 /]# kubectl create -f ./my1.yaml -f ./my2.yaml

使用目录下的所有清单文件来创建资源
```
[root@hcss-ecs-9883 /]# kubectl create -f ./dir
```

使用url来创建资源

[root@hcss-ecs-9883 /]# kubectl create -f https://git.io/vPieo

启动一个nginx实例

[root@hcss-ecs-9883 /]# kubectl run nginx --image=nginx

获取pod和svc文档

[root@hcss-ecs-9883 /]# kubectl explain pods
[root@hcss-ecs-9883 /]# kubectl explain svc

显示和查找资源

列出所有namespace中的service

[root@hcss-ecs-9883 /]# kubectl get services

列出所有namespace中的pod

[root@hcss-ecs-9883 /]# kubectl get pods --all-namespaces

列表所有pod并显示详细信息

[root@hcss-ecs-9883 /]# kubectl get pods -o wide

列出指定deployment

[root@hcss-ecs-9883 /]# kubectl get deployment my-dep

列出该namespace中所有pod（包括未初始化的）

[root@hcss-ecs-9883 /]# kubectl get pods --include-uninitialized

使用详细输出来描述命令

[root@hcss-ecs-9883 /]# kubectl describe nodes my-node
[root@hcss-ecs-9883 /]# kubectl describe pods my-pod

更新资源

滚动更新pod frontend-v1

[root@hcss-ecs-9883 /]# kubectl rolling-update frontend-v1 -f frontend-v2.json

更新资源名称并更新镜像

[root@hcss-ecs-9883 /]# kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2

更新frontend pod中的镜像

[root@hcss-ecs-9883 /]# kubectl rolling-update frontend --image=image:v2

退出已存在的进行中的滚动更新

[root@hcss-ecs-9883 /]# kubectl rolling-update frontend-v1 frontend-v2 --rollback

修补资源

部分更新节点

[root@hcss-ecs-9883 /]# kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

编辑资源

编辑名为docker-registry的service

[root@hcss-ecs-9883 /]# kubectl edit svc/docker-registry

scale -- 扩容与缩容

扩充nginx的数量

[root@hcss-ecs-9883 /]# kubectl get deployment
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   1/1     1            1           8m43s
[root@hcss-ecs-9883 /]# kubectl scale deploy --replicas=3 nginx-deploy
[root@hcss-ecs-9883 /]# kubectl get deployment
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3/3     3            3           8m43s

删除资源

删除pod.json文件中定义的类型和名称的pod

[root@hcss-ecs-9883 /]# kubectl delete -f ./pod.json

删除名为“baz”的pod和名为“foo”的service

[root@hcss-ecs-9883 /]# kubectl delete pod,service baz foo

删除具有name=myLabel标签的pod和service

[root@hcss-ecs-9883 /]# kubectl delete pods,services -l name=myLabel

删除具有 name=myLabel 标签的 pod 和 service（包括尚未初始化的）

[root@hcss-ecs-9883 /]# kubectl delete pods,services -l name=myLabel --include-uninitialized

删除 my-ns namespace 下的所有 pod 和 serivce（包括尚未初始化的）
```
[root@hcss-ecs-9883 /]# kubectl -n my-ns delete po,svc --all
```

pod相关命令

输出 pod 的日志（stdout）

[root@hcss-ecs-9883 /]# kubectl logs my-pod

连接到运行中的容器

[root@hcss-ecs-9883 /]# kubectl attach my-pod -i

格式化输出

-o json：输出json格式
-o name：仅打印资源名称
-o wide：以纯文本格式输出所有信息
-o yaml：输出yaml格式

pod

pod生命周期

配置文件

apiVersion: v1 # api 文档版本
kind: Pod  # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据，用于描述 Pod 的数据
  name: nginx-demo # Pod 的名称
  labels: # 定义 Pod 的标签
    type: app # 自定义 label 标签，名字为 type，值为 app
    test: 1.0.0 # 自定义 label 标签，描述 Pod 版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
  - name: nginx # 容器的名称
    image: nginx:1.7.9 # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;' # nginx -g 'daemon off;'
    workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录
    ports:
    - name: http # 端口名称
      containerPort: 80 # 描述容器内要暴露什么端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    - env: # 环境变量
      name: JVM_OPTS # 环境变量名称
      value: '-Xms128m -Xmx128m' # 环境变量的值
    reousrces:
      requests: # 最少需要多少资源
        cpu: 100m # 限制 cpu 最少使用 0.1 个核心
        memory: 128Mi # 限制内存最少使用 128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制 cpu 最多使用 0.2 个核心
        memory: 256Mi # 限制 最多使用 256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

探针

类型

startupProbe

用于判断应用程序是否已经启动了

当配置了 startupProbe 后，会先禁用其他探针，直到 startupProbe 成功后，其他探针才会继续

spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
    startupProbe: # 启动探针
      httpGet: # 探测方式
        path: /api/startup
        port: 80

LivenessProbe

用于探测容器中的应用是否运行，如果探测失败，kubelet 会根据配置的重启策略进行重启，若没有配置，默认就认为容器启动成功，不会执行重启策略。

spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
    livenessProbe: # 存活探针
      failureThreshold: 5 # 失败次数
      httpGet: # 探测方式
        path: /health
        port: 8080
        scheme: HTTP
      initialDelaySeconds: 60 # 初始化时间
      periodSeconds: 10 # 监测间隔时间

ReadinessProbe

用于探测容器内的程序是否健康，它的返回值如果返回 success，那么就认为该容器已经完全启动，并且该容器是可以接收外部流量的。

spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
    readinessProbe: # 就绪探针
      failureThreshold: 3 # 错误次数
      httpGet: # 探测方式
        path: /ready
        port: 8181
        scheme: HTTP
      periodSeconds: 10 # 间隔时间
      successThreshold: 1 # 成功次数

探测方式

ExecAction

在容器内部执行一个命令，如果返回值为 0，则任务容器时健康的。
```
livenessProbe:
  exec:
    command:
      - cat
      - /health
```
TCPSocketAction

通过 tcp 连接监测容器内端口是否开放，如果开放则证明该容器健康
```
livenessProbe:
  tcpSocket:
    port: 80
```
HTTPGetAction

生产环境用的较多的方式，发送 HTTP 请求到容器内的应用程序，如果接口返回的状态码在 200~400 之间，则认为容器健康。
```
livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /health
    port: 8080
    scheme: HTTP
    httpHeaders:
      - name: xxx
```

参数配置

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

生命周期配置

spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
    lifecycle: # 生命周期配置
      postStart: # 容创建完成后执行的动作，不能保证该操作一定在容器的 command 之前执行，一般不使用
        exec: # 可以是 exec / httpGet / tcpSocket
          command:
            - sh
            - -c
            - 'mkdir /data'
      preStop: # 在容器停止前执行的动作
        httpGet: # 发送一个 http 请求
          path: /
          port: 80
        exec: # 执行一个命令
          command:
            - sh
            - -c
            - sleep 9

preStop

但是需要注意，由于 k8s 默认给 pod 的停止宽限时间为 30s，如果我们停止操作会超过 30s 时，不要光设置 sleep 50，还要将 terminationGracePeriodSeconds: 30 也更新成更长的时间，否则 k8s 最多只会在这个时间的基础上再宽限几秒，不会真正等待 50s

资源调度

Deployment

配置文件

apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
  labels: # 标签
    app: nginx-deploy # 具体的 key: value 配置形式
  name: nginx-deploy # deployment 的名字
  namespace: blog # 所在的命名空间
spec:
  replicas: 1 # 期望副本数
  revisionHistoryLimit: 10 # 进行滚动更新后，保留的历史版本数
  selector: # 选择器，用于找到匹配的 RS
    matchLabels: # 按照标签匹配
      app: nginx-deploy # 匹配的标签key/value
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时，更新的个数最多可以超过期望副本数的个数/比例
      maxUnavailable: 25% # 进行滚动更新时，最大不可用比例更新比例，表示在所有副本数中，最多可以有多少个不更新成功
    type: RollingUpdate # 更新类型，采用滚动更新
  template: # pod 模板
    metadata: # pod 的元信息
      labels: # pod 的标签
        app: nginx-deploy
    spec: # pod 期望信息
      containers: # pod 的容器
      - image: nginx:1.7.9 # 镜像
        imagePullPolicy: IfNotPresent # 拉取策略
        name: nginx-docker # 容器名称
      restartPolicy: Always # 重启策略
      terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间

滚动更新

只有修改了 deployment 配置文件中的 template 中的属性后，才会触发更新操作

查看滚动更新过程

# 修改deployment文件
[root@hcss-ecs-9883 /]# kubectl edit deployment <deployment_name>
# 查看滚动更新过程
[root@hcss-ecs-9883 /]# kubectl rollout status deploy <deployment_name>

回滚

# 获取 revison 的列表
[root@hcss-ecs-9883 /]# kubectl rollout history deployment/<deployment_name>
deployment.apps/nginx-deploy 
REVISION  CHANGE-CAUSE
1         <none>
# 回退到上一个版本
[root@hcss-ecs-9883 /]# kubectl rollout undo deployment/<deployment_name>
# 回退到指定的 revision
[root@hcss-ecs-9883 /]# kubectl rollout undo deployment/<deployment_name> --to-revision=2

扩容与缩容

通过 kube scale命令可以进行自动扩容/缩容

暂停与恢复

# 暂停更新
[root@hcss-ecs-9883 /]# kubectl rollout pause deployment <name> 
# 恢复更新
[root@hcss-ecs-9883 /]# kubectl rollout deploy <name>

StatefulSet

配置文件

--- # 表示在yaml文件中嵌套另一个yaml文件
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet # 资源类型
metadata:
  name: web # statefulSet的名字
spec:
  serviceName: "nginx" # 使用哪个Service来管理dns
  replicas: 1 # 期望副本数
  template:
    metadata:
      matchLabels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports: # 容器内部要暴露的端口
        - containerPort: 80 # 具体要暴露的端口号
          name: web # 该端口配置的名字
        volumeMounts: # 加载数据卷
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # 数据卷模板
  - metadata:
      name: www
      annotations:
        volume.alpha.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

扩容与缩容

通过 kube scale命令可以进行自动扩容/缩容

滚动更新

只有修改了 StatefulSet 配置文件中的 template 中的属性后，才会触发更新操作。由于 pod 是有序的，在 StatefulSet 中更新时是基于 pod 的顺序倒序更新的

更新

# statefulSet版本
[root@hcss-ecs-9883 /]# kubectl edit statefulSet <statefulSet_name>
# 查看滚动更新过程
[root@hcss-ecs-9883 /]# kubectl rollout status sts <statefulSet_name>

RollingUpdate

利用滚动更新中的 partition 属性，可以实现简易的灰度发布(金丝雀发布)的效果

例如我们有 5 个 pod，如果当前 partition 设置为 3，那么此时滚动更新时，只会更新那些序号 >= 3 的 pod
```
spec:
  updateStrategy: # 更新策略
  	rollingUpdate: # 滚动更新
  		partition: 0
  	type: RollingUpdate # 更新方案
```

OnDelete

只有在 pod 被删除时会进行更新操作

spec:
	updateStrategy: # 更新策略
  		type: OnDelete  # 更新方案

删除

级联删除：删除 statefulset 时会同时删除 pods

[root@hcss-ecs-9883 /]# kubectl delete statefulset <statefulset_name>
# 删除 service
[root@hcss-ecs-9883 /]# kubectl delete service <service_name>

非级联删除：删除 statefulset 时不会删除 pods，删除 sts 后，pods 就没人管了，此时再删除 pod 不会重建的

[root@hcss-ecs-9883 /]# kubectl deelte sts <statefulset_name> --cascade=false
# 删除 service
[root@hcss-ecs-9883 /]# kubectl delete service <service_name>

DaemonSet

示例图

配置文件

apiVersion: apps/v1
kind: DaemonSet # 创建DameonSet资源
metadata:
  name: fluentd # 名字
spec:
  selector: # 选择器，用于创建
  	mathcLabels:
  	  app: logging
  template:
    metadata:
      labels:
        app: logging
        id: fluentd
      name: fluentd
    spec:
      nodeSelector:
        svc_type: microsvc
      containers:
      - name: fluentd-es
        image: agilestacks/fluentd-elasticsearch:v1.3.0
        env: # 环境变量配置
         - name: FLUENTD_ARGS
           value: -qq
        volumeMounts: # 加载数据卷
         - name: containers
           mountPath: /var/lib/docker/containers
         - name: varlog
           mountPath: /varlog
      volumes: # 定义数据卷
         - hostPath:
             path: /var/lib/docker/containers
           name: containers
         - hostPath:
             path: /var/log
           name: varlog

向node添加标签

[root@hcss-ecs-9883 /]# kubectl label no <nodes_name> [label_key]=[label_value]

滚动更新

不建议使用 RollingUpdate，建议使用 OnDelete 模式，这样避免频繁更新 ds

HPA自动扩/缩容

开启指标服务

Kubectl top pods需要优先开启指标服务

[root@hcss-ecs-9883 /]# wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml
[root@hcss-ecs-9883 /]# sed -i 's/k8s.gcr.io\/metrics-server/registry.cn-hangzhou.aliyuncs.com\/google_containers/g' metrics-server-components.yaml
[root@hcss-ecs-9883 /]# vim metrics-server-components.yaml
### spec.template.spec
containers:
- args:
  ...
  - --kubelet-insecure-tls
  ...
###
[root@hcss-ecs-9883 /]# kubectl apply -f metrics-server-components.yaml
# 查看 pod 状态
[root@hcss-ecs-9883 /]# kubectl get pods --all-namespaces | grep metrics

前提操作

实现 cpu 或内存的监控，首先有个前提条件是该对象必须配置了 resources.requests.cpu 或 resources.requests.memory 才可以，可以配置当 cpu/memory 达到上述配置的百分比后进行扩容或缩容
```
### spec.template.spec.containers
resources:
  limits:
  	cpu: 100m
  	memory: 128Mi
  requests:
  	cpu: 100m
  	memory: 128Mi
###
```

执行命令

最少创建2个，最多创建5个pod

[root@hcss-ecs-9883 /]# kubectl autoscale {deploy|sts} {<deploy_name>|<sts_name>} --cpu-percent=20 --min=2 --max=5

获取HPA信息
```
[root@hcss-ecs-9883 /]# kubectl get hpa
```

服务发布

示例图

配置文件

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx-svc
spec:
  ports:
  - name: http # service 端口配置的名称
    protocol: TCP # 端口绑定的协议，支持 TCP、UDP、SCTP，默认为 TCP
    port: 80 # service 自己的端口，在使用内网ip时使用
    targetPort: 80 # 目标 pod 的端口
  - name: https
    port: 443 # Kubernetes中的服务之间访问的端口
    protocol: TCP
    targetPort: 443 # 容器的端口（最根本的端口入口），与制作容器时暴露的端口一致
    NodePort: 433 # 外部机器可访问的端口
  selector: # 选中当前 service 匹配哪些 pod，对哪些 pod 的东西流量进行代理
    app: nginx
  type: NodePort # 随机启动一个端口

Service定义

创建service

[root@hcss-ecs-9883 /]# kubectl create -f <service_file>.yaml

查看service信息
```
[root@hcss-ecs-9883 /]# kubectl get svc
```

创建其他 pod 通过 service name 进行访问

# 例如
[root@hcss-ecs-9883 /]# kubectl exec -it busybox -- sh
[root@hcss-ecs-9883 /]# curl http://nginx-svc
# 默认在当前 namespace 中访问，如果需要跨 namespace 访问 pod，则在 service name 后面加上 .<namespace> 即可
[root@hcss-ecs-9883 /]# curl http://nginx-svc.default

代理k8s外部服务

配置文件

编写 service 配置文件时，不指定 selector 属性，自己创建 endpoint

各环境访问名称统一
访问k8s集群外的其他服务
项目迁移

apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: wolfcode-svc-external # 与 service 一致
  name: wolfcode-svc-external # 与 service 一致
  namespace: default # 与 service 一致
subsets:
- addresses:
  	- ip: <target ip> # 目标 ip 地址
  ports: # 与 service 一致
  	- name: http
      port: 80
      protocol: TCP

ingress-nginx

配置文件

apiVersion: networking.k8s.io/v1
kind: Ingress # 资源类型为 Ingress
metadata:
  name: wolfcode-nginx-ingress
  annotations:
    # 指定 Ingress Controller 的类型
    kubernetes.io/ingress.class: "nginx"
    # 指定我们的 rules 的 path 可以使用正则表达式
    nginx.ingress.kubernetes.io/use-regex: "true"
    # 连接超时时间，默认为 5s
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
    # 后端服务器回转数据超时时间，默认为 60s
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
    # 后端服务器响应超时时间，默认为 60s
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    # 客户端上传文件，最大大小，默认为 20m
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    # URL 重写
    nginx.ingress.kubernetes.io/rewrite-target: /
spec: 
  rules: # ingress 规则配置，可以配置多个
  - host: k8s.wolfcode.cn # 域名配置，可以使用通配符 *
    http:
      paths: # 相当于 nginx 的 location 配置，可以配置多个
      - pathType: Prefix # 路径类型，按照路径类型进行匹配 ImplementationSpecific 需要指定 IngressClass，具体匹配规则以 IngressClass 中的规则为准。Exact：精确匹配，URL需要与path完全匹配上，且区分大小写的。Prefix：以 / 作为分隔符来进行前缀匹配
        backend:
          service: 
            name: nginx-svc # 代理到哪个 service
            port: 
              number: 80 # service 的端口
        path: /api # 等价于 nginx 中的 location 的路径前缀匹配

常用类型

ClusterIP：只能在集群内部使用，不配置类型的话默认就是 ClusterIP
ExternalName：返回定义的 CNAME 别名，可以配置为域名
NodePort：配置指定端口，需要在30000~32767端口范围内，如果不指定会随机指定端口。该端口直接绑定在Node上，且集群中的每一个node都会绑定这个端口
LoadBalancer：使用云服务商（阿里云、腾讯云等）提供的负载均衡器服务

配置管理

使用

###spec.containers
volumeMounts: # 加载数据卷
  - name: db-config # 表示加载volumes属性中哪个数据卷
    mountPath: "/usr/local/..." # 想要将数据卷中的文件加载到哪个目录下
    readOnly: true # 是否只读
### spec
volumes: # 数据卷挂载 configmap、secret
  - name: db-config # 数据卷的名字 
    configMap: # 数据卷的类型
      name: test-dir-config # configMap的名字，必须跟想要加载的configmap相同
      items: # 对configmap中的key进行映射，如果不指定，默认会将configmap中的所有key全部转换为一个个同名的文件
      - key: "db.properties" # configMap中的key
        path: "db.properties" # 将该key的值转换为文件

ConfigMap

一般用于去存储 Pod 中应用所需的一些配置信息，或者环境变量，将配置于 Pod 分开，避免应为修改配置导致还需要重新构建镜像与容器。

使用 ConfigMap 或 Secret 挂载到目录的时候，会将容器中源目录给覆盖掉

命令

查看创建示例

[root@hcss-ecs-9883 /]# kubectl create configmap -h

根据指定的文件创建ConfigMap

[root@hcss-ecs-9883 /]# kubectl create configmap <configMap_name> --from-file=<key>=<file_address.yaml>

SubPath

覆盖目录中的某一个文件，要使用到 SubPath

修改配置使用的文件即可

持久化存储

Volumes

使用

###spec.containers
volumeMounts: # 加载数据卷
  - name: test-volume # 表示加载volumes属性中哪个数据卷
    mountPath: "/usr/local/..." # 想要将数据卷中的文件加载到pod哪个目录下
### spec
volumes: # 数据卷挂载 configmap、secret
  - name: test-volume # 数据卷的名字 
    hostPath: # 与主机共享目录，加载主机中的指定目录到容器中
      path: /data # 节点中的目录
      type: Directory # 检查类型

HostPath

将节点上的文件或目录挂载到 Pod 上，此时该目录会变成持久化存储目录，即使 Pod 被删除后重启，也可以重新加载到该目录，该目录下的文件不会丢失
- 空字符串：默认类型，不做任何检查
- DirectoryOrCreate：如果给定的 path 不存在，就创建一个 755 的空目录
- Directory：这个目录必须存在
- FileOrCreate：如果给定的文件不存在，则创建一个空文件，权限为 644
- File：这个文件必须存在
- Socket：UNIX 套接字，必须存在
- CharDevice：字符设备，必须存在
- BlockDevice：块设备，必须存在
EmptyDir

EmptyDir 主要用于一个 Pod 中不同的 Container 共享数据使用的，由于只是在 Pod 内部使用，因此与其他 volume 比较大的区别是，当 Pod 如果被删除了，那么 emptyDir 也会被删除。
```
### spec
volumes: # 数据卷挂载 configmap、secret
  - name: test-volume # 数据卷的名字 
    emptyDir: {}
```

NFS

nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。

安装

# 安装 nfs
[root@hcss-ecs-9883 /]# yum install nfs-utils -y
# 启动 nfs
[root@hcss-ecs-9883 /]# systemctl start nfs-server
# 创建共享目录
[root@hcss-ecs-9883 /]# mkdir -p /data/nfs && cd /data/nfs && mkdir rw && mkdir ro
# 设置共享目录 export
[root@hcss-ecs-9883 /]# vim /etc/exports
###
/data/nfs/rw 192.168.113.0/24(rw,sync,no_subtree_check,no_root_squash)
/data/nfs/ro 192.168.113.0/24(ro,sync,no_subtree_check,no_root_squash)
###
# 重新加载
[root@hcss-ecs-9883 /]# exportfs -f
[root@hcss-ecs-9883 /]# systemctl reload nfs-server
# 到其他测试节点安装 nfs-utils 并加载测试
[root@hcss-ecs-9883 /]# mkdir -p /mnt/nfs/rw
[root@hcss-ecs-9883 /]# mount -t nfs 192.168.113.121:/data/nfs/rw /mnt/nfs/rw

使用

###spec.containers
volumeMounts: # 加载数据卷
  - name: test-nfs # 表示加载volumes属性中哪个数据卷
    mountPath: "/usr/local/..." # 想要将数据卷中的文件加载到pod哪个目录下
### spec
volumes: # 数据卷挂载 configmap、secret
  - name: test-volume
    nfs:
      server: my-nfs-server.example.com # 网络存储服务地址
      path: /my-nfs-volume # 网络存储路径
      readOnly: true # 是否只读

PV

持久卷（PersistentVolume，PV） 是集群中的一块存储，可以由管理员事先制备，或者使用存储类（Storage Class）来动态制备。持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。

配置文件

### spec
capacity: # 容量配置
  storage: 5Gi # pv 的容量
volumeMode: Filesystem # 存储类型为文件系统
accessModes: # 访问模式：ReadWriteOnce、ReadWriteMany、ReadOnlyMany
  - ReadWriteOnce # 可被单节点独写
persistentVolumeReclaimPolicy: Recycle # 回收策略
storageClassName: slow # 创建 PV 的存储类名，需要与 pvc 的相同
mountOptions: # 加载配置
  - hard
  - nfsvers=4.1
nfs: # 连接到 nfs
  path: /data/nfs/rw/test-pv # 存储路径
  server: 192.168.113.121 # nfs 服务地址

创建

[root@hcss-ecs-9883 /]# kubectl create -f <pv_file>

状态
- Available：空闲，未被绑定
- Bound：已被pvc绑定
- Released：PVC被删除，资源已回收，且PV未被重新使用
- Failed：自动回收失败

PVC

持久卷申领（PersistentVolumeClaim，PVC） 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式（例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。

配置文件

### spec
  accessModes:
    - ReadWriteOnce # 权限需要与对应的 pv 相同
volumeMode: Filesystem
resources:
  requests:
    storage: 8Gi # 资源可以小于 pv 的，但是不能大于，如果大于就会匹配不到 pv
storageClassName: slow # 名字需要与对应的 pv 相同
#  selector: # 使用选择器选择对应的 pv
#    matchLabels:
#      release: "stable"
#    matchExpressions:
#      - {key: environment, operator: In, values: [dev]}

创建

[root@hcss-ecs-9883 /]# kubectl create -f <pvc_file>

使用

###spec.containers
volumeMounts: # 加载数据卷
  - name: test-nfs # 表示加载volumes属性中哪个数据卷
    mountPath: "/usr/local/..." # 想要将数据卷中的文件加载到pod哪个目录下
### spec
volumes: # 数据卷挂载 configmap、secret
  - name: test-pvc
    persistentVolumeClaim:
      claimName: pvc-name

StroageClass

高级调度

初始化窗口

InitContainer

在真正的容器启动之前，先启动 InitContainer，在初始化容器中完成真实容器所需的初始化操作，完成后再启动真实的容器。

配置文件

spec:
  initContainers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    command: ["sh", "-c", "echo 'inited;' >> ~/.init"]
    name: init-test

污点 Taint

污点：是标注在节点上的，当我们在一个节点上打上污点以后，k8s 会认为尽量不要将 pod 调度到该节点上，除非该 pod 上面表示可以容忍该污点，且一个节点可以打多个污点，此时则需要 pod 容忍所有污点才会被调度该节点。

# 为节点打上污点
[root@hcss-ecs-9883 /]# kubectl taint node k8s-master key=value:NoSchedule
# 移除污点
[root@hcss-ecs-9883 /]# kubectl taint node k8s-master key=value:NoSchedule-
# 查看污点
[root@hcss-ecs-9883 /]# kubectl describe no k8s-master

污点的影响

NoSchedule：不能容忍的 pod 不能被调度到该节点，但是已经存在的节点不会被驱逐
NoExecute：不能容忍的节点会被立即清除，能容忍且没有配置 tolerationSeconds 属性，则可以一直运行，设置了 tolerationSeconds: 3600 属性，则该 pod 还能继续在该节点运行 3600 秒

容忍 Toleration

容忍：是标注在 pod 上的，当 pod 被调度时，如果没有配置容忍，则该 pod 不会被调度到有污点的节点上，只有该 pod 上标注了满足某个节点的所有污点，则会被调度到这些节点

# pod 的 spec 下面配置容忍
tolerations:
- key: "污点的 key"
  value: "污点的 value"
  offect: "NoSchedule" # 污点产生的影响
  operator: "Equal" # 表是 value 与污点的 value 要相等，也可以设置为 Exists 表示存在 key 即可，此时可以不用配置 value

亲和力 Affinity

NodeAffinity

节点亲和力：进行 pod 调度时，优先调度到符合条件的亲和力节点上

配置模板

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity: # 亲和力配置
    nodeAffinity: # 节点亲和力
      requiredDuringSchedulingIgnoredDuringExecution: # 节点必须匹配下方配置
        nodeSelectorTerms: # 选择器
        - matchExpressions: # 匹配表达式
          - key: topology.kubernetes.io/zone # 匹配 label 的 key
            operator: In # 匹配方式，只要匹配成功下方的一个 value 即可
            values:
            - antarctica-east1 # 匹配的 value
            - antarctica-west1 # 匹配的 value
      preferredDuringSchedulingIgnoredDuringExecution: # 节点尽量匹配下方配置
      - weight: 1 # 权重[1,100]，按照匹配规则对所有节点累加权重，最终之和会加入优先级评分，优先级越高被调度的可能性越高
        preference:
          matchExpressions: # 匹配表达式
          - key: another-node-label-key # label 的 key
            operator: In # 匹配方式，满足一个即可
            values:
            - another-node-label-value # 匹配的 value
#      - weight: 20
        ......
  containers:
  - name: with-node-affinity
    image: pause:2.0

匹配类型 operator
- In：部署在满足条件的节点上
- NotIn：匹配不在条件中的节点，实现节点反亲和性
- Exists：只要存在 key 名字就可以，不关心值是什么
- DoesNotExist：匹配指定 key 名不存在的节点，实现节点反亲和性
- Gt：value 为数值，且节点上的值小于指定的条件
- Lt：value 为数值，且节点上的值大于指定条件