# 一、deployemnt基础命令
## 1.查看全部的deployemnt
```js
kubectl get deploy -A
```

![image.png](/static/img/8be3a5759af3b7b26b91264ef75420d1.image.webp)



## 2.查看deployemnt的情况
```js
kubectl describe deploy example-app
```

![image.png](/static/img/7657370441ae963fdac42484bb4a8972.image.webp)

## 3.输出到文件中
```js
kubectl get deploy example-app -o yaml >> test.yaml
```

# 二、deployemnt扩缩容
## 1.该deployemnt有三个副本，我要把他变成10个

![image.png](/static/img/d555314739686833ff75eab8081cedb9.image.webp)

## 2.把deployemnt扩成10个副本，同理缩容只需要改变以下数字即可。
```js
kubectl scale deploy example-app --replicas=10
```

![image.png](/static/img/6ecb409b0e06a677e147e90e0e7dcb46.image.webp)

# 三、deployemnt版本回退控制
## 1.当我更换yml配置文件中的镜像版本时候，查看历史版本命令

![image.png](/static/img/840dadf4aa93394f817ba0f50dfc593a.image.webp)
```js
kubectl rollout history deploy example-app
```
## 2.查看指定历史版本信息更新了什么

![image.png](/static/img/25e71b620caa2fdcf5c9014439b437b3.image.webp)
```js
kubectl rollout history deploy example-app --revision=2
```

## 3.回滚到上个版本

![image.png](/static/img/5500007532641322bcc0008c465d41e7.image.webp)
**当回滚到上个版本后，版本号的1就变成3，因为里面的内容是一样的，只会变更版本号，版本1就没有了。**
```js
kubectl rollout undo deploy example-app
```
## 4.回滚到指定版本

![image.png](/static/img/efa1d7e2ef2d7bbc0f22f9959d6ac171.image.webp)

```js
kubectl rollout undo deploy example-app --to-revision=2
```

## 5.其他很少用到的命令

```js
# 重新部署
kubectl rollout restart deploy example-app
# 暂停运行，暂停后，对 deployment 的修改不会立刻生效，恢复后才应用设置
kubectl rollout pause deploy example-app
# 恢复
kubectl rollout resume deploy example-app
```
# 五、删除deployemnt

```js
# 删除 Deployment
kubectl delete deploy example-app
kubect delete -f k8s06.yml

# 删除默认命名空间下全部资源
kubectl delete all --all

# 删除指定命名空间的资源
kubectl delete all --all -n 命名空间的名称
```


9.deployemnt

# 一、节点调度pod
## 1.使用nodeSelector标签方式分配节点

![image.png](/static/img/901c7f7eeb0e8f044ece8d12a4dfb7e4.image.webp)

先用命令查询出K8S集群node的标签
```js
kubectl get nodes --show-labels
```
然后给对应的节点添加标签

```js
kubectl label nodes k8s-node01  name=songxuan01
```
```js
kubectl label nodes k8s-node02  name=songxuan02
```
然后给yml文件nodeSelector中的打上对应标签，该pod就会分配到该节点了
```yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx01
  labels:
    name: songxuan01
spec:
  containers:
    - name: nginx01
      image: nginx:1.14.2
      ports:
        - containerPort: 80
      imagePullPolicy: IfNotPresent
  nodeSelector:
    name: songxuan01
  restartPolicy: Always
```

```yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx02
  labels:
    name: songxuan02
spec:
  containers:
    - name: nginx02
      image: nginx:1.14.2
      ports:
        - containerPort: 80
      imagePullPolicy: IfNotPresent
  nodeSelector:
    name: songxuan02
  restartPolicy: Always

```
**然后查看这两个pod都分配到对应的节点了**
![image.png](/static/img/d6ff0d7a88a54b54ac88f339ce91e5ba.image.webp)



:::note{title="注意"}
如果yml文件中打的标签中找不到有对应标签的node节点就会一直是Pending的状态
:::

## 2.使用nodeName指定node节点
使用nodeName: k8s-node02指定到对应节点

```yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx03
  labels:
    name: songxuan03
spec:
  containers:
    - name: nginx03
      image: nginx:1.14.2
      ports:
        - containerPort: 80
      imagePullPolicy: IfNotPresent
  nodeName: k8s-node02  #指定node节点的名称
  restartPolicy: Always
```
启动pod后，该pod已经在我指定的节点上运行。

![image.png](/static/img/1020bd78a740b496622dcd42d5c7a4f8.image.webp)



# 二、亲和性和反亲和性
## 1.亲和性中的硬亲和性requiredDuringSchedulingIgnoredDuringExecutio

```yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx01
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: #硬亲和性要求
        nodeSelectorTerms:
        - matchExpressions:
          - key: name        #标签为name
            operator: In     #包含
            values:
            - songxuan01     #值为songxuan01
  containers:
  - name: nginx
    image: nginx:1.19
```
**使用requiredDuringSchedulingIgnoredDuringExecutio硬亲和性，工作节点标签必须有name标签并且包含songxuan01的值，才能分配到该节点，不然一样会Pending的状态**

