1. 项目概述为什么我们需要K8S自动化运维容器在容器技术席卷软件交付流程的今天相信很多运维和开发朋友都经历过这样的场景手头管理着几十甚至上百个微服务每个服务都打包成了Docker镜像。本地测试一切顺利但一到生产环境服务发现、负载均衡、滚动更新、故障自愈这些事儿就让人头疼不已。你可能需要写一堆脚本去管理容器的启停手动配置Nginx做流量转发半夜被报警叫醒去处理某个挂掉的服务实例。这种“人肉运维”容器的方式在服务规模稍大一点后就变得难以维持效率低下且容易出错。这正是Kubernetes常简称为K8S要解决的核心问题。它不是一个简单的容器运行时而是一个容器编排平台。你可以把它理解为一个分布式的容器操作系统或者一个高度自动化的“容器云工厂”。它的目标是把运维人员从繁琐、重复的容器生命周期管理工作中解放出来通过声明式的配置和强大的控制循环实现从部署、伸缩、更新到监控、自愈的全流程自动化。我最初接触K8S时也觉得概念繁多有些望而却步。但真正用起来后发现一旦掌握了其核心模式它带来的运维效率提升是颠覆性的。今天我就结合自己从零搭建到生产实践的经验抛开那些复杂的理论直接聊聊如何利用K8S实现容器的自动化运维把那些热词背后大家真正关心的问题比如安装部署、常用命令、故障排查、与Docker的区别等揉碎了讲清楚。2. K8S自动化运维的核心设计思想在动手之前理解K8S的设计哲学至关重要。这能帮助你在后面遇到复杂配置或故障时知道该从哪里思考。2.1 声明式API与控制循环这是K8S最精髓的思想。传统运维往往是“命令式”的执行一条命令比如docker run让系统达到一个状态。而K8S是“声明式”的你告诉它你期望的系统最终状态是什么样子比如“运行3个Nginx实例使用80端口”然后K8S的控制器会持续地观察当前状态并驱动系统向期望状态收敛。举个例子你提交了一个Deployment配置文件声明需要3个副本replicas。K8S的Deployment控制器看到这个“期望状态”后会自动去创建对应的Pod容器组。如果某个Pod所在的节点宕机了当前状态只剩2个Pod与期望状态3个Pod不符控制器会立刻在其它健康节点上重新创建一个Pod直到恢复成3个。整个过程无需人工干预。实操心得养成用YAML文件定义资源的习惯。不要总用kubectl run这种命令式操作虽然快捷但不便版本管理和复用。把YAML文件纳入Git仓库运维即代码。2.2 核心对象模型解析K8S通过一系列抽象的资源对象来管理容器理解它们的关系是进行自动化运维的基础。PodK8S管理和调度的最小单位。一个Pod可以包含一个或多个紧密关联的容器比如一个Web应用容器和一个日志收集sidecar容器它们共享网络命名空间、存储卷等。Pod是短暂的会被频繁地创建和销毁。Deployment这是最常用的工作负载控制器。你通过Deployment来定义无状态应用的部署策略比如副本数、更新策略滚动更新。它负责确保指定数量的Pod副本始终运行。ServicePod的IP地址是不固定的Service为一组功能相同的Pod通常由Deployment管理提供一个稳定的访问入口虚拟IP和DNS名并负责负载均衡。ConfigMap Secret将配置信息和敏感数据如密码从容器镜像中解耦出来。你可以直接在YAML中引用它们实现配置的集中管理和动态更新无需重新构建镜像。Namespace逻辑上的资源隔离单元。可以将开发、测试、生产环境部署在不同的Namespace下方便管理和资源配额控制。Node运行容器的工作节点可以是物理机或虚拟机。每个Node上运行着Kubelet负责与Master通信管理本机Pod和容器运行时如Docker、containerd。2.3 K8S与Docker的关系澄清这是新手最容易混淆的点。简单来说Docker负责“造集装箱”构建和运行单个容器K8S负责“管理集装箱船队”编排和调度众多容器。Docker是一个容器化平台包含容器运行时、镜像构建工具等。它解决了“如何把应用及其依赖打包成一个标准、可移植的单元”的问题。K8S是一个容器编排系统。它不直接管理容器而是通过CRI容器运行时接口与Docker、containerd这样的容器运行时打交道。K8S负责决定在哪个节点上启动容器、如何将它们连接起来、如何扩缩容等更高层次的集群管理问题。现在很多生产环境为了追求更轻量、更稳定会直接用containerd替代Docker作为K8S的容器运行时但基本的容器概念和镜像标准OCI是相通的。3. 从零开始搭建一个可用的K8S集群理论说再多不如动手一试。这里我以最常用的方式使用kubeadm工具在CentOS 7系统上搭建一个单Master节点的集群。为什么选kubeadm因为它官方推荐、操作相对标准化适合学习和中小规模生产。3.1 前置准备与系统配置准备至少两台虚拟机或云服务器一台作为Master控制平面一台作为Node工作节点。配置要求2核CPU2GB内存以上网络互通。第一步基础环境配置所有节点执行# 1. 关闭防火墙、SELinux生产环境请根据安全策略调整 systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing$/SELINUXpermissive/ /etc/selinux/config # 2. 关闭swap交换分区K8S强制要求 swapoff -a sed -i / swap / s/^\(.*\)$/#\1/g /etc/fstab # 3. 配置内核参数并加载模块 cat EOF | sudo tee /etc/modules-load.d/k8s.conf br_netfilter EOF cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables 1 net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 EOF sysctl --system # 4. 配置yum源这里使用阿里云镜像 cat EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] nameKubernetes baseurlhttps://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled1 gpgcheck1 repo_gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF第二步安装容器运行时与K8S组件所有节点执行这里我们选择containerd它比Docker更轻量是未来趋势。# 1. 安装containerd yum install -y yum-utils device-mapper-persistent-data lvm2 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y containerd.io # 配置containerd使用systemd作为cgroup driver与kubelet保持一致 mkdir -p /etc/containerd containerd config default | tee /etc/containerd/config.toml sed -i s/SystemdCgroup false/SystemdCgroup true/ /etc/containerd/config.toml systemctl enable --now containerd # 2. 安装kubeadm, kubelet, kubectl yum install -y kubelet-1.23.0 kubeadm-1.23.0 kubectl-1.23.0 --disableexcludeskubernetes # 指定一个稳定版本如1.23.0 systemctl enable --now kubelet注意事项kubelet在安装后会不断重启是正常的因为它还在等待kubeadm的初始化指令。务必保持所有节点版本一致避免兼容性问题。3.2 初始化Master节点仅在Master节点执行。# 初始化集群使用阿里云镜像仓库加速 kubeadm init \ --apiserver-advertise-address192.168.1.100 \ # 替换为Master节点的实际IP --image-repository registry.aliyuncs.com/google_containers \ --kubernetes-version v1.23.0 \ --service-cidr10.96.0.0/12 \ --pod-network-cidr10.244.0.0/16 # 初始化成功后会输出类似下面的提示务必保存好 # Your Kubernetes control-plane has initialized successfully! # ... # To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config # 查看节点状态此时Master应为NotReady因为网络插件未安装 kubectl get nodes3.3 安装Pod网络插件CNIPod之间要能通信必须安装网络插件。这里选择最经典的Flannel。# 在Master节点执行 kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml # 等待片刻查看Pod状态直到所有CoreDNS和Flannel的Pod都Running kubectl get pods -n kube-system -w3.4 将Node节点加入集群在Master节点初始化成功输出的最后会有一条kubeadm join开头的命令。复制这条命令到你的Node节点上执行。# 在Node节点上执行示例命令具体token和hash以你初始化输出为准 kubeadm join 192.168.1.100:6443 --token xxxxxx.xxxxxxxxxxxxxx \ --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx加入成功后回到Master节点查看kubectl get nodes你应该能看到Master和Node的状态都变为Ready。至此一个最小的K8S集群就搭建完成了。4. 自动化运维实战部署与管理一个Web应用集群搭好了我们来真刀真枪地演练一下如何自动化部署一个应用。我们以部署一个Nginx为例但会覆盖完整的运维流程。4.1 使用Deployment部署应用创建文件nginx-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 # 声明期望运行3个副本 selector: matchLabels: app: nginx template: # Pod模板 metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21-alpine # 使用特定版本标签避免使用latest ports: - containerPort: 80 resources: requests: # 资源请求调度依据 memory: 64Mi cpu: 250m limits: # 资源上限防止容器失控 memory: 128Mi cpu: 500m livenessProbe: # 存活探针检查应用是否健康 httpGet: path: / port: 80 initialDelaySeconds: 5 # 容器启动后5秒开始探测 periodSeconds: 10 # 每10秒探测一次 readinessProbe: # 就绪探针检查应用是否可接收流量 httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5应用这个配置kubectl apply -f nginx-deployment.yaml关键点解析replicas: 3声明了期望状态Deployment控制器会确保始终有3个Pod在运行。resources为容器设置资源请求和限制这是保障集群稳定性的关键。没有限制一个失控的Pod可能吃光节点资源。livenessProbereadinessProbe自动化运维的“眼睛”。存活探针失败K8S会重启Pod就绪探针失败Service不会把流量转发给该Pod。这是实现服务自愈和高可用的核心机制。4.2 使用Service暴露应用Pod的IP不固定我们需要Service。创建nginx-service.yamlapiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx # 选择所有标签为appnginx的Pod ports: - protocol: TCP port: 80 # Service对外的端口 targetPort: 80 # 容器内部的端口 type: NodePort # 集群外可通过节点IP:NodePort访问应用并查看kubectl apply -f nginx-service.yaml kubectl get svc nginx-service输出中会有一个30000的端口如80:32678/TCP你就可以通过http://任意节点IP:32678访问到Nginx了。4.3 实现配置与代码分离ConfigMap假设我们需要修改Nginx的默认欢迎页面。我们不进入容器修改也不重建镜像而是用ConfigMap。创建nginx-configmap.yamlapiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: default.conf: | server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; } # 可以在这里添加自定义配置 } index.html: | !DOCTYPE html html headtitleHello from K8S ConfigMap!/title/head bodyh1This page is managed by ConfigMap!/h1/body /html然后更新Deployment将ConfigMap挂载到容器中# 在nginx-deployment.yaml的Pod模板spec.containers下添加 volumeMounts: - name: nginx-config-volume mountPath: /etc/nginx/conf.d/default.conf subPath: default.conf - name: nginx-config-volume mountPath: /usr/share/nginx/html/index.html subPath: index.html # 在spec.template.spec下添加与containers同级 volumes: - name: nginx-config-volume configMap: name: nginx-config应用更新kubectl apply -f nginx-deployment.yaml。K8S会自动滚动更新所有Pod新的Pod会使用ConfigMap中的配置。4.4 自动化滚动更新与回滚这是Deployment的杀手锏功能。当我们更新镜像版本时kubectl set image deployment/nginx-deployment nginxnginx:1.22-alpine --record # 或者通过修改yaml文件中的image字段再applyK8S会启动新的Pod1.22版本并逐步终止旧的Pod1.21版本。在这个过程中Service会确保流量只打到就绪的Pod上实现零停机更新。如果更新后发现问题一键回滚# 查看历史版本 kubectl rollout history deployment/nginx-deployment # 回滚到上一个版本 kubectl rollout undo deployment/nginx-deployment # 回滚到指定版本 kubectl rollout undo deployment/nginx-deployment --to-revision25. 高级运维场景与故障排查实录掌握了基础部署我们来看看更复杂的场景和那些“踩坑”经历。5.1 有状态应用部署以PostgreSQL为例“k8s部署pgsql”是个热门需求。对于数据库这类有状态应用我们需要用StatefulSet和PersistentVolume(PV)/PersistentVolumeClaim(PVC)。核心思路存储准备先准备持久化存储可以是云盘、NFS、Ceph等。这里以创建NFS类型的PV为例需提前搭建NFS服务器。使用StatefulSet它能为每个Pod提供稳定的网络标识如pg-0,pg-1和独立的持久化存储。Headless Service用于Pod间的DNS发现。简易示例单实例# postgresql-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: postgresql-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi --- # postgresql-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: postgresql spec: serviceName: postgresql replicas: 1 selector: matchLabels: app: postgresql template: metadata: labels: app: postgresql spec: containers: - name: postgresql image: postgres:14 env: - name: POSTGRES_PASSWORD valueFrom: secretKeyRef: # 密码应放在Secret中此处简化 name: postgresql-secret key: password ports: - containerPort: 5432 volumeMounts: - name: data mountPath: /var/lib/postgresql/data volumeClaimTemplates: # 关键为每个Pod自动创建PVC - metadata: name: data spec: accessModes: [ ReadWriteOnce ] resources: requests: storage: 10Gi踩坑记录StatefulSet的Pod是有序创建和终止的podManagementPolicy: Parallel可改为并行。删除StatefulSet时默认不会删除关联的PVC需要手动清理否则重新创建同名的StatefulSet会复用旧数据。5.2 常见故障排查命令与思路当Pod状态不是Running时别慌按顺序排查查看Pod详情kubectl describe pod pod-name。这是最常用、信息最全的命令关注Events部分经常直接报错原因如镜像拉取失败、节点资源不足。查看Pod日志kubectl logs pod-name。如果Pod内有多个容器用-c container-name指定。进入Pod调试kubectl exec -it pod-name -- /bin/sh。可以进去看看文件系统、进程状态、网络连通性。查看资源状态kubectl get nodes看节点是否Ready。kubectl get pods -o wide看Pod调度在哪个节点IP是什么。kubectl get svc,ep查看Service和对应的端点Pod IP是否正确。针对热词“k8s configmap执行脚本 permission denied”这通常发生在将ConfigMap挂载为文件时文件默认权限是644。如果容器内的进程用户非root需要执行该文件就会报权限拒绝。解决方法有两种在容器启动脚本中修改权限在Dockerfile的ENTRYPOINT或CMD脚本里先执行chmod x /path/to/script.sh。使用initContainer修改权限推荐在Pod定义中添加一个初始化容器以root身份运行专门负责修改挂载卷的权限。5.3 监控与日志收集自动化运维离不开可观测性。对于“prometheus监控k8s集群状态的详细操作注意prometheus在k8集群外”这个需求核心思路是利用K8S的API Server和Service发现机制。简化部署流程在集群内部署监控对象使用kube-prometheus-stack(原Prometheus Operator) Helm包一键部署Prometheus、Grafana以及针对K8S的各种Exporternode-exporter, kube-state-metrics等。它们会自动配置好对集群内资源的监控。使集群外Prometheus能够访问关键是将集群内Prometheus Service的端口如9090通过NodePort或LoadBalancer类型暴露到集群外。更安全的方式是使用Ingress配合认证。外部Prometheus配置在集群外的Prometheus配置文件中添加一个基于Kubernetes SD服务发现的job指定K8S API Server的地址和认证信息如bearer token让它自动发现集群内所有需要监控的TargetsNodes, Pods, Services等。日志方面EFKElasticsearch, Fluentd, Kibana或Loki是主流方案。Fluentd可以以DaemonSet形式运行在每个节点上自动收集节点和容器日志并发送到中心存储。6. 生产环境进阶考量与最佳实践当你要把K8S用于真实业务时以下这些点需要重点考虑。6.1 资源管理与调度优化设置合理的Requests和Limits这是保障集群稳定性的生命线。Requests用于调度K8S根据它选择有足够资源的节点Limits用于防止容器“发疯”。不设Limits等同于裸奔。使用命名空间进行资源配额通过ResourceQuota限制每个Namespace能使用的总CPU、内存、Pod数量等防止一个团队耗尽整个集群资源。节点亲和性与反亲和性控制Pod更喜欢或更不喜欢调度到哪些节点上可以用于实现高可用将同一服务的Pod分散到不同故障域或硬件偏好将有GPU需求的Pod调度到GPU节点。6.2 安全加固使用ServiceAccount为不同的Pod分配最小权限的ServiceAccount而不是使用默认的default。配置SecurityContext在Pod或容器级别限制权限如禁止以root运行、设置只读根文件系统等。镜像安全使用私有镜像仓库对镜像进行漏洞扫描避免使用latest标签。网络策略NetworkPolicy实现Pod之间的网络隔离默认情况下K8S集群内所有Pod网络是互通的这存在风险。NetworkPolicy可以定义“哪些Pod可以访问哪些Pod的哪些端口”。6.3 CI/CD与GitOps自动化运维的终极形态是与CI/CD流水线结合并走向GitOps。你可以将应用的所有K8S部署清单YAML文件存放在Git仓库中。当代码变更触发CI流程构建出新镜像后CD工具如Argo CD, Flux会自动监测镜像仓库或Git仓库的变化并将变更同步到K8S集群中实现“基础设施即代码”和“持续部署”。例如对于“ruoyi-cloud k8s 完整部署教程”这类复杂应用最佳实践就是编写一套完整的K8S清单包括Deployment, Service, ConfigMap, Ingress等放入项目仓库。通过Jenkins、GitLab CI等工具在构建镜像后自动更新清单中的镜像标签并kubectl apply。我个人在实践中最深的体会是K8S的学习曲线前期确实陡峭但一旦你接受了它的声明式哲学并将运维操作都转化为YAML文件和Git提交那种一切尽在掌控、可重复、可追溯的感觉是非常棒的。从手动敲命令到编写YAML再到用Helm打包最后实现GitOps每一步都是运维效率和系统稳定性的巨大提升。开始可能会觉得繁琐但请相信这些前期在设计和规范上的投入会在后期规模扩大和故障排查时带来成倍的回报。
1. 项目概述为什么我们需要K8S自动化运维容器在容器技术席卷软件交付流程的今天相信很多运维和开发朋友都经历过这样的场景手头管理着几十甚至上百个微服务每个服务都打包成了Docker镜像。本地测试一切顺利但一到生产环境服务发现、负载均衡、滚动更新、故障自愈这些事儿就让人头疼不已。你可能需要写一堆脚本去管理容器的启停手动配置Nginx做流量转发半夜被报警叫醒去处理某个挂掉的服务实例。这种“人肉运维”容器的方式在服务规模稍大一点后就变得难以维持效率低下且容易出错。这正是Kubernetes常简称为K8S要解决的核心问题。它不是一个简单的容器运行时而是一个容器编排平台。你可以把它理解为一个分布式的容器操作系统或者一个高度自动化的“容器云工厂”。它的目标是把运维人员从繁琐、重复的容器生命周期管理工作中解放出来通过声明式的配置和强大的控制循环实现从部署、伸缩、更新到监控、自愈的全流程自动化。我最初接触K8S时也觉得概念繁多有些望而却步。但真正用起来后发现一旦掌握了其核心模式它带来的运维效率提升是颠覆性的。今天我就结合自己从零搭建到生产实践的经验抛开那些复杂的理论直接聊聊如何利用K8S实现容器的自动化运维把那些热词背后大家真正关心的问题比如安装部署、常用命令、故障排查、与Docker的区别等揉碎了讲清楚。2. K8S自动化运维的核心设计思想在动手之前理解K8S的设计哲学至关重要。这能帮助你在后面遇到复杂配置或故障时知道该从哪里思考。2.1 声明式API与控制循环这是K8S最精髓的思想。传统运维往往是“命令式”的执行一条命令比如docker run让系统达到一个状态。而K8S是“声明式”的你告诉它你期望的系统最终状态是什么样子比如“运行3个Nginx实例使用80端口”然后K8S的控制器会持续地观察当前状态并驱动系统向期望状态收敛。举个例子你提交了一个Deployment配置文件声明需要3个副本replicas。K8S的Deployment控制器看到这个“期望状态”后会自动去创建对应的Pod容器组。如果某个Pod所在的节点宕机了当前状态只剩2个Pod与期望状态3个Pod不符控制器会立刻在其它健康节点上重新创建一个Pod直到恢复成3个。整个过程无需人工干预。实操心得养成用YAML文件定义资源的习惯。不要总用kubectl run这种命令式操作虽然快捷但不便版本管理和复用。把YAML文件纳入Git仓库运维即代码。2.2 核心对象模型解析K8S通过一系列抽象的资源对象来管理容器理解它们的关系是进行自动化运维的基础。PodK8S管理和调度的最小单位。一个Pod可以包含一个或多个紧密关联的容器比如一个Web应用容器和一个日志收集sidecar容器它们共享网络命名空间、存储卷等。Pod是短暂的会被频繁地创建和销毁。Deployment这是最常用的工作负载控制器。你通过Deployment来定义无状态应用的部署策略比如副本数、更新策略滚动更新。它负责确保指定数量的Pod副本始终运行。ServicePod的IP地址是不固定的Service为一组功能相同的Pod通常由Deployment管理提供一个稳定的访问入口虚拟IP和DNS名并负责负载均衡。ConfigMap Secret将配置信息和敏感数据如密码从容器镜像中解耦出来。你可以直接在YAML中引用它们实现配置的集中管理和动态更新无需重新构建镜像。Namespace逻辑上的资源隔离单元。可以将开发、测试、生产环境部署在不同的Namespace下方便管理和资源配额控制。Node运行容器的工作节点可以是物理机或虚拟机。每个Node上运行着Kubelet负责与Master通信管理本机Pod和容器运行时如Docker、containerd。2.3 K8S与Docker的关系澄清这是新手最容易混淆的点。简单来说Docker负责“造集装箱”构建和运行单个容器K8S负责“管理集装箱船队”编排和调度众多容器。Docker是一个容器化平台包含容器运行时、镜像构建工具等。它解决了“如何把应用及其依赖打包成一个标准、可移植的单元”的问题。K8S是一个容器编排系统。它不直接管理容器而是通过CRI容器运行时接口与Docker、containerd这样的容器运行时打交道。K8S负责决定在哪个节点上启动容器、如何将它们连接起来、如何扩缩容等更高层次的集群管理问题。现在很多生产环境为了追求更轻量、更稳定会直接用containerd替代Docker作为K8S的容器运行时但基本的容器概念和镜像标准OCI是相通的。3. 从零开始搭建一个可用的K8S集群理论说再多不如动手一试。这里我以最常用的方式使用kubeadm工具在CentOS 7系统上搭建一个单Master节点的集群。为什么选kubeadm因为它官方推荐、操作相对标准化适合学习和中小规模生产。3.1 前置准备与系统配置准备至少两台虚拟机或云服务器一台作为Master控制平面一台作为Node工作节点。配置要求2核CPU2GB内存以上网络互通。第一步基础环境配置所有节点执行# 1. 关闭防火墙、SELinux生产环境请根据安全策略调整 systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing$/SELINUXpermissive/ /etc/selinux/config # 2. 关闭swap交换分区K8S强制要求 swapoff -a sed -i / swap / s/^\(.*\)$/#\1/g /etc/fstab # 3. 配置内核参数并加载模块 cat EOF | sudo tee /etc/modules-load.d/k8s.conf br_netfilter EOF cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables 1 net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 EOF sysctl --system # 4. 配置yum源这里使用阿里云镜像 cat EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] nameKubernetes baseurlhttps://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled1 gpgcheck1 repo_gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF第二步安装容器运行时与K8S组件所有节点执行这里我们选择containerd它比Docker更轻量是未来趋势。# 1. 安装containerd yum install -y yum-utils device-mapper-persistent-data lvm2 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y containerd.io # 配置containerd使用systemd作为cgroup driver与kubelet保持一致 mkdir -p /etc/containerd containerd config default | tee /etc/containerd/config.toml sed -i s/SystemdCgroup false/SystemdCgroup true/ /etc/containerd/config.toml systemctl enable --now containerd # 2. 安装kubeadm, kubelet, kubectl yum install -y kubelet-1.23.0 kubeadm-1.23.0 kubectl-1.23.0 --disableexcludeskubernetes # 指定一个稳定版本如1.23.0 systemctl enable --now kubelet注意事项kubelet在安装后会不断重启是正常的因为它还在等待kubeadm的初始化指令。务必保持所有节点版本一致避免兼容性问题。3.2 初始化Master节点仅在Master节点执行。# 初始化集群使用阿里云镜像仓库加速 kubeadm init \ --apiserver-advertise-address192.168.1.100 \ # 替换为Master节点的实际IP --image-repository registry.aliyuncs.com/google_containers \ --kubernetes-version v1.23.0 \ --service-cidr10.96.0.0/12 \ --pod-network-cidr10.244.0.0/16 # 初始化成功后会输出类似下面的提示务必保存好 # Your Kubernetes control-plane has initialized successfully! # ... # To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config # 查看节点状态此时Master应为NotReady因为网络插件未安装 kubectl get nodes3.3 安装Pod网络插件CNIPod之间要能通信必须安装网络插件。这里选择最经典的Flannel。# 在Master节点执行 kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml # 等待片刻查看Pod状态直到所有CoreDNS和Flannel的Pod都Running kubectl get pods -n kube-system -w3.4 将Node节点加入集群在Master节点初始化成功输出的最后会有一条kubeadm join开头的命令。复制这条命令到你的Node节点上执行。# 在Node节点上执行示例命令具体token和hash以你初始化输出为准 kubeadm join 192.168.1.100:6443 --token xxxxxx.xxxxxxxxxxxxxx \ --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx加入成功后回到Master节点查看kubectl get nodes你应该能看到Master和Node的状态都变为Ready。至此一个最小的K8S集群就搭建完成了。4. 自动化运维实战部署与管理一个Web应用集群搭好了我们来真刀真枪地演练一下如何自动化部署一个应用。我们以部署一个Nginx为例但会覆盖完整的运维流程。4.1 使用Deployment部署应用创建文件nginx-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 # 声明期望运行3个副本 selector: matchLabels: app: nginx template: # Pod模板 metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21-alpine # 使用特定版本标签避免使用latest ports: - containerPort: 80 resources: requests: # 资源请求调度依据 memory: 64Mi cpu: 250m limits: # 资源上限防止容器失控 memory: 128Mi cpu: 500m livenessProbe: # 存活探针检查应用是否健康 httpGet: path: / port: 80 initialDelaySeconds: 5 # 容器启动后5秒开始探测 periodSeconds: 10 # 每10秒探测一次 readinessProbe: # 就绪探针检查应用是否可接收流量 httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5应用这个配置kubectl apply -f nginx-deployment.yaml关键点解析replicas: 3声明了期望状态Deployment控制器会确保始终有3个Pod在运行。resources为容器设置资源请求和限制这是保障集群稳定性的关键。没有限制一个失控的Pod可能吃光节点资源。livenessProbereadinessProbe自动化运维的“眼睛”。存活探针失败K8S会重启Pod就绪探针失败Service不会把流量转发给该Pod。这是实现服务自愈和高可用的核心机制。4.2 使用Service暴露应用Pod的IP不固定我们需要Service。创建nginx-service.yamlapiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx # 选择所有标签为appnginx的Pod ports: - protocol: TCP port: 80 # Service对外的端口 targetPort: 80 # 容器内部的端口 type: NodePort # 集群外可通过节点IP:NodePort访问应用并查看kubectl apply -f nginx-service.yaml kubectl get svc nginx-service输出中会有一个30000的端口如80:32678/TCP你就可以通过http://任意节点IP:32678访问到Nginx了。4.3 实现配置与代码分离ConfigMap假设我们需要修改Nginx的默认欢迎页面。我们不进入容器修改也不重建镜像而是用ConfigMap。创建nginx-configmap.yamlapiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: default.conf: | server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; } # 可以在这里添加自定义配置 } index.html: | !DOCTYPE html html headtitleHello from K8S ConfigMap!/title/head bodyh1This page is managed by ConfigMap!/h1/body /html然后更新Deployment将ConfigMap挂载到容器中# 在nginx-deployment.yaml的Pod模板spec.containers下添加 volumeMounts: - name: nginx-config-volume mountPath: /etc/nginx/conf.d/default.conf subPath: default.conf - name: nginx-config-volume mountPath: /usr/share/nginx/html/index.html subPath: index.html # 在spec.template.spec下添加与containers同级 volumes: - name: nginx-config-volume configMap: name: nginx-config应用更新kubectl apply -f nginx-deployment.yaml。K8S会自动滚动更新所有Pod新的Pod会使用ConfigMap中的配置。4.4 自动化滚动更新与回滚这是Deployment的杀手锏功能。当我们更新镜像版本时kubectl set image deployment/nginx-deployment nginxnginx:1.22-alpine --record # 或者通过修改yaml文件中的image字段再applyK8S会启动新的Pod1.22版本并逐步终止旧的Pod1.21版本。在这个过程中Service会确保流量只打到就绪的Pod上实现零停机更新。如果更新后发现问题一键回滚# 查看历史版本 kubectl rollout history deployment/nginx-deployment # 回滚到上一个版本 kubectl rollout undo deployment/nginx-deployment # 回滚到指定版本 kubectl rollout undo deployment/nginx-deployment --to-revision25. 高级运维场景与故障排查实录掌握了基础部署我们来看看更复杂的场景和那些“踩坑”经历。5.1 有状态应用部署以PostgreSQL为例“k8s部署pgsql”是个热门需求。对于数据库这类有状态应用我们需要用StatefulSet和PersistentVolume(PV)/PersistentVolumeClaim(PVC)。核心思路存储准备先准备持久化存储可以是云盘、NFS、Ceph等。这里以创建NFS类型的PV为例需提前搭建NFS服务器。使用StatefulSet它能为每个Pod提供稳定的网络标识如pg-0,pg-1和独立的持久化存储。Headless Service用于Pod间的DNS发现。简易示例单实例# postgresql-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: postgresql-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi --- # postgresql-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: postgresql spec: serviceName: postgresql replicas: 1 selector: matchLabels: app: postgresql template: metadata: labels: app: postgresql spec: containers: - name: postgresql image: postgres:14 env: - name: POSTGRES_PASSWORD valueFrom: secretKeyRef: # 密码应放在Secret中此处简化 name: postgresql-secret key: password ports: - containerPort: 5432 volumeMounts: - name: data mountPath: /var/lib/postgresql/data volumeClaimTemplates: # 关键为每个Pod自动创建PVC - metadata: name: data spec: accessModes: [ ReadWriteOnce ] resources: requests: storage: 10Gi踩坑记录StatefulSet的Pod是有序创建和终止的podManagementPolicy: Parallel可改为并行。删除StatefulSet时默认不会删除关联的PVC需要手动清理否则重新创建同名的StatefulSet会复用旧数据。5.2 常见故障排查命令与思路当Pod状态不是Running时别慌按顺序排查查看Pod详情kubectl describe pod pod-name。这是最常用、信息最全的命令关注Events部分经常直接报错原因如镜像拉取失败、节点资源不足。查看Pod日志kubectl logs pod-name。如果Pod内有多个容器用-c container-name指定。进入Pod调试kubectl exec -it pod-name -- /bin/sh。可以进去看看文件系统、进程状态、网络连通性。查看资源状态kubectl get nodes看节点是否Ready。kubectl get pods -o wide看Pod调度在哪个节点IP是什么。kubectl get svc,ep查看Service和对应的端点Pod IP是否正确。针对热词“k8s configmap执行脚本 permission denied”这通常发生在将ConfigMap挂载为文件时文件默认权限是644。如果容器内的进程用户非root需要执行该文件就会报权限拒绝。解决方法有两种在容器启动脚本中修改权限在Dockerfile的ENTRYPOINT或CMD脚本里先执行chmod x /path/to/script.sh。使用initContainer修改权限推荐在Pod定义中添加一个初始化容器以root身份运行专门负责修改挂载卷的权限。5.3 监控与日志收集自动化运维离不开可观测性。对于“prometheus监控k8s集群状态的详细操作注意prometheus在k8集群外”这个需求核心思路是利用K8S的API Server和Service发现机制。简化部署流程在集群内部署监控对象使用kube-prometheus-stack(原Prometheus Operator) Helm包一键部署Prometheus、Grafana以及针对K8S的各种Exporternode-exporter, kube-state-metrics等。它们会自动配置好对集群内资源的监控。使集群外Prometheus能够访问关键是将集群内Prometheus Service的端口如9090通过NodePort或LoadBalancer类型暴露到集群外。更安全的方式是使用Ingress配合认证。外部Prometheus配置在集群外的Prometheus配置文件中添加一个基于Kubernetes SD服务发现的job指定K8S API Server的地址和认证信息如bearer token让它自动发现集群内所有需要监控的TargetsNodes, Pods, Services等。日志方面EFKElasticsearch, Fluentd, Kibana或Loki是主流方案。Fluentd可以以DaemonSet形式运行在每个节点上自动收集节点和容器日志并发送到中心存储。6. 生产环境进阶考量与最佳实践当你要把K8S用于真实业务时以下这些点需要重点考虑。6.1 资源管理与调度优化设置合理的Requests和Limits这是保障集群稳定性的生命线。Requests用于调度K8S根据它选择有足够资源的节点Limits用于防止容器“发疯”。不设Limits等同于裸奔。使用命名空间进行资源配额通过ResourceQuota限制每个Namespace能使用的总CPU、内存、Pod数量等防止一个团队耗尽整个集群资源。节点亲和性与反亲和性控制Pod更喜欢或更不喜欢调度到哪些节点上可以用于实现高可用将同一服务的Pod分散到不同故障域或硬件偏好将有GPU需求的Pod调度到GPU节点。6.2 安全加固使用ServiceAccount为不同的Pod分配最小权限的ServiceAccount而不是使用默认的default。配置SecurityContext在Pod或容器级别限制权限如禁止以root运行、设置只读根文件系统等。镜像安全使用私有镜像仓库对镜像进行漏洞扫描避免使用latest标签。网络策略NetworkPolicy实现Pod之间的网络隔离默认情况下K8S集群内所有Pod网络是互通的这存在风险。NetworkPolicy可以定义“哪些Pod可以访问哪些Pod的哪些端口”。6.3 CI/CD与GitOps自动化运维的终极形态是与CI/CD流水线结合并走向GitOps。你可以将应用的所有K8S部署清单YAML文件存放在Git仓库中。当代码变更触发CI流程构建出新镜像后CD工具如Argo CD, Flux会自动监测镜像仓库或Git仓库的变化并将变更同步到K8S集群中实现“基础设施即代码”和“持续部署”。例如对于“ruoyi-cloud k8s 完整部署教程”这类复杂应用最佳实践就是编写一套完整的K8S清单包括Deployment, Service, ConfigMap, Ingress等放入项目仓库。通过Jenkins、GitLab CI等工具在构建镜像后自动更新清单中的镜像标签并kubectl apply。我个人在实践中最深的体会是K8S的学习曲线前期确实陡峭但一旦你接受了它的声明式哲学并将运维操作都转化为YAML文件和Git提交那种一切尽在掌控、可重复、可追溯的感觉是非常棒的。从手动敲命令到编写YAML再到用Helm打包最后实现GitOps每一步都是运维效率和系统稳定性的巨大提升。开始可能会觉得繁琐但请相信这些前期在设计和规范上的投入会在后期规模扩大和故障排查时带来成倍的回报。
)
