k8s 1.25学习4 - 使用Deployment、StatefulSet部署应用

k8s集群中apiserver是无状态的,可以有多台同时工作
Controller-Manager、scheduler是有状态的,会选举出一个master节点工作

#查看主节点
kubectl get leases -n kube-system

CoreDNS:Service路由解析

#显示和操作IP路由表
route -n

kubectl run mynginx --image=nginx
kubectl exec -it mynginx -- sh
#nameserver指向dns的IP
cat /etc/resolv.conf
exit

kubectl get svc -A | grep dns
kubectl delete pod mynginx

Pod常用命令

每个Pod包含一个Pause容器
Pause容器是Pod的父容器,负责僵尸进程的回收管理,通过Pause容器使同一个Pod里的容器共享存储、网络、PID、IPC等

#查看k8s.io命名空间内的静态容器
ctr -n k8s.io container ls
ctr -n k8s.io task ls

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/
Pod官方文档

使用文件创建Pod
#输出Pod的yaml文件,不会自动创建Pod
kubectl run nginx --image=nginx:1.15.12 -oyaml --dry-run=client > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx:1.15.12
    name: nginx

kubectl apply -f pod.yaml
查看yaml文件格式中的版本号
kubectl api-resources | grep pod
kubectl api-resources | grep deployment
覆盖镜像中entrypoint命令
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx:1.15.12
    name: nginx
    command: ["sleep", "10"]  #entrypoint
	
	
#查看帮忙文档	
kubectl explain Pod.spec.containers	

#command覆盖镜像中entrypoint
#args覆盖镜像中CMD中的参数

Pod镜像拉取策略
imagePullPolicy: IfNotPresent # 可选,镜像拉取策略,IfNotPresent、Never、IfNotPresent

Pod重启策略
#默认Always
#OnFailure:容器执行entrypoint命令后,以不为0的状态码终止,则自动重启该容器
restartPolicy: Always #Always、OnFailure、Never


Pod的三种探针

startupProbe:判断容器内的应用程序是否已经启动
livenessProbe:探测容器是否在运行;如果不满足健康条件,根据Pod中设置的restartPolicy(重启策略)来判断,Pod是否要进行重启操作
readinessProbe:探测容器内的程序是否健康,即判断容器是否为就绪(Ready)状态;不可用将从Service的Endpoints中移除

kubectl get svc -n kube-system
kubectl describe svc metrics-server -n kube-system
kubectl get pods -n kube-system -owide | grep metrics
kubectl get endpoints metrics-server -n kube-system

程序如果启动比较慢,需要使用startupProbe探针
只有等startupProbe检测通过了之后,才会开始检测livenessProbe、readinessProbe
应用启动时间大于30秒,就需要配置startupProbe,这样livenessProbe、readinessProbe的间隔检查时间就可以配置小一些了
vi nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.15.12
    imagePullPolicy: IfNotPresent
    command:
    - sh
    - -c
    - sleep 30; nginx -g "daemon off;"
    startupProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 10 # 初始化时间
      timeoutSeconds: 2 # 超时时间
      periodSeconds: 5 # 检测间隔
      successThreshold: 1 # 检查成功为2次表示就绪
      failureThreshold: 5 # 检测失败1次表示未就绪
    readinessProbe: 
      httpGet:
        path: /index.html
        port: 80
        scheme: HTTP
      initialDelaySeconds: 10 # 初始化时间, 健康检查延迟执行时间
      timeoutSeconds: 2 # 超时时间
      periodSeconds: 5 # 检测间隔
      successThreshold: 1 # 检查成功为2次表示就绪
      failureThreshold: 2 # 检测失败1次表示未就绪
    livenessProbe: # 可选,健康检查
      exec: # 端口检测方式
        command:
        - sh
        - -c
        - pgrep nginx
      initialDelaySeconds: 10 # 初始化时间
      timeoutSeconds: 2 # 超时时间
      periodSeconds: 5 # 检测间隔
      successThreshold: 1 # 检查成功为 2 次表示就绪
      failureThreshold: 2 # 检测失败 1 次表示未就绪
    ports:
    - containerPort: 80
  restartPolicy: Never
kubectl apply -f nginx-pod.xml
kubectl delete -f nginx-pod.xml
preStop容器停止前执行指令

vi pod-preStop.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.15.12
    imagePullPolicy: IfNotPresent
    lifecycle:
      preStop:
       exec:
         command:
         - sh
         - -c
         - sleep 10
    ports: 
    - containerPort: 80 
  restartPolicy: Never
kubectl apply -f pod-preStop.yaml
kubectl delete -f pod-preStop.yaml

无状态应用管理Deployment