![image.png](/static/img/5389d883e18cfe5299cd92cd99e0f987.image.webp)

## 2.亲和性中的软亲和性preferredDuringSchedulingIgnoredDuringExecution

```yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx02
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution: #软亲和性要求
        - preference:
            matchExpressions:
              - key: name
                operator: In
                values:
                  - songxuan02
          weight: 90           #90权重分配到name标签值为songxuan02的节点上
  containers:
  - name: nginx
    image: nginx:1.19
```
**使用preferredDuringSchedulingIgnoredDuringExecution软亲和性，会优先调配到满足条件的节点上，如果没有节点满足条件就会随机分配到任意节点上，不会像硬亲和性一样如果不满足条件就会Pending状态。**

## 3.亲和性中硬亲和性和软亲和性同时使用

```yml
# 定义Kubernetes API版本和资源类型
apiVersion: apps/v1  # 使用apps/v1版本的API
kind: Deployment     # 定义这是一个Deployment资源

# 元数据部分
metadata:
  name: example-app  # Deployment的名称为example-app
  labels:            # 为Deployment添加标签
    name: songxuan01 # 键值对标签，标识这个应用

# Deployment的规格定义
spec:
  replicas: 3  # 指定需要运行的Pod副本数量为3个

  # 选择器，用于匹配要管理的Pod
  selector:
    matchLabels:
      name: songxuan01  # 选择带有name=songxuan01标签的Pod

  # Pod模板，定义如何创建Pod
  template:
    metadata:
      labels:
        name: songxuan01 # 为Pod添加标签，与selector匹配
    spec:
      # 容器定义
      containers:
      - name: nginx       # 容器名称
        image: nginx:1.19 # 使用nginx 1.19版本的镜像
        ports:
        - containerPort: 80  # 容器暴露的端口号

      # 亲和性调度规则
      affinity:
        nodeAffinity:  # 节点亲和性规则
          # 必须满足的条件(硬性要求)
          requiredDuringSchedulingIgnoredDuringExecution:

            nodeSelectorTerms:
            - matchExpressions:
              - key: name  # 标签
                operator: In  # 操作符，表示值必须在指定列表中
                values:
                - songxuan01  # 必须部署在songxuan01


          # 优先满足的条件(软性偏好)
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 80  # 权重为80(相对权重)
            preference:
              matchExpressions:
              - key: name # 标签
                operator: In
                values:
                - songxuan02  # 优先选择有songxuan02的节点
```

![image.png](/static/img/939b0518d0fc40554ebe9045a98bab61.image.webp)

**requiredDuringScheduling(硬性要求)优先级高于preferredDuringScheduling(软性偏好)，如果都满足了要求，硬性要求则会优先；如果都无法满足要求，存在软亲和性会随机分配到某个节点上。**

![image.png](/static/img/74239e1e0b5b529042c9949e4ec40343.image.webp)

## 4.亲和性的 topologyKey

```yml
apiVersion: v1
kind: Pod
metadata:
  name: web-server
  labels:
    app: web-server
    tier: frontend
spec:
  affinity:
    # 硬性亲和性 - 确保相同Pod不运行在同一节点
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: name
            operator: In
            values:
            - songxuan01
        topologyKey: "name"   #选择为name的区域
    
    # 软性亲和性 - 优先但不强制调度到特定区域
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100  # 权重值(1-100)
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: name
              operator: In
              values:
              - songxuan02
          topologyKey: "name"
    
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
```

# 三、
## 1.节点封锁
标记节点为 SchedulingDisabled，阻止新 Pod 调度到该节点，但已有 Pod 不受影响。

```js
# 禁止调度
kubectl cordon <node-name>

# 恢复调度
kubectl uncordon <node-name>
```
## 2.节点污点
通过污点阻止不匹配容忍度的 Pod 调度到节点。
```js
kubectl taint nodes <node-name> key=value:NoSchedule  # 添加污点阻止调度 
kubectl taint nodes <node-name> key:NoSchedule-        # 移除污点
```
## 3.节点驱逐
驱逐节点上所有 Pod 并同时禁止调度。

```js
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force
```

8.节点调度策略

Init 容器是一种特殊容器，在Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。

## 1.init 容器特点
init 容器与普通的容器非常像，除了如下几点：

- 它们总是运行到完成。如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。
- 每个都必须在下一个启动之前成功完成。
- 同时 Init 容器不支持 `lifecycle`、`livenessProbe`、`readinessProbe` 和 `startupProbe`， 因为它们必须在 Pod 就绪之前运行完成。
- 如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。
- Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同。

