2、k8s命令(pod相关(驱逐、强制删除)、让Master当Node用、修改nodeport端口范围、修改k8sDNS、运行nslookup容器)

一、pod相关(驱逐、强制删除)

1、kubectl drain可以让node在维护期间排除节点。drain本意排水,意思是将出问题的node下的pod转移到其它node下运行。

kubectl drain nodename --delete-local-data --ignore-daemonsets --force

2、将node置为SchedulingDisabled不可调度状态

kubectl cordon nodename

将node置为SchedulingDisabled不可调度状态,后续的新创建pod容器时scheduler调度不会考虑该node,旧的pod容器不会受影响,仍可以对外提供正常服务。(特殊情况:pod容器如果跟node绑定的话,容器下次更新就不会回到原宿主机,该情况如何处理呢?可能设置成不可调度状态就不太合适。调度器 预调度策略)

恢复调度

kubectl uncordon nodename

3、Terminating可使用kubectl中的强制删除命令

# 删除POD
kubectl delete pod PODNAME --force --grace-period=0

二、让Master也能当作Node使用

#将 Master 也当作 Node 使用
kubectl taint node nodename node-role.kubernetes.io/master-

[root@app01 home]# kubectl taint node app01 node-role.kubernetes.io/master-
node/app01 untainted
[root@app01 home]# 

#将 Master 恢复成 Master Only 状态
kubectl taint node nodename node-role.kubernetes.io/master="":NoSchedule
  
[root@app01 rabbitmq]# kubectl taint node app01  node-role.kubernetes.io/master="":NoSchedule
node/app01 tainted
[root@app01 rabbitmq]# 

三、修改nodeport端口范围(nodePort 端口默认范围为:30000-32767)

  1. 编辑 kube-apiserver.yaml文件
vim /etc/kubernetes/manifests/kube-apiserver.yaml
  1. 找到 --service-cluster-ip-range 这一行,在这一行的下一行增加 如下内容
    - --service-node-port-range=30000-50000

示例如下:

kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
 2. command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
    - --advertise-address=192.168.180.37
    - --allow-privileged=true
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --disable-admission-plugins=PersistentVolumeLabel
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --insecure-port=0
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-cluster-ip-range=10.96.0.0/12
    - --service-node-port-range=30000-50000
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
  1. 最后 重启 kubelet
systemctl daemon-reload
systemctl restart kubelet

四、修改k8sDNS

1、查看coredns配置

[root@dev15 ~]# kubectl get  configmap coredns  -n kube-system -o yaml
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           upstream
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy . /etc/resolv.conf
        cache 30
        reload
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-10-21T05:57:32Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "77720660"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: ac49f58c-f3c7-11e9-a4a8-005056974fea
[root@dev15 ~]#

2、增加DNS配置
hosts {
192.168.168.168 sft-ap.pfizer.com sft-am.pfizer.com
fallthrough
}

[root@dev15 ~]# kubectl edit configmap coredns -n kube-system
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           upstream
           fallthrough in-addr.arpa ip6.arpa
        }
        hosts {
          192.168.168.168 sft-ap.pfizer.com sft-am.pfizer.com
          fallthrough
        }
        prometheus :9153
        proxy . /etc/resolv.conf
        cache 30
        reload
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-10-21T05:57:32Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "77720660"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: ac49f58c-f3c7-11e9-a4a8-005056974fea
[root@dev15 ~]#

五、运行nslookup容器

kubectl run -it --image busybox:1.28.4 dns-test --restart=Never --rm sh

六、查看configmap文件

[root@dev15 kubeadm_v1.11.0]# kubectl get cm --all-namespaces
NAMESPACE            NAME                                 DATA   AGE
filebeat-namespace   filebeat-config                      1      394d
filebeat-namespace   filebeat-inputs                      1      394d
kube-public          cluster-info                         4      626d
kube-system          coredns                              1      626d
kube-system          extension-apiserver-authentication   6      626d
kube-system          kube-flannel-cfg                     2      395d
kube-system          kube-proxy                           2      626d
kube-system          kubeadm-config                       2      626d
kube-system          kubelet-config-1.11                  1      626d
kube-system          kubelet-config-1.12                  1      428d
kube-system          kubelet-config-1.13                  1      428d
kube-system          kubernetes-dashboard-settings        1      626d
kube-system          prometheus-config                    1      220d