Replication Controller可确保Pod副本数达到期望值,即确保一个Pod或一组同类Pod总是可用
ReplicaSet是支持基于集合的标签选择器的下一代Replication Controller
它主要用作Deployment协调创建、删除和更新Pod,和Replication Controller唯一的区别是,ReplicaSet支持标签选择器

#生成deployment模板
kubectl create deploy nginx --image=nginx:1.15.12-alpine --replicas=3 -oyaml --dry-run=client > nginx-deploy.yaml
kubectl apply -f nginx-deploy.yaml
kubectl get deploy
kubectl get rs
kubectl get pod
kubectl delete pod nginx-b7599c689-qchww
kubectl get pod

查看整个Deployment创建的状态

kubectl rollout status deployment/nginx
kubectl get deploy
kubectl get rs -l app=nginx
kubectl get pods --show-label

更新Deployment

kubectl set image deployment nginx nginx=nginx:1.13 --record
kubectl rollout status deployment/nginx
kubectl describe deploy nginx

回滚Deployment

#查看历史版本
kubectl rollout history deployment nginx

#查看某一个版本的信息
kubectl rollout history deployment nginx --revision=3

#回滚到上一个版本
kubectl rollout undo deployment nginx

#回滚到指定版本
kubectl rollout undo deployment nginx --to-revision=3

扩容

kubectl scala deployment nginx --replicas=5 

暂停和恢复Deployment更新

kubectl rollout pause deployment nginx
#更新配置信息,但不重启pod
kubectl set image deployment nginx nginx=1.15.12-alpine --record
kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
#恢复pod,自动更新
kubectl rollout resume deployment nginx
kubectl get rs

Deployment更新策略
.spec.strategy.type==RollingUpdate,默认滚动更新
.spec.strategy.rollingUpdate.maxUnavailable,指定在回滚更新时最大不可用的Pod数量,默认为25%
.spec.strategy.rollingUpdate.maxSurge可以超过期望值的最大Pod数,默认为25%(一次启动多个副本,最大限制数量)


StatefulSet部署有状态应用

#StatefulSet服务域名格式:StatefulSetName-0.ServiceName.Namepace.svc.cluster.local
web-0.nginx.default.svc.cluster.local

StatefulSet需要创建一个Service对外提供服务
vi statefulset.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
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  minReadySeconds: 10 # by default is 0
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx:1.15.12-alpine
        ports:
        - containerPort: 80
          name: web

创建

kubectl apply -f statefulset.yaml
kubectl rollout status sts web
kubectl get pods
kubectl get sts

Pod创建时按顺序一个一个单独创建,缩容时按倒序一个一个接着关闭

kubectl exec -it web-2 --sh 
curl web-0.nginx.default.svc.cluster.local
nslookup web-0.nginx.default.svc.cluster.local

扩容

kubectl scale sts web --replicas=5
kubectl get pods
StatefulSet更新策略

RollingUpdate默认滚动更新

分段更新partition

  updateStrategy:
    rollingUpdate:
      partition: 0
    type: RollingUpdate

partition默认值为0,表示更新后缀大于等于0的Pod;如果配置为3,则表示只更新后缀大于等于3的Pod,而小于3的Pod不会更新;可以用于灰度测试

删除sts

kubectl delete sts web
kubectl get sts
kubectl get pod 

#删除default命名空间中的所有pod
kubectl delete pod --all

守护进程集DaemonSet

每个节点上可以有一个守护进程集

kubectl get ds -n kube-system

#DaemonSet的yaml与Deployment类似,只是少了副本这一个参数
#删除replicas: 3,修改kind: DaemonSet
cp nginx-deploy.yaml nginx-ds.yaml
kubectl apply -f nginx-ds.yaml
kubectl get ds
kubectl get pods

查看node节点上的label

kubectl get node --show-labels
#node节点上增加label
kubectl label node k8s-node2 k8s-node3 disktype=ssd
kubectl get node --show-labels

指定节点部署Pod:.spec.template.spec.nodeSelector

#节点选择器
    nodeSelector:
      disktype: ssd
kubectl apply -f nginx-ds.yaml
kubectl get pods -owide


kubectl get ds -oyaml
kubectl get ds 
kubectl rollout status ds/nginx
kubectl rollout history daemonset nginx
kubectl rollout undo daemonset nginx
kubectl get controllerrevision
kubectl delete -f nginx-ds.yaml

HPA自动扩缩容

kubectl get apiservices | grep autoscaling
kbuectl create deployment hpa-nginx --image=nginx:1.15.12-alpine --dry-run=client -oyaml > hpa-nginx.yaml