## 2.使用init容器
在 Pod 的规约中与用来描述应用容器的 `containers` 数组平行的位置指定 Init 容器。
```yml
apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'echo init-myservice is running! && sleep 5']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'echo init-mydb is running! && sleep 10']
```


7.init容器

## 1.安装metrics-server插件

```yml
# components.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
  - apiGroups:
      - metrics.k8s.io
    resources:
      - pods
      - nodes
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/metrics
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - pods
      - nodes
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
  - kind: ServiceAccount
    name: metrics-server
    namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - kind: ServiceAccount
    name: metrics-server
    namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
  - kind: ServiceAccount
    name: metrics-server
    namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
        - args:
            - --cert-dir=/tmp
            - --secure-port=4443
            - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
            - --kubelet-use-node-status-port
            - --metric-resolution=15s
            - --kubelet-insecure-tls #修改去掉证书验证
          image: dyrnq/metrics-server:v0.6.2 #修改官方无法下载
          imagePullPolicy: IfNotPresent
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /livez
              port: https
              scheme: HTTPS
            periodSeconds: 10
          name: metrics-server
          ports:
            - containerPort: 4443
              name: https
              protocol: TCP
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /readyz
              port: https
              scheme: HTTPS
            initialDelaySeconds: 20
            periodSeconds: 10
          resources:
            requests:
              cpu: 100m
              memory: 200Mi
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 1000
          volumeMounts:
            - mountPath: /tmp
              name: tmp-dir
      hostNetwork: true  #必须指定这个才行
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
        - emptyDir: {}
          name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100
```

## 2.创建一个容器，限制请求内存和最大内存限制。

```yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-memory-demo
spec:
  containers:
  - name: nginx-memory-demo
    image: nginx:1.19
    resources:
      requests:
        memory: "100Mi" 
      limits:
        memory: "200Mi"
```

## 3.查看pod的使用CPU和内存情况

![image.png](/static/img/2ce900ff468dbab1d2f5c82b801fc408.image.webp)

```js
kubectl top pod
```


## 4.创建一个容器，限制请求CPU和最大CPU限制。

```yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-cpu-demo
spec:
  containers:
  - name: nginx-cpu-demo
    image: nginx:1.19
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
```

6.容器资源限制

## 1.exec探针

```yml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    exec: exec
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;" #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:    #这里使用 exec 执行 shell 命令检测容器状态
        command:  
        - ls
        - /var/run/nginx.pid  #查看是否有pid文件
      initialDelaySeconds: 5   #初始化时间5s
      periodSeconds: 4    #检测间隔时间4s
      timeoutSeconds: 1   #默认检测超时时间为1s
      failureThreshold: 3   #默认失败次数为3次，达到3次后重启pod
      successThreshold: 1   #默认成功次数为1次，1 次代表成功
```

```js
该yml配置文件说明：exec探针会去该路径下检查nginx是否有pid文件生成。
 initialDelaySeconds: 5 容器启动五秒后开始检测
 periodSeconds: 4 检测时间为4秒一次
 failureThreshold: 3   检测3次失败将会重启pod
  successThreshold: 1 当1次检测到有pid文件时就会成功
```


## 2.TCP socket 探针

```yml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcpsocket
  labels:
    tcpsocket: tcpsocket
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;"  #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5   #初始化时间5s
      periodSeconds: 4    #检测间隔时间4s
      timeoutSeconds: 1   #默认检测超时时间为1s
      failureThreshold: 3   #默认失败次数为3次，达到3次后重启pod
      successThreshold: 1   #默认成功次数为1次，1 次代表成功
```

```js
tcpSocket探针它会监控你指定的端口是否存活，如配置文件检测80端口是否存活。
```

## 3.HTTP GET 探针

```yml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  labels:
    httpget: httpget
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;" #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:     #httpget
        port: 80   #访问的端口
        path: /index.html   #访问的路径
      initialDelaySeconds: 5   #初始化时间5s
      periodSeconds: 4    #检测间隔时间4s
      timeoutSeconds: 1   #默认检测超时时间为1s
      failureThreshold: 3   #默认失败次数为3次，达到3次后重启pod
      successThreshold: 1   #默认成功次数为1次，1 次代表成功
```
```js
HTTP GET 探针会发送一个get请求访问你指定的路径端口，如果返回200-399状态码为成功。
```

## 总结

```txt
‌TCP Socket 探针‌
向容器指定端口发起 TCP 连接（三次握手）。若端口成功打开，则判定为健康示例配置：仅需指定端口号。

‌HTTP GET 探针‌
向容器指定端口和 HTTP 路径发送 GET 请求。若响应状态码为 200-399，则判定为健康示例配置：
需指定端口、路径（如 /healthz），可自定义请求头。

‌Exec 探针‌
在容器内执行指定命令（如脚本或程序）。若命令退出状态码为 0，则判定为健康示例配置：
需定义完整的 Shell 命令（如 check_db.sh）。
```