标签：kubectl name 04 ## 介绍 yaml 组件 Pod pod

k8s里的资源对象

在k8s里，yaml用来声明API对象的，那么API对象都有哪些？
可以这样查看资源对象
kubectl api-resources

yaml

使用缩进表示层次，缩进不允许使用tab，只能用空格，缩进空格数多少不要求，只要保证同一层级空格数一样多即可
使用 # 书写注释
数组（列表）是使用 - 开头的清单形式
对象（字典）的格式与JSON基本相同，但Key不需要使用双引号。
表示对象的 : 和表示数组的 - 后面都必须要有空格。
可以使用 --- 在一个文件里分隔多个YAML对象

![[yaml基本介绍.png]]

yaml简单使用

01、运行一个pod
可以使用kubectl命令快速启动一个pod
kubectl run pod-demo --image=busybox
说明：Pod名字为pod-demo，镜像为busybox

然后从已知的pod到处yaml文件：
kubectl get pod pod-demo -o yaml > pod-demo.yaml

创建一个deployment

kubectl create deployment testdp --image=nginx:1.23.2
##deploymnet名字为testdp 镜像为nginx:1.23.2

## 查看deployment
kubectl get deployment

## 查看Pod
kubectl get pods

## 查看Pod详情
kubectl describe pod testdp-68dc848667-6cz67

## 创建service，暴漏pod端口到node节点上
kubectl expose deployment testdp --port=80 --type=NodePod --target-port=80 --name=testsvc
The Service "testsvc" is invalid: spec.type: Unsupported value: "NodePod": supported values: "ClusterIP", "ExternalName", "LoadBalancer", "NodePort"

## 有问题没解决

以下为一个pod的yaml文件示例内容：

apiVersion: v1
kind: Pod
metadata:
  name: ngx-pod
  namespace: aming
  labels:  ## labels字段非常关键，它可以添加任意数量的Key-Value，目的是为了让pod的信息更加详细
    env: dev
spec:  ##用来定义该pod更多的资源信息，比如containers, volume, storage
  containers:  ##定义容器属性
  - image: nginx:1.23.2
    imagePullPolicy: IfNotPresent  ##镜像拉取策略，三种：Always/Never/IfNotPresent，一般默认是IfNotPresent，也就是说只有本地不存在才会远程拉取镜像，可以减少网络消耗。
    name: ngx
    env:  ##定义变量，类似于Dockerfile里面的ENV指令
      - name: os
        value: "Rocky Linux"
    ports:
    - containerPort: 80

这个yaml文件，可以创建一个临时pod导出一个模板yaml文件
然后基于模板yaml去修改即可

03、基于yaml文件创建和删除pod
工作中创建pod，更多的是基于yaml来创建。而非使用bukectl命令
创建:
kubectl apply -f ngx-pod.yaml
删除:
kubectl delete -f ngx-pod.yaml

04、查看pod信息
常见的观察和管理pod方法
列出pod：

列出默认命名空间的pod

`kubectl get pod`

列出kube-system命名空间的pod

kubectl get pod -n kube-system

查看pod的详细信息：
kubectl describe pod ngx-pod
可以看到pod的相关信息，比如镜像是什么、IP是什么、pod的创建日志等

查看pod日志：

kubectl logs ngx-pod

##动态查看日志，类似于tail -f
kubectl logs -f ngx-pod

##查看最后100行日志
kubectl logs --tail=100 ngx-pod

一、API资源对象Pod

Pod原理和生命周期

Pod为k8s里最小、最简单的资源对象。它和docker容器还是有一定区别的，它比容器单元更大一些，也就是说在Pod里面会包含容器，一个pod里面可以有多个容器。
![[pod对象01.png]]

1.pod原理

Pod 是在 K8s集群中运行部署应用或服务的最小单元。
在同一个Pod中其实可以同时运行多个容器，这些容器能够共享网络、存储以及 CPU/内存等资源。
每个Pod都有一个特殊的被称为 “根容器” 的Pause容器。Pause容器的主要作用是为Pod中的其他容器提供一些基本的功能，比如网络和PID命名空间的共享、负责管理Pod内其他容器的生命周期。
网络命名空间共享：pause容器为整个Pod创建一个网络命名空间，Pod内的其他容器都将加入这个网络命名空间。这样，Pod中的所有容器都可以共享同一个IP地址和端口空间，从而实现容器间的紧密通信。
PID命名空间共享：pause容器充当Pod内其他容器的父容器，它们共享同一个PID命名空间。这使得Pod内的容器可以通过进程ID直接发现和相互通信，同时也使得Pod具有一个统一的生命周期。
生命周期管理：pause容器作为Pod中其他容器的父容器，负责协调和管理它们的生命周期。当pause容器启动时，它会成为Pod中其他容器的根容器。当pause容器终止时，所有其他容器也会被自动终止，确保了整个Pod的生命周期的一致性。
保持Pod状态：pause容器保持运行状态，即使Pod中的其他容器暂时停止或崩溃，也可以确保
Pod保持活跃。这有助于Kubernetes更准确地监视和管理Pod的状态。

2.pod生命周期

Pod生命周期包括以下几个阶段：

Pending：在此阶段，Pod已被创建，但尚未调度到运行节点上。此时，Pod可能还在等待被调度，或者因为某些限制（如资源不足）而无法立即调度。
Running：在此阶段，Pod已被调度到一个节点，并创建了所有的容器。至少有一个容器正在运行，或者正在启动或重启。
Succeeded：在此阶段，Pod中的所有容器都已成功终止，并且不会再次重启。
Failed：在此阶段，Pod中的至少一个容器已经失败（退出码非零）。这意味着容器已经崩溃或以其他方式出错。
Unknown：在此阶段，Pod的状态无法由Kubernetes确定。这通常是因为与Pod所在节点的通信出现问题。

除了这些基本的生命周期阶段之外，还有一些更详细的容器状态，用于描述容器在Pod生命周期中的不同阶段：

ContainerCreating：容器正在创建，但尚未启动。
Terminating：容器正在终止，但尚未完成。
Terminated：容器已终止。
Waiting：容器处于等待状态，可能是因为它正在等待其他容器启动，或者因为它正在等待资源可用。
Completed：有一种Pod是一次性的，不需要一直运行，只要执行完就会是此状态。

Pod创建

Pod删除

pod资源限制

01、Resource Quota

资源配额Resource Quotas（简称quato）是对namespace进行资源配额，限制资源使用的一种策略。

k8s是一个多用户架构，当多用户或者团队共享一个k8s系统时，SA使用quota防止用户（基于namespace的）的资源抢占，定义好资源分配策略。

Quota应用在namespace上，默认情况下，没有resource quota 的，需要另外创建quota，并且每个namespace最多只能有一个quota对象。

resource quota可限定资源类型，主要有三大类：计算资源、存储资源以及资源个数。

计算资源：
主要针对CPU和内存的限制
limit.cpu | requests.cpu | limits.memory | requests.memory

存储资源：
包括存储资源的总量以及指定storage class的总量
request.storage:存储资源总量，如500Gi
persistentvolumeclaims：pvc的个数

对象数：
即可创建的对象个数
pods,replicationcontrollers,configmaps,secrets,
persistentvolueclaims,services,
services.loadbalancers,service.nodeports

resource quota 依赖于资源管理器，可以使用资源对象limits或者在创建资源对象时为pod设置资源限制（resources），如果不设置，资源对象无法创建。

当该namespace中的任意个额度达到预设Quota时，将无法创建资源对象。

resource quota示例

cat > quota.yaml <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  namespace: aming
  name: aming-quota

spec:
  hard:
    pods: 50 ## 该命名空间里最多支持启动50个Pods
    requests.cpu: 0.5 ##最低保证0.5个CPU资源
    requests.memory: 512Mi ##最低保证512M内存
    limits.cpu: 5 ##最多使用5核CPU
    limits.memory: 16Gi ##最多使用16G内存
    configmaps: 20 ##最多支持20个configMaps
    persistentvolumeclaims: 20 ##最多支持20个pvc
    replicationcontrollers: 20 ##最多支持20个replicationControllers
    secrets: 20 ##最多支持20个secrets
    services: 50 ##最多支持50个services
EOF

##############################
## 生效
kubectl apply -f quota.yaml

## 查看
kubectl get quota -n aming

测试

为了显示限额效果，修改quota.yaml，将pod限制数改为5，其它先删除掉

命令行创建deployment，指定Pod副本为7

kubectl create deployment testdp --image=nginx:1.23.2 -n aming --replicas=7

查看deployment和pod

kubectl get deploy,po -n aming

02、pod 的 limits 和 requests

resources quota 是针对namespace下面所有的pod的限制，而pod本身也有限制。

eg：

cat > quota-pod.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: quota-pod
  namespace: aming

spec:
  containers:
  - image: nginx:1.23.2
    name: ngx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    resources:
      limits:
        cpu: 0.5  ##限制Pod CPU资源最多使用500m，这里的0.5=500m，1=1000m
        memory: 2Gi ##限制内存资源最多使用2G
      requests:
        cpu: 200m  ##K8s要保证Pod使用的最小cpu资源为200m，如果node上资源满足不了，则不会调度到该node上
        memory: 512Mi ##K8s要保证Pod使用最小内存为512M，如果node上资源满足不了，则不会调度到该node上
EOF

limits重在限制，意思为不允许超过这么多
requests重在保障，意思是至少要给到这么多

二、Deployment

deployment YAML示例

vim ng-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ng-deploy
  labels:
    app: myng
spec:
  replicas: 2  # 副本数
  selector:
    matchLabels:
      app: myng
  template:
    metadata:
      labels:
        app: myng
    spec:
      containers:
      - name: myng
        image: nginx:1.23.2
        ports:
        - name: myng-port
          containerPort: 80

## 使用YAML創建deploy
kubectl apply -f ng-deploy.yaml
## 查看
kubectl get deploy
kubectl get po
## 查看pod分配到哪个节点上
kubectl get po -o wide

![[Pasted image 20240724150349.png]]

三、Service

Service（简称：svc）YAML示例

vim ng-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: ngx-svc
spec:
  selector:
    app: myng
  ports:
  - protocol: TCP
    port: 8080  # Service 的端口号，服务访问的端口
    targetPort: 80  # Pod 的端口号，实际容器监听的端口

## 使用yaml創建service
kubectl apply -f ng-svc.yaml

## 查看
kubectl get svc

SVC三种类型

1.ClusterIP

该方式为默认类型，即不定义type字段时，（如上面展示的service的示例），就是该类型

spec:
  selector:
    app: myng
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 8080 ## service的port
    targetPort: 80 ##pod的port

2.NodePort

如果想通过k8s节点的IP直接访问到service对应的资源，可以使用nodeport，NodePort对应的端口范围为：30000-32767

spec:
  selector:
    app: myng
  type: NodePort
  ports:
  - protocol: TCP
    port: 8080  # Service 的端口，外部访问的端口
    targetPort: 80  # Pod 的端口，容器内部监听的端口
    nodePort: 30009  # NodePort 服务的节点端口，可以自定义或自动获取

3.LoadBlancer

这种方式需要配合公有云资源（阿里云、亚马逊云等）来实现，这里需要一个公网IP作为入口，然后负载均衡所有pod

spec:
  selector:
    app: myng
  type: LoadBalancer  # 确保类型拼写正确
  ports:
  - protocol: TCP
    port: 8080  # Service 的端口，即服务暴露的端口
    targetPort: 80  # Pod 的端口，即后端 Pod 监听的端口

四、DaemonSet

有些场景需要在每一个node上运行pod，（比如，网络插件calico、监控、日志收集），Deploment无法做到，而Daemonset（简称ds）可以。

Deamonset的目标是在集群的每一个节点上运行且只允许一个pod。

Daemonset不支持使用 kubectl create 获取 YAML 模板，所以只能参考Delopment的YAML编写，

其实Daemonset 和 Delopment 的差异很小，除了Kind不一样，还需要去掉replica配置。

Daemonset（简称ds）YAML示例

vim ds-demo.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ds-demo
  labels:
    app: ds-demo
spec:
  selector:
    matchLabels:
      app: ds-demo
  template:
    metadata:
      labels:
        app: ds-demo
    spec:
      containers:
      - name: ds-demo
        image: nginx:1.23.2
        ports:
        - name: mysql-port  # 注意：这里端口的名称是 mysql-port，但实际容器使用的是 nginx镜像
          containerPort: 80

## 使用yaml创建ds
kubectl apply -f ds-demo.yaml

## 查看
kubectl get ds
kubectl get po

## 默认master上有限制，只在两个node节点上启动pod，master上没有启动
kubectl describe node k8s01 |grep -i 'taint'
Taints: node-role.kubernetes.io/control-plane:NoSchedule

说明：Taint叫做污点，如果某一个节点上有污点，则不会被调度运行pod

但是这个还得取决于pod自己的一个属性：toleration（容忍），即这个Pod是否能够容忍目标节点是否有污点。

为了解决此问题，我们可以在Pod上增加toleration属性。

增加toleration属性的ds.YAML示例

修改后的YAML配置：

vim ds-demo.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ds-demo
  labels:
    app: ds-demo
spec:
  selector:
    matchLabels:
      app: ds-demo
  template:
    metadata:
      labels:
        app: ds-demo
    spec:
      tolerations:
      - key: "node-role.kubernetes.io/control-plane"
        effect: "NoSchedule"
      containers:
      - name: ds-demo
        image: nginx:1.23.2
        ports:
        - name: mysql-port  # 注意端口名称与服务的实际用途应保持一致
          containerPort: 80

## 再次使用此YAML
kubectl apply -f ds-demo.yaml

五、StatefulSet

Pod根据是否有数据存储分为有状态和无状态：

无状态：指的Pod运行期间不会产生重要数据，即使有数据产生，这些数据丢失了也不影响整个应用。比如nginx、Tomcat等应用适合无状态。
有状态：指的是Pod运行期间会产生重要的数据，这些数据必须要做持久化，比如MySQL、Redis、RabbitMQ等。

Deploment 和 Daemonset 适合做无状态，而有状态也有一个对应的资源，那就是 Statefulset（简称sts）。

说明：由于StatefulSet涉及到数据持久化，用到了StorageClass，需要先创建一个基于NFS 的StorageClass

额外建立一台虚拟机，搭建NFS服务（待完善）

假设NFS服务器IP地址为192.168.31.30，共享目录为 /data/nfs

另外，想要使用NFS的sc，还需要装一个NFS provisioner，它的作用是自动创建NFS的pv

GitHub地址：https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

源码下载：

## 无git命令，需先安装
yum install -y git

git clone https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

cd nfs-subdir-external-provisioner/deploy

## 修改命名空间为 kube-system
sed -i 's/namespace:default/namespace:kube-system/' rbac.yaml

## 创建rbac授权
kubectl apply -f rbac.yaml

修改deploment.yaml

## 修改命名空间为kube-system
sed -i 's/namespace: default/namespace: kube-system/' deployment.yaml 

#### 你需要修改标红的部分
vim deploment.yaml

## 你需要修改红色的部分
spec:
  serviceAccountName: nfs-client-provisioner
  containers:
  - name: nfs-client-provisioner
    # image: chronolaw/nfs-subdir-external-provisioner:v4.0.2
    image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
    volumeMounts:
    - name: nfs-client-root
      mountPath: /persistentvolumes
    env:
    - name: PROVISIONER_NAME
      value: k8s-sigs.io/nfs-subdir-external-provisioner
    - name: NFS_SERVER
      value: 192.168.10.10 # nfs服务器地址
    - name: NFS_PATH
      value: /home/nfsdir # nfs共享目录
  volumes:
  - name: nfs-client-root
    nfs:
      server: 192.168.10.10 # nfs服务器地址
      path: /home/nfsdir # nfs共享目录

## 应用yaml
kubectl apply -f deployment.yaml
kubectl apply -f class.yaml ##创建storageclass

sc.yaml 示例

cat class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner 
# 选择一个与deployment的env PROVISIONER_NAME匹配的名称
parameters:
  archiveOnDelete: "false" # 自动回收存储空间

Sts示例

vim redis-sts.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-sts
spec:
  serviceName: redis-svc
  replicas: 2
  selector:
    matchLabels:
      app: redis-sts
  template:
    metadata:
      labels:
        app: redis-sts
    spec:
      containers:
      - name: redis
        image: redis:6.2
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: redis-pvc
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: redis-pvc
    spec:
      storageClassName: nfs-client
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 500Mi

vim redis-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: redis-svc
spec:
  selector:
    app: redis-sts
  ports:
    - port: 6379
      protocol: TCP
      targetPort: 6379

应用两个yaml文件

kubectl apply -f redis-sts.yaml -f redis-svc.yaml

对于Sts的pod，有如下特点

Pod名固定有序，后缀从0开始
“域名”固定，这个“域名”组成：Pod名.Svc名；例如：redis-sts-0.redis-svc;
每个Pod对应的PVC也是固定的

## 测试
## ping 域名
kubectl exec -it redis-sts-0 --bash 
## 进去可以 ping redis-sts-0.redis-svc
## ping redis-sts-1.redis-svc

## 创建key
kubectl exec -it redis-sts-0 --redis-cli
127.0.0.1:6379 > set k1 'abc'
ok
127.0.0.1:6379 > set k2 'bcd'
ok

模拟故障

kubectl delete pod redis-sts-0

删除后，它会自动创建同名Pod，再次进入查看reids key

kubectl exec -it redis-sts-0 --redis-cli
127.0.0.1:6379> get k1
"abc"
127.0.0.1:6379> get k2
"bcd"

数据依然存在

关于Sts里的多个Pod间数据同步，具体的数据同步和一致性策略取决于我们部署的有状态应用程序。

不同的应用程序可能使用不同的数据同步和一致性策略。

例如，关系型数据库（MySQL）可能是有主从复制，而分布式数据库（MongoDB）可能使用一种基于分区和副本数量的数据同步机制。

六、Job

可以理解为一次性运行后就退出的Pod。

## 先生成一个yaml文件
kubectl create job job-demo --image=busybox --dry-run=client -o yaml > job-demo.yaml

## 编辑此配置
vim job-demo.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  template: # 模板，基于此模板来创建pod，它用来定义pod的属性，比如container
    spec:
      restartPolicy: OnFailure # 定义Pod运行失败时的策略，可以是OnFailure和Never
      # 其中OnFailure表示失败的话需要重启容器，Never表示失败的话不重启容器，而是重新生成一个新的Pod
      containers:
      - image: busybox
        name: job-demo
        command: ["/bin/echo"]
        args: ["hello", "world"] # 修正了拼写错误

## 创建job
kubectl apply -f job-demo.yaml

## 查看job
kubectl get job,pod

##可以看到容器运行完成后，状态就变成了Completed

对于Pod，有几个特殊的字段：

activeDeadlineSeconds : 设置Pod运行超时的时间
backoffLimit : 设置Pod的失败重启次数
completions : job完成需要运行多少个Pod，默认是1
parallelism ：它与 completions 相关，表示允许并发运行的Pod数量，避免过多占用资源

vim myjob.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: sleep-job
spec:
  activeDeadlineSeconds: 15 # 15秒后超时
  backoffLimit: 2 # 失败重试2次就放弃
  completions: 4 # 需要运行4个pod才算完成
  parallelism: 2 # 允许并发运行2个pod
  template:
    spec:
      restartPolicy: Never
      containers:
      - image: busybox
        name: echo-job
        imagePullPolicy: IfNotPresent
        command:
        - sh
        - -c
        - "sleep 10; echo done" # 将命令和参数合并为一个字符串，用双引号包围

## 创建job,并查看job情况
kubectl apply -f myjob.yaml

kubectl get pod -w

七、CronJob

CronJob(cj)是一种周期运行的Pod，比如有些任务需要每天执行一次，就可以使用CronJob

## 先生产一个YAML文件
kubectl create cj cj-demo --image=busybox --schedule="" --dry-run=client -o yaml > cj-demo.yaml

## 编辑此配置
vim job-demo.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cj-demo
spec:
  schedule: '*/1 * * * *' # 每小时执行一次
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - image: busybox
            name: cj-demo
            imagePullPolicy: IfNotPresent
            command: ["/bin/echo"]
            args: ["hello", "world"]

## 运行并查看
kubectl apply -f cj-demo.yaml
kubectl get cj
kubectl get pod

八、Endpoint

Endpoint(简称ep) 资源是和service -- 一一对应的

也就是说每一个service都会对应一个Endpoint

[root@giorno01 k8s] kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.15.0.1      <none>        443/TCP        12d
redis-svc    ClusterIP   10.15.71.89    <none>        6379/TCP       6h58m
tesrsvc      NodePort    10.15.78.222   <none>        80:32284/TCP   11d
[root@giorno01 k8s] kubectl get ep
NAME         ENDPOINTS                             AGE
kubernetes   192.168.10.6:6443                     12d
redis-svc    10.18.135.207:6379,10.18.37.72:6379   6h58m
tesrsvc      10.18.135.194:80                      11d

Endpoint 可以理解为 service 后端对应的资源。

有时候K8s中的Pod需要访问外部资源，比如访问外部的MySQL服务，就可以定义一个对外资源的Endpoint，然后再定义一个service，就可以让K8s里面的其他Pod访问了。

vim testep.yaml

apiVersion: v1
kind: Endpoints
metadata:
  name: external-mysql
subsets:
  - addresses:
    - ip: 192.168.222.128
    ports:
      - port: 3306

---
apiVersion: v1
kind: Service
metadata:
  name: external-mysql
spec:
  ports:
    - port: 3306

## 应用YAML文件
kebuctl apply -f testep.yaml

## 测试
kubectl get ep
kubectl get svc

安装mariadb包（需要mysql命令），然后命令行连接Service external-mysql对应的Cluster IP测试

九、ConfigMap

ConfigMap(简称cm)用来存储配置信息

比如服务端口、运行参数、文件路径等等

示例

vim mycm.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mycm
data:
  DATABASE: 'db'
  USER: 'wp'
  PASSWORD: '123456'
  ROOT_PASSWORD: '123456'

# 创建cm
kubectl apply -f mycm.yaml
# 查看
kubectl get cm
kubectl describe cm mycm

在其他Pod里面引用 ConfigMap

vim testpod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: testpod
  labels:
    app: testpod
spec:
  containers:
  - image: mariadb:10
    name: maria
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 3306
    envFrom:
    - configMapRef:
        name: mycm
      prefix: 'MARIADB_' # 将导入的字段名前自动加上前缀，例如MARIADB_DATABASE

## 验证
kubectl exec -it testpod -- bash
## 进入Pod，查看变量 $MARIADB_DATABASE

十、Secret

Secret 和 cm 的结构和用法很类似，不过在K8s里Secret对象又细分出很多类

比如

访问私有镜像仓库的认证信息
身份识别的凭证信息
HTTPS通信的证书和密钥
一般的机密信息（格式由用户自行解释）

前几种我们现在暂时用不到，所以只使用最后一种

示例

vim mysecret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  user: Z2lvcm5v     # echo -n "aming" | base64
  passwd: bGludXgxMjM= # echo -n "linux123" | base64

## 查看
kubectl apply -f mysecret.yaml
kubectl get secret
kubectl describe secret mysecret

其他Pod中引用Secret

vim testpod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: testpod2
spec:
  containers:
  - image: busybox
    name: busy
    imagePullPolicy: IfNotPresent
    command: ["/bin/sleep", "300"]
    env:
    - name: USERNAME
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: user
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: passwd

## 查看
kubectl exec -it testpod2 -- sh
## 进去之后可以 echo $PASSWORD 查看变量值

十一、水平自动扩容和缩容HPA

适合K8s版本 >= 1.23.x

HPA全称Horizontal Pod Autoscaler，中文：POD水平自动伸缩

HPA可以基于CPU利用率对 replication controller 、deployment 和 replicaset 中的Pod数量进行自动扩容缩容（出了CPU利用率也可以基于其他应用程序提供的度量指标 custom metrics 进行自动扩容缩容）

Pod自动缩放不适用于无法缩容的对象，如DaemonSets

HPA 由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为，控制器会周期性的获取目标资源指标（如，平均CPU利用率），并与目标值相比较之后来调整Pod副本数量

创建测试Deployment

vim php-apache.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: aminglinux/hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m  # 限制Pod CPU资源最多使用500m
          requests:
            cpu: 200m  # K8s要保证Pod使用的最小cpu资源为200m

---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

安装merics-server（通过它才能获取到具体的资源使用情况）

下载YAML文件

# 下载yaml文件
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml

# 修改yaml文件
vi high-availability-1.21+.yaml
将image: k8s.gcr.io/metrics-server/metrics-server:v0.6.2 修改为 image:aminglinux/metrics-server:v0.6.2 (image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.6.3)
在image: 这行上面增加一行: - --kubelet-insecure-tls

# 应用此yaml文件
kubectl apply -f high-availability-1.21+.yaml

创建HPA

vim hpa-php-apache.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1 # 最小Pod数为1
  maxReplicas: 10 # 最大Pod数为10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50 # 当Pod的CPU使用率超过50%时，需要自动扩容

# 应用YAML
kubectl apply -f hpa-php-apache.yaml

模拟php-apache Pod CPU 使用率增加

## 再打开一个终端执行
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

## 回到原来终端查看hap和po
kubectl get deployment,po,hpa |egrep 'NAME|php-apache' 
## php-apache Pod副本会逐渐增加，hpa的TARGETS列CPU使用率会越来越高，当超过50%就会自动生成新的Pod副本kubecy

标签：kubectl,name,04,##,介绍,yaml,组件,Pod,pod
From： https://www.cnblogs.com/wangand/p/18321102

04、组件介绍