1颗CPU是1000m
创建一个deploy,限制CPU资源为10m

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hpa-nginx
  name: hpa-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hpa-nginx
  template:
    metadata:
      labels:
        app: hpa-nginx
    spec:
      containers:
      - image: nginx:1.15.12-alpine
        name: nginx
        resources: 
          requests: 
            cpu: 10m

创建

kubectl apply -f hpa-nginx.yaml 
kubectl get deploy

#创建Service
kubectl expose deploy hpa-nginx --port=80
kubectl get svc
curl http://10.96.226.0
kubectl top pods

创建hpa

#CPU使用率超过10%时开始扩容
kubectl autoscale deploy hpa-nginx --cpu-percent=10 --min=1 --max=10
kubectl get hpa
kubectl get hpa -oyaml

压测

kubectl get svc
#增大访问压力
while true; do wget -q -O - http://10.96.226.0 > /dev/null; done
kubectl top pods
kubectl logs -f hpa-nginx-54c8954b44-j5spv
kubectl top pods
kubectl get hpa
kubectl delete -f hpa-nginx.yaml

Label标签选择器

Label可以对k8s的一些对象进行分组,用于区分同样的资源不同的分组
Selector可以根据资源的标签查询出精确的对象信息
一般不修改Pod的标签,常修改Node的标签

kubectl get pods --show-labels
kubectl get pods -l app=nginx
kubectl get nodes --show-labels
kubectl get nodes -l disktype=ssd
kubectl get svc -n kube-system --show-labels

给节点打标签

kubectl label node k8s-node2 region=sz
kubectl get node -l region=sz


#yaml使用nodeSelector选择部署在指定的节点上
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        region: sz

获取label中disktype为nginx或者ssd的数据

kubectl get nodes -l 'disktype in (nginx, ssd)' --show-labels

#匹配多个条件
kubectl get nodes -l 'region!=sz, disktype in (nginx, ssd)' --show-labels

#匹配是否存在标签
kubectl get nodes -l region

修改标签

kubectl label node k8s-node2 region=sh --overwrite

#批量修改标签
kubectl label node -l region region=wh --overwrite

删除标签

kubectl label node k8s-node2 region-
<think>嗯,用户想了解如何部署高可用Kubernetes集群。首先,我需要回忆一下高可用Kubernetes的关键点。高可用性通常涉及多个控制平面节点,确保即使一个节点故障,集群仍能正常运行。用户可能在生产环境中使用,所以可靠性和冗余很重要。 首先,应该考虑集群架构。传统的Kubernetes高可用架构需要至少三个控制平面节点,分布在不同的物理服务器或云实例上。这样可以利用etcd的分布式特性,确保数据一致性和容错。另外,负载均衡器也是关键,用于将流量分发到各个控制平面节点的API Server。用户可能对负载均衡器的选择有疑问,比如是用云服务商的LB还是自建(如HAProxy、Keepalived)。 接下来是etcd集群的部署。etcd作为Kubernetes的后端存储,必须高可用。通常有三种部署方式:堆叠式(Stacked)和外部式(External)。堆叠式是将etcd与控制平面节点部署在一起,而外部式则是独立部署etcd集群。用户可能需要了解这两种方式的优缺点,比如堆叠式简化部署,但外部式可能更稳定。 然后是Kubernetes组件的配置。比如kube-apiserver需要配置为连接负载均衡器的地址,而不是单个节点。kube-controller-manager和kube-scheduler需要启用leader选举,确保只有一个实例处于活动状态。用户可能对如何配置这些组件的参数不太清楚,需要具体步骤。 安装工具的选择也很重要。用户可能习惯使用kubeadm,或者其它工具如kops、Rancher等。这里可能需要以kubeadm为例,因为它是官方工具,适合大多数用户。但要注意不同Kubernetes版本的差异,比如1.25之后的一些变化。 网络插件方面,用户需要选择支持高可用的CNI插件,如Calico、Flannel、Cilium等。此外,Pod和Service的网络规划也需要考虑,避免IP冲突,并确保网络策略符合需求。 存储方面,高可用集群需要可靠的存储解决方案,如Ceph、Longhorn或云存储。用户可能需要持久卷的动态供应,这需要StorageClass的配置。 节点的高可用也不容忽视,工作节点需要足够数量,并分布在不同的故障域。同时,部署应用使用DeploymentStatefulSet,并配置Pod反亲和性,避免单点故障。 证书和安全性也是重点。控制平面组件使用TLS通信,证书需要有效且定期更新。可能涉及使用cfssl或cert-manager来管理证书。 监控和日志系统,如Prometheus、Grafana、EFK,帮助及时发现问题。用户可能不了解如何集成这些工具,需要简要说明。 最后,备份和灾难恢复计划。定期备份etcd数据,并测试恢复流程,确保在灾难时能快速恢复。 用户可能还关心具体的操作步骤,比如使用kubeadm初始化集群,添加控制平面节点,配置负载均衡器等。需要分步骤说明,确保清晰易懂。同时,注意版本兼容性和系统要求,如禁用swap、正确配置防火墙等。 可能遇到的常见问题包括etcd节点间通信问题、证书配置错误、负载均衡器配置不当导致API Server不可用。需要提醒用户检查网络连通性,验证证书有效性,以及测试负载均衡器的健康检查。 总结下来,回答需要结构清晰,分步骤讲解,涵盖架构设计、组件配置、工具选择、网络存储、监控备份等各个方面,同时给出具体命令示例和注意事项,确保用户能够逐步实施并避免常见陷阱。</think>部署高可用 Kubernetes 集群的核心目标是消除单点故障,确保控制平面和关键组件在节点故障时仍能稳定运行。以下是分步指南: --- ### **一、架构设计** 1. **控制平面高可用** - 至少部署 **3 个 Master 节点**(奇数个以解决 etcd 选举问题) - 使用 **负载均衡器(LB)** 代理 API Server 流量(如 HAProxy + Keepalived 或云厂商 LB) - 拓扑模式选择: - **堆叠式(Stacked)**:每个 Master 节点同时运行 API Server 和 etcd - **外部 etcd**:独立部署 3 个 etcd 节点(更高隔离性但复杂度增加) 2. **工作节点** - 根据业务需求横向扩展,建议至少 2 个 Worker 节点 - 跨可用区(AZ)部署以提升容灾能力 --- ### **二、部署步骤** #### **1. 前置准备** ```bash # 所有节点执行 # 关闭 Swap sudo swapoff -a sed -i '/swap/s/^/#/' /etc/fstab # 配置内核参数 cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter # 配置 sysctl cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl --system ``` #### **2. 安装容器运行时(以 Containerd 为例)** ```bash # 所有节点安装 Containerd apt-get update && apt-get install -y containerd sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl restart containerd ``` #### **3. 使用 kubeadm 部署控制平面** **首个 Master 节点初始化** ```bash sudo kubeadm init \ --control-plane-endpoint "LOAD_BALANCER_IP:6443" \ --upload-certs \ --pod-network-cidr=10.244.0.0/16 ``` **添加其他 Master 节点** ```bash # 根据 kubeadm init 输出的命令加入集群 kubeadm join LOAD_BALANCER_IP:6443 \ --token <token> \ --discovery-token-ca-cert-hash <hash> \ --control-plane \ --certificate-key <key> ``` #### **4. 部署网络插件(以 Calico 为例)** ```bash kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml ``` #### **5. 验证集群状态** ```bash kubectl get nodes -o wide kubectl get componentstatus # 检查控制平面组件健康状态 ``` --- ### **三、关键配置优化** 1. **etcd 调优** - 启用 etcd 自动快照备份 - 配置心跳间隔(`--heartbeat-interval`)和选举超时(`--election-timeout`) 2. **API Server 负载均衡** - 配置 LB 健康检查指向 API Server 的 6443 端口 - 使用 TCP 而非 HTTP 检查(API Server 不响应 HTTP 根路径) 3. **证书管理** - 使用 `kubeadm certs renew` 定期更新证书 - 或集成 cert-manager 实现自动化 --- ### **四、高可用附加组件** | 组件 | 作用 | 推荐工具 | |------------------|-----------------------------|-----------------------| | 持久化存储 | 提供跨节点数据持久化 | Rook (Ceph)、Longhorn | | 监控告警 | 实时监控集群状态 | Prometheus + Grafana | | 日志收集 | 聚合容器日志 | EFK (Elasticsearch+Fluentd+Kibana) | | 灾难恢复 | etcd 数据备份与恢复 | etcdctl snapshot | --- ### **五、常见问题排查** - **API Server 不可达**:检查 LB 配置、防火墙规则(6443 端口) - **etcd 集群故障**:使用 `etcdctl endpoint status` 验证节点健康 - **证书过期**:`kubeadm certs check-expiration` 查看有效期 --- ### **六、生产建议** 1. 使用基础设施即代码(IaC)工具(如 Terraform)管理节点生命周期 2. 定期执行混沌测试(如使用 Chaos Mesh)验证高可用性 3. 遵循最小权限原则,配置 RBAC 和网络策略 通过以上步骤,可构建一个符合生产要求的高可用 Kubernetes 集群。实际部署时需根据业务规模、云环境特性(如 AWS EBS 卷绑定)调整细节。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

GalenZhang888

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值