k8s知识点

redis 服务问题

#关联GitLab服务器HIS-BACKEND项目与Programer主机HIS-BACKEND代码
[root@Programer ~]# cd HIS/HIS-BACKEND/

[root@Programer HIS-BACKEND]# git init                          #初始化仓库
已初始化空的 Git 仓库于 /root/HIS/HIS-BACKEND/.git/

[root@Programer HIS-BACKEND]# git remote add origin http://192.168.88.20/devops/HIS-BACKEND.git                     #关联本地与远程

[root@Programer HIS-BACKEND]# git remote -v
origin  http://192.168.88.20/devops/HIS-BACKEND.git (fetch)
origin  http://192.168.88.20/devops/HIS-BACKEND.git (push)

[root@Programer HIS-BACKEND]# git add ./                        #添加代码到暂存区

[root@Programer HIS-BACKEND]# git commit -m "Init Backend Code" #提交本地版本库

[root@Programer HIS-BACKEND]# git tag v1                        #创建v1标签

[root@Programer HIS-BACKEND]# git push -u origin --all          #推送本地所有分支

[root@Programer HIS-BACKEND]# git push -u origin --tags         #推送本地所有标签
总共 0（差异 0），复用 0（差异 0），包复用 0

config ： 配置git行为，用户名，邮箱等

init ： 初始化一个git仓库

add : 将工作区文件添加到暂存区         

commit ： 将暂存区文件添加到本地仓库

push ： 将本地仓库的文件推送到远程仓库

DOCKER

# 上帝进程
容器启动时执行的第一个进程
只能在前台运行

# entrypoint

Dockerfile 详解

wget http://raw.githubusercontent.com/Ljohn001/ljohn_ops/master/redis/redis3.x.sh
curl -O  https://raw.githubusercontent.com/Ljohn001/ljohn_ops/master/redis/redis3.x.sh

 # 嵌入式脚本  command
 initsvc:
    container_name: init
    image: myos:8.5
    command:
      - sh
      - -c
      - |
        for i in {1..9}
        do
            sleep 1
            echo "${HOSTNAME} && $${HOSTNAME}"   # $宿主机变量  $$ 容器内变量 
        done

熟悉 k8s/kubernetes 架构及操作，包括 pod、service、deployment 等核心组件
熟悉 Docker、包括 Dockerfile 制作镜像、Harbor 私有镜像仓库管理
熟悉使用华为云平台搭建和管理集群，了解阿里云、腾讯云等平台
熟悉使用 CentOS、Ubuntu、RHEL、Debian、Rocky 等主流 Linux 操作系统
熟悉 Ansible 自动化运维工具，能编写 Playbook 脚本，实现自动化运维
熟悉 CI/CD 流程与自动化工具，通过 Jenkins,Gitlab 实现代码管理
熟悉 Shell 语言的编写以及 sed、awk、grep 正则表达式的使用
熟悉 Lvs、Haproxy、Keepalived、Nginx 等高可用及负载均衡的安装和配置
熟悉 Web 服务器的配置和管理，包括 Apache、Nginx、Tomcat
熟悉网络通信原理，OSI 七层模型、TCP/IP 协议/Iptables 防火墙
熟悉 MySQL、Redis 数据库相关技术，掌握主从同步、读写分离的应用以及中间件部署调优
熟悉 RedHat 虚拟化 KVM、VMware 虚拟化技术
熟悉主流运维监控 Zabbix、Promethus、Grafana 的部署使用
了解 RocketMQ、RabbitMQ、kafka 消息队列

k8s

角色和对应的组件

# master
APIServer # 整个系统的对外接口 供客户端和其他组件调用  后端元数据存储在etcd中（键值数据库）

Scheduler # 对集群内的资源进行分配和调度

ControllerManager # 管理控制器  大总管

etcd （重要 做高可用集群） # 注意很有可能面试会问，比如如何备份master  怎么做高可用 
# 基于go语言  k8s运行中产生的所有元数据都存储在etcd中

# NOde   
kubelet  # 守护进程 负责在节点上维护和管理pod的运行 
kube-proxy # 
Runtime # 容器运行时   用于创建容器

# 镜像仓库
harbor


calico  #  用来解决不同节点直接的容器实现互通，子网路由的方式  也可以设置网络策略 是一直种实现容器间网络互通的就解决方案   还有一种就是端口映射

# 循环上传镜像
# read 可以用来批量赋值  _ 其他值赋给_但是不用
docker images|while read i t _;do

    [[ "${t}" == "TAG" ]] && continue

    [[ "${i}" =~ ^"harbor:443/".+ ]] && continue

    docker tag ${i}:${t} harbor:443/k8s/${i##*/}:${t}

    docker push harbor:443/k8s/${i##*/}:${t}

    docker rmi ${i}:${t} harbor:443/k8s/${i##*/}:${t}

done

1、获取证书哈希值和token

[root@master calico]# kubeadm token create --ttl=0 --print-join-command
kubeadm join 192.168.88.50:6443 --token rgrlf1.7pmhqwe4kvz8y4ay --discovery-token-ca-cert-hash sha256:87a9a99c8c4c2231760ea0645703cb77a2775f18f8d1414b71867f7b098e2435 

kubeadm token create --ttl=0 --print-join-command
kubeadm join 192.168.88.50:6443 --token rgrlf1.7pmhqwe4kvz8y4ay --discovery-token-ca-cert-hash sha256:87a9a99c8c4c2231760ea0645703cb77a2775f18f8d1414b71867f7b098e2435 

k8s为什么要关闭swap

kubectl

[root@master ~]# kubectl get nodes  master -o wide 
NAME        STATUS   ROLES           AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION              CONTAINER-RUNTIME
master      Ready    control-plane   20h   v1.29.2   192.168.88.50   <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-372.9.1.el8.x86_64   containerd://1.6.28

docker images|while read i t _;do
    [[ "${t}" == "TAG" ]] && continue
    [[ "${i}" =~ ^"harbor:443/".+ ]] && continue
    docker tag ${i}:${t} harbor:443/library/${i##*/}:${t}
    docker push harbor:443/library/${i##*/}:${t}
    docker rmi ${i}:${t} harbor:443/library/${i##*/}:${t}
done

pod

概念

pod 可以理解为一个陈放容器的盒子  也可以理解为豌豆荚

异步创建 

用户发送创建pod的请求，api server 接受请求后将请求保存至etcd，并返回保存结果，然后scheduler 调度器，通过调度算法给pod分配计算节点，再把计算出来的结果保存至etcd，这几步都是在master主节点中进行，在计算机点 kubelet 守护进程，用于维护和管理pod运行，它接受到api server的调用之后，会去调用runtime 容器运行时创建容器，最后把创建的结果保存到etcd。

状态

核心命令

重点 排错语法 工作重点

logs

# 语法
kubectl logs pods名称  {参数/选项}

# 例如查看 查看名称空间 kube-system 下的 kube-proxy-qgwhr pod 日志
kubectl logs kube-proxy-qgwhr  -n kube-system  

describe

# 语法
kubectl describe 资源类型  {资源名称}  {选项/参数}

# Events: 事物日志 用于排错
[root@master metrics]# kubectl describe -n kube-system pod metrics-server-8569457874-hnlkx
。。。。
Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Normal   Scheduled  8m52s                  default-scheduler  Successfully assigned kube-system/metrics-server-8569457874-hnlkx to node-0001
  Warning  Failed     8m10s (x3 over 8m51s)  kubelet            Failed to pull image "harbor:443/plugins/metrics-server:v0.6.4": failed to pull and unpack image "harbor:443/plugins/metrics-server:v0.6.4": failed to resolve reference "harbor:443/plugins/metrics-server:v0.6.4": failed to do request: Head "https://harbor:443/v2/plugins/metrics-server/manifests/v0.6.4": tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match harbor
  Warning  Failed     8m10s (x3 over 8m51s)  kubelet            Error: ErrImagePull
  Normal   BackOff    7m32s (x6 over 8m50s)  kubelet            Back-off pulling image "harbor:443/plugins/metrics-server:v0.6.4"
  Warning  Failed     7m32s (x6 over 8m50s)  kubelet            Error: ImagePullBackOff
  Normal   Pulling    7m17s (x4 over 8m51s)  kubelet            Pulling image "harbor:443/plugins/metrics-server:v0.6.4"
  Normal   Pulled     7m3s                   kubelet            Successfully pulled image "harbor:443/plugins/metrics-server:v0.6.4" in 13.254s (13.254s including waiting)
  Normal   Created    7m3s                   kubelet            Created container metrics-server
  Normal   Started    7m2s                   kubelet            Started container metrics-server

Pod 管理命令（2）

exec

# -- 选项终止符 区分 kubectl 的选项和容器内命令 
[root@master ~]# kubectl exec -it myweb -- ls
index.html  info.php

# 执行交互式命令  进入容器内部
[root@master ~]# kubectl exec -it myweb -- bash
[root@myweb html]# 

cp

# 上传文件到容器内  跟docker一样要写容器内绝对路径
[root@master ~]# kubectl cp 1.txt myweb:/var/www/html
[root@master ~]# kubectl exec -it myweb -- tree /var/www/html
/var/www/html
|-- 1.txt
|-- index.html
`-- info.php

# 拉取容器内的文件 
[root@master ~]# kubectl cp myweb:/var/www/html /root/var
tar: Removing leading `/' from member names
[root@master ~]# ls
1.txt  init  myos.tar.xz  plugins  root  var
[root@master ~]# tree var/
var/
├── 1.txt
├── index.html
└── info.php

cp其实就是通过tar流传输数据   跟docker  cp  的原理是两码事
docker是单机   k8s是跨服务器

delete

# 可以删除k8s中的任何文件 容器  节点  名称空间
[root@master ~]# kubectl delete pods myweb
pod "myweb" deleted
[root@master ~]# kubectl get pods
No resources found in default namespace.
[root@master ~]# kubectl delete namespaces work 
namespace "work" deleted
[root@master ~]# kubectl get namespaces 
NAME              STATUS   AGE
default           Active   24h
kube-node-lease   Active   24h
kube-public       Active   24h
kube-system       Active   24h

资源清单文件 要求会默写

[root@master ~]# vim myweb.yaml
---
kind: Pod
apiVersion: v1
metadata:
  name: myweb
spec:
  containers:
  - name: nginx
    image: myos:nginx
status: {}


---
# 资源类型
kind：
# 版本
apiVersion: 
# 资源属性
metadata:
  name: 
# 资源特征
spec:
  containers:
  - name: 
    image: 
# 状态
status: {}

语法

# 只有键值对和数组这两种数据类型
# 键值对格式 键值对用花括号
key: value
key: 
  value
  
key: {key: v1}

key: 
  key: v1
  
key:
  key:
    v1

# 数组 一个- 代表一个数组元素
[aa,bb,cc]
等于
- aa
- bb
- cc

key: [aa,bb,cc]

key: 
- aa
- bb
- cc

key: 
  - aa
  - bb
  - cc
  
# 嵌套
key: [aa,{k1: v1,k2: v2},[aa,bb,cc]]

key: 
- aa
- {k1: v1,k2: v2}
- [aa,bb,cc]

key: 
- aa
- k1: v1
  k2: v2
- - aa
  - bb
  - cc
  
---
kind: Pod
apiVersion: v1
metadata: {name: myweb3}
spec: {containers: [{name: nginx,image: myos: nginx}]}
status: {}

# 关键字需要遵守key 小驼峰  value 大驼峰

# 获取资源对象模板
[root@master ~]# kubectl create namespace work --dry-run=client -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: work
spec: {}
status: {}

explain

# explain  查看资源清单各个级别的参数
[root@master ~]# kubectl explain Pod.apiVersion
KIND:       Pod
VERSION:    v1

管理命令

# apply  和  replace

# apply 更新pod里面的容器内容，并不会影响pod  而 replace则是强行重建pod  和原先的pod不是同一个

# apply  不可修改资源的名字

# 语法

kubectl  create  -f  **.yaml

# 强制重建
[root@master ~]# kubectl get pods web1 -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE        NOMINATED NODE   READINESS GATES
web1   1/1     Running   0          85s   10.244.21.134   node-0001   <none>           <none>
[root@master ~]# kubectl replace --force -f  web1.yaml 
[root@master ~]# kubectl get pods web1 -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE        NOMINATED NODE   READINESS GATES
web1   1/1     Running   0          51s   10.244.21.135   node-0001   <none>           <none>

# 拓展提高
# 与 kubectl apply -f myweb.yaml 功能相同  - 占位符  标准输入  标准输出
[root@master ~]# cat myweb.yaml |kubectl apply -f -

[root@master ~]# kubectl create 
clusterrolebinding   (Create a cluster role binding for a particular cluster role)
clusterrole          (Create a cluster role)
configmap            (Create a config map from a local file, directory or literal value)
cronjob              (Create a cron job with the specified name)
deployment           (Create a deployment with the specified name)
ingress              (Create an ingress with the specified name)
job                  (Create a job with the specified name)
namespace            (Create a namespace with the specified name)
poddisruptionbudget  (Create a pod disruption budget with the specified name)
priorityclass        (Create a priority class with the specified name)
quota                (Create a quota with the specified name)
rolebinding          (Create a role binding for a particular role or cluster role)
role                 (Create a role with single rule)
secret               (Create a secret using a specified subcommand)
serviceaccount       (Create a service account with the specified name)
service              (Create a service using a specified subcommand)
token                (Request a service account token)

namespace

# 创建名称空间
[root@master ~]# kubectl create namespace work   
# 指定名称空间创建pod
[root@master ~]# kubectl -n work  run myweb --image myos:httpd 
# 不同名称空间里可以创建同名的pod  但这是两个不同的pod
[root@master ~]# kubectl get pods myweb  -n work  -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE        NOMINATED NODE   READINESS GATES
myweb   1/1     Running   0          58s   10.244.21.129   node-0001   <none>           <none>
[root@master ~]# kubectl get pods myweb  -n default  -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
myweb   1/1     Running   0          61m   10.244.243.193   node-0003   <none>           <none>

lscpu

毫核计算

静态pod

# 创建静态pod只需要在相应的计算节点的/etc/kubernetes/manifests/下创建一个资源清单即可，就可以直接创建出静态pod  创建的pod名称由节点的主机名和name属性拼接而成
---
kind: Pod
apiVersion: v1
metadata:
  name: node-0001
spec:
  containers:
  - name: web
    image: myos:httpd
status: {}
~            

# 修改资源清单内容后，pod也会相应的自动修改
metadata:
  name: myweb
  
# 在主节点上无法通过delete删除静态pod，只有删除相应的资源清单才能删除静态pod

多容器pod

# 由于共享网络ip所以会出现端口冲突的问题

---
kind: Pod
apiVersion: v1
metadata:
  name: tw1
spec:
  containers:
  - name: httpd
    image: myos:httpd
  - name: nginx
    image: myos:nginx

嵌入式脚本

# $ 只能调用容器内的变量，跟docker不同
---
kind: Pod
apiVersion: v1
metadata:
  name: tw1
spec:
  containers:
  - name: httpd
    image: myos:httpd
    command:[sh] 
    args:
    - -c
    - |
      ls

# 当容器内的主进程（PID 1）退出时，容器会自动停止。如果容器内运行的是一个嵌入式脚本（如 Shell 脚本），且该脚本执行完毕后没有保持前台进程运行，容器就会立即退出。
[root@master ~]# kubectl get pods
NAME              READY   STATUS             RESTARTS        AGE
myweb             1/1     Running            2 (5h39m ago)   22h
myweb-node-0001   1/1     Running            0               5h19m
myweb3            1/1     Running            0               5h36m
tw3               0/1     CrashLoopBackOff   4 (65s ago)     2m42s
two               2/2     Running            0               66m
[root@master ~]# kubectl logs  tw3
index.html
info.php
[root@master ~]# vim more.yaml 
---
kind: Pod
apiVersion: v1
metadata:
  name: tw3
spec:
  containers:
  - name: httpd
    image: myos:httpd
    command: [sh]
    args:
    - -c
    - |
      ls

宽限期

# 默认30秒   防止数据丢失  损坏  数据库  消息队列  时间较长  让pod里面事务执行完成
terminationGracePeriodSeconds

标签

# 可以用来做服务分区  把不同的pod部署在不同的节点上  比如说有的功能需要更好性能的服务器  则可以把这些性能好的服务器标签

# 查看标签
kubectl get pods --show-labels 

# 创建标签 app=apache
 kubectl label pod myhttp app=apache
 
# 删除标签
 kubectl label pod myhttp app-

探针

#  生存探针 必备
#  启动探针
#  就绪探针

资源配置

#  只配置了限额，配额的值使用限额的值  k8s要关闭swap的原因之一就是与资源配置有关
---
kind: Pod
apiVersion: v1
metadata:
  name: blp1
spec: 
  containers:
    - name: httpd
      image: myos:httpd
      resources:
        limits:
          cpu: 1500m
          memory: 800Mi

写操作大于读操作   
ceph 搭建分布式对像存储集群，用作视频和图片的存储  异地容灾
mycat实现读写分离
mysql双主双从+keepalived+mycat（2台）+双主分片写    存储元数据   
Ceph
跨机房3副本 + 异地RGW同步
每周全量 + 每日增量备份至异地
MySQL
双主跨机房 + Keepalived VIP
每日XtraBackup全量 + 增量备份

redis？要用吗 ，用的话要不要，主从+哨兵？做高可用
不确定mysql主服务器数量
MySQL？？  

在 Kubernetes 的调度过程中，过滤（Filtering/Predicates）、打分（Scoring/Prioritization） 和 绑定（Binding） 是三个核心阶段，它们共同决定了 Pod 如何被分配到合适的节点上。

-.0


.-help
--dry-run=client -o yaml

卷

背格式

PV 和 PVC 的关系

在 Kubernetes 中，PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 是核心的持久化存储抽象机制，用于管理存储资源（如磁盘、NFS、云存储等）。它们通过解耦存储的提供（PV）和消费（PVC），实现了存储的灵活分配与动态管理。

PV：存储的“物理定义”，描述存储的属性和位置。

PVC：存储的“需求声明”，用户通过 PVC 申请存储。

绑定流程：PVC → 匹配 PV → 绑定 → Pod 使用。

    volumeMounts:
    - name: nignx-conf
      subPath: nginx.conf
      # 用mountPath挂在的都是目录  只有加上subPath后才是文件
      mountPath: /usr/local/nginx/conf/nginx.conf

emptyDir 的核心作用

(1) 提供临时存储

• 数据持久性：数据仅在 Pod 运行期间存在，Pod 被删除（或崩溃重启）后，emptyDir 中的数据会被永久清除。

• 存储位置

  ：

  • 默认：存储在节点磁盘上（路径如 /var/lib/kubelet/pods/<pod-id>/volumes/kubernetes.io~empty-dir/）。
  • 可选：通过 medium: Memory 指定使用内存（tmpfs），性能更高但数据更易丢失（重启或 Pod 删除后丢失）。

(2) 共享数据

• 容器间共享：同一个 Pod 内的多个容器可以挂载同一个 emptyDir，实现数据共享（例如 Sidecar 容器处理日志，主容器读取日志）。
• 无需持久化：适合临时交换数据（如缓存、中间计算结果、会话状态等）。

在 Kubernetes 中，是否使用单独的服务器存储数据取决于你选择的卷类型和存储后端。卷的核心作用是抽象存储资源，让数据可以独立于容器生命周期流动（持久化或临时共享），但具体存储位置（本地节点、网络存储、云存储等）由卷类型决定。以下是详细分析：

1. 卷的存储位置：是否需要单独的服务器？

(1) 本地存储（节点磁盘/内存）

• 卷类型：emptyDir、hostPath

• 存储位置：当前节点（Pod 所在的 Kubernetes 节点服务器）。

• 特点

  ：

  • 无需单独服务器：数据直接存储在运行 Pod 的节点上。

  • 局限性

    ：

    • 不跨节点：Pod 迁移到其他节点后，数据无法跟随（除非重新同步）。
    • 节点故障风险：节点宕机时数据可能丢失（除非有备份）。

• 适用场景

  ：

  • 临时缓存（emptyDir）。
  • 访问节点文件（如 /var/log，hostPath）。
  • 非关键数据（如测试环境）。

示例：emptyDir 存储视频临时文件

volumes:
- name: video-cache
  emptyDir:
    medium: Memory  # 使用节点内存存储（高性能）
    sizeLimit: 2Gi  # 限制大小为 2Gi
volumeMounts:
- name: video-cache
  mountPath: /tmp/videos  # 容器内路径

(2) 网络存储（需要单独的存储服务器/服务）

• 卷类型：PersistentVolumeClaim (PVC) + 存储后端（如 NFS、云盘、Ceph 等）。

• 存储位置：独立的存储服务器或云存储服务（与 Kubernetes 节点分离）。

• 特点

  ：

  • 跨节点共享：多个 Pod 可以挂载同一个 PVC（如 ReadWriteMany 模式的 NFS）。
  • 高可用性：存储后端通常有冗余机制（如云盘自动备份）。
  • 需要额外配置：需提前部署存储服务（如 NFS 服务器）或使用云提供商的存储（如 AWS EBS）。

• 适用场景

  ：

  • 持久化数据（如数据库、用户上传的视频/图片）。
  • 需要跨节点访问的数据（如共享文件服务器）。

示例：NFS 存储用户上传的图片

1. 部署 NFS 服务器

   （单独的服务器或云存储）：

   # 在 NFS 服务器上创建共享目录
   mkdir /data/nfs
   chown nobody:nobody /data/nfs
   

2. 创建 Kubernetes PVC

   ：

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: nfs-pvc
   spec:
     accessModes: [ "ReadWriteMany" ]  # 多节点可读写
     storageClassName: "nfs-client"    # 需提前配置 StorageClass
     resources:
       requests:
         storage: 100Gi
   

3. Pod 挂载 PVC

   ：

   volumeMounts:
   - name: nfs-storage
     mountPath: /usr/share/nginx/html/uploads  # 存储用户上传的图片
   volumes:
   - name: nfs-storage
     persistentVolumeClaim:
       claimName: nfs-pvc
   

(3) 云存储（AWS/Azure/GCP 等）

• 卷类型：云提供商的 CSI 驱动（如 aws-ebs-csi-driver、azure-disk-csi-driver）。

• 存储位置：云服务商的块存储/对象存储（如 AWS EBS、S3）。

• 特点

  ：

  • 完全托管：无需自己维护存储服务器。
  • 弹性扩展：按需调整存储大小和性能。
  • 成本：按使用量计费（需权衡性能和价格）。

• 适用场景

  ：

  • 云原生应用（如 AWS EKS、GCP GKE）。
  • 需要全球低延迟访问的数据（如 CDN 边缘存储）。

示例：AWS EBS 存储视频数据库

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-pvc
spec:
  accessModes: [ "ReadWriteOnce" ]
  storageClassName: "ebs-sc"  # AWS EBS 存储类
  resources:
    requests:
      storage: 500Gi  # 500Gi 高性能 SSD

2. 卷如何实现数据流通？

卷通过挂载（Mount）机制将存储资源映射到容器内部，实现数据的持久化和共享：

1. 持久化：数据存储在卷中，容器重启或删除后数据保留。

2. 共享

   ：

   • 容器间共享：同一 Pod 的多个容器挂载同一卷（如 emptyDir）。
   • 跨节点共享：通过网络存储（如 NFS、云存储）实现。

示例：多容器共享 emptyDir 处理视频

containers:
- name: video-processor
  image: video-encoder
  volumeMounts:
  - name: shared-data
    mountPath: /input  # 读取原始视频
- name: video-uploader
  image: s3-uploader
  volumeMounts:
  - name: shared-data
    mountPath: /output  # 写入处理后的视频
volumes:
- name: shared-data
  emptyDir: {}  # 临时存储，处理完成后可迁移到持久化存储

3. 如何选择存储方案？

4. 最佳实践

1. 关键数据用持久化存储

   ：

   • 用户上传的文件、数据库必须使用 PVC + 网络存储/云存储。
   • 避免使用 emptyDir 存储重要数据（除非是临时处理）。

2. 性能优化

   ：

   • 视频/图片处理：使用 SSD 存储（如 gp3 存储类）。
   • 大文件存储：结合对象存储（如 S3）和 CSI 挂载。

3. 备份策略

   ：

   • 定期快照持久化卷（如云盘的自动备份）。
   • 使用 Velero 等工具备份整个 Namespace（包括 PVC）。

总结

• 是否需要单独服务器：取决于卷类型。本地存储（emptyDir/hostPath）不需要；网络存储（NFS/云存储）需要。

• 卷的作用：通过抽象存储资源，实现数据持久化、容器间共享和跨节点流动。

• 推荐方案

  ：

  • 临时数据：emptyDir（内存优先）。
  • 持久化数据：PVC + 网络存储/云存储。
  • 云环境：直接使用云提供商的 CSI 驱动（如 AWS EBS、S3）。

service 管理

# 如果service失效，则可能与这三个地方有关 
# 标签要和web服务相同
selector:
    app: web
# 端口别名要和web相同   targetPort: myhttp
# 固定ip地址要在范围之内 clusterIP: 10.245.88.80
---
kind: Service
apiVersion: v1
metadata:
  name: web123
spec:
  type: ClusterIP
  clusterIP: 10.245.88.80
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: myhttp
    
    
# web1
---
kind: Pod
apiVersion: v1
metadata:
  name: web1
  labels:
    app: web
spec:
  containers:
    - name: web
      image: myos:httpd
      ports:
      - name: myhttp
        protocol: TCP
        containerPort: 80     

对外发布服务

nodeport

ingress