[root@dev15 net.d]# kubectl get configmap coredns  -n kube-system -o yaml
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           upstream
           fallthrough in-addr.arpa ip6.arpa
        }
        hosts {
          192.168.168.12 sft-ap.pfizer.com sft-am.pfizer.com
          fallthrough
        }
        prometheus :9153
        proxy . /etc/resolv.conf
        cache 30
        reload
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-10-21T05:57:32Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "95879867"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: ac49f58c-f3c7-11e9-a4a8-005056974fea
[root@dev15 net.d]#
<think>嗯,用户让我介绍一下Kubernetesk8s)的优化。首先,我需要确定用户的基础知识水平,可能他们已经对k8s有一定了解,现在想深入优化方面。优化涉及多个层面,比如资源管理、调度、网络、存储、监控等。我需要分步骤来组织思路,确保覆盖主要方面,同时保持结构清晰。 首先,资源管理是关键。用户可能遇到节点资源利用率低或者Pod竞争资源的问题。要解释如何设置资源请求和限制,包括CPU和内存。然后,Horizontal Pod Autoscaler(HPA)和Cluster Autoscaler(CA)的使用,这些自动扩展机制能帮助应对负载变化。 接下来是调度优化。默认调度器可能不够高效,所以需要讨论节点亲和性、污点和容忍、Pod间亲和性/反亲和性。这些策略能优化Pod的分布,提升性能和稳定性。比如,避免同一服务的多个Pod集中在同一节点,减少单点故障风险。 网络方面,服务发现和网络策略可能影响性能。需要提到选择高效的CNI插件,比如Calico或Cilium,以及使用网络策略限制不必要的流量,减少延迟。此外,Ingress控制器的选择和优化,比如使用Nginx或Traefik,并配置缓存和压缩。 存储优化也不可忽视。持久卷的选择,比如本地存储还是网络存储,以及调整I/O参数。使用StorageClass动态分配存储资源,避免手动管理带来的延迟。另外,临时存储的清理策略,防止资源泄露。 监控和日志是关键运维部分。Prometheus和Grafana的组合用于监控集群状态,而EFK或Loki处理日志。需要说明如何分析监控数据定位瓶颈,比如高CPU使用率或内存泄漏。 配置方面,etcd作为关键组件,其性能影响整个集群。优化etcd的存储和网络配置,比如使用SSD磁盘,减少写入操作。同时,kubelet和API Server的参数调优,比如调整--max-requests-inflight限制,防止API过载。 安全性优化可能用户也会关心,比如RBAC的细粒度控制,镜像的安全扫描,网络策略限制非授权访问。不过用户主要问优化,这部分可能需要简要提及。 最后,应用层面的优化,比如容器镜像的轻量化,减少启动时间;健康检查配置,确保快速故障恢复;合理设置副本数,平衡资源使用和可用性。 需要考虑用户可能的实际场景,比如他们是否在云环境或本地部署,不同的环境优化策略可能不同。例如,云环境中Cluster Autoscaler更常用,而本地可能需要更多手动调整。另外,用户是否已经遇到特定问题,比如Pod频繁被驱逐或API延迟高,可能需要针对性建议。 需要避免过于技术化的术语,用易懂的中文解释概念,同时保持专业性。结构上分点列出,每个部分给出具体方法和示例,帮助用户逐步实施优化措施。可能还要提醒用户优化是一个持续过程,需要监控和调整,建议定期审查集群配置和应用需求。</think>Kubernetesk8s)优化是一个系统工程,需从资源调度、网络性能、存储效率等多个维度切入。以下是分步骤的优化策略: --- ### 一、资源管理与调度优化 1. **资源请求/限制精准化** - 所有Pod必须设置`resources.requests`和`resources.limits` ```yaml containers: - name: nginx resources: requests: cpu: "100m" # 初始分配量 memory: "128Mi" limits: cpu: "200m" # 硬上限 memory: "256Mi" ``` - **作用**:避免节点资源争抢,防止OOM Killer误杀进程 2. **Horizontal Pod Autoscaler(HPA)调优** - 基于自定义指标(如QPS、连接数)触发扩缩容 ```bash kubectl autoscale deployment myapp --cpu-percent=60 --min=2 --max=10 ``` - 推荐使用Kubernetes Metrics Server + Prometheus Adapter 3. **调度器策略增强** - 使用`nodeAffinity`/`podAntiAffinity`避免单点故障 ```yaml affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: [myapp] topologyKey: "kubernetes.io/hostname" ``` - 通过`topologySpreadConstraints`实现Zone级均衡分布 --- ### 二、网络性能优化 1. **CNI插件选型** - 高性能场景选择**Cilium**(eBPF加速)或**Calico**(IPIP模式调优) - 避免Flannel的VxLAN模式在大规模集群中的性能衰减 2. **Service流量优化** - 使用`IPVS`代理模式替代默认的`iptables` ```bash kubectl edit cm kube-proxy -n kube-system # 修改mode: "ipvs" ``` - 对高QPS服务启用`ExternalTrafficPolicy: Local`减少网络跳转 3. **Ingress控制器调优** - Nginx Ingress启用`enable-underscores-in-headers`和`keepalive`配置 - 使用**WebAssembly(Wasm)**插件实现边缘计算加速 --- ### 三、存储性能优化 1. **存储卷类型选择** - 高频IO场景使用**本地SSD卷**(Local PersistentVolume) - 分布式存储推荐**Rook/Ceph**或云厂商的Block Storage 2. **CSI驱动优化** - 调整`volumeBindingMode: WaitForFirstConsumer`延迟绑定 - 设置合理的`fsType`(如ext4/xfs对NVMe SSD的性能差异) --- ### 四、集群组件调优 1. **etcd性能保障** - 分离etcd集群与业务节点,使用专用SSD磁盘 - 设置`--auto-compaction-retention=1h`定期压缩历史数据 2. **kube-apiserver参数** - 增加`--max-requests-inflight=1500`和`--max-mutating-requests-inflight=500` - 启用`--enable-priority-and-fairness`避免API饥饿 3. **kubelet配置** - 设置`--image-gc-high-threshold=85`防止镜像占满磁盘 - 调整`--kube-api-qps=50`提升节点心跳响应速度 --- ### 五、监控与诊断 1. **黄金指标监控** - 使用Prometheus监控四类关键指标: - 节点资源:$$ \text{CPU利用率} = \frac{\sum \text{容器CPU使用量}}{\sum \text{节点CPU总量}} $$ - Pod状态异常率 - 网络丢包率 - 存储IO延迟 2. **分布式追踪集成** - 通过**Jaeger**或**OpenTelemetry**定位微服务链路瓶颈 --- ### 六、进阶优化手段 1. **Serverless架构融合** - 使用**Knative**实现请求驱动的自动扩缩(缩容到零) 2. **异构资源调度** - 通过**NVIDIA GPU Operator**管理AI训练任务 - 使用**Kubernetes Device Plugins**调度FPGA等专用硬件 3. **安全加固** - 启用Pod Security Admission(PSA)策略 - 使用**Kyverno**或**OPA Gatekeeper**实现策略即代码 --- ### 优化效果验证 通过压力测试量化改进效果: $$ \text{提升比} = \frac{\text{优化前TPS}}{\text{优化后TPS}} \times 100\% $$ 建议使用**k6**或**Locust**进行基准测试。 --- 优化需遵循迭代原则,建议每次只修改一个变量并通过监控观察效果。生产环境应先在小规模测试集群验证后再全量实施。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值