K8s常见问题分析&解决(未分类问题二)

本文探讨Kubernetes(K8s)中常见的七大问题,包括容器时间同步、hosts配置、Pod滚动更新策略、存活检测、Java应用时区、网络互通与隔离。提供详细的解决步骤,如配置时区文件挂载、利用HostAliases、设置滚动更新策略、配置liveness探针等。

1:容器内部时间和node节点的系统时间不一致

详细描述:
    容器内部时间和node节点的系统时间不一致
    例如: kubectl exec -it <pod-name> date
         UTC 2019
         node 上的date    CST
解题思路:
    无
原因分析:
    这个不单单是K8s问题, 单纯使用docker也存在类似的问题
解决步骤:
    将物理机的时区文件以hostpath方式只读挂载,这样只要保证物理机的系统时间正确即可
    修改yaml文件中:
    containers:
    -mountPath: /etc/localtime
      name: vol-localtime
      readOnly: true
    volumes:
        -name: vol-localtime
        hostpath:
            path: /etc/localtime

2:pod内部hosts文件问题

详细描述:
    pod内部hosts文件问题
解题思路:
原因分析:
    默认情况下, k8s会将pod的hostname和ip地址添加到hosts文件里面,实际应用场景下会有手动去追加hosts文件记录的需求,而pod的生存周期是不固定的,增对这部分官方提供了hostalias解决方案:https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/
解决步骤:
    通过配置pod内部hosts文件的初衷有两个:
    1: 有些微服务之间的调用走的是公网的解析,效率低且DNS有时候会出现响应超时问题
    2:目前开放、测试和现网环境,本质上代码是同一套
    我们可以通过配置hosts记录,可以将程序连接mysql、mongodb、mq这些公共服务的名称固定,不同的环境对应的公共服务的IP地址通过hostalias方式注入,可以有效避免由于配置的原因导致的问题。
    对应yaml中的内容:
    spec:
        hostAliases:
           - ip: "xx.xxx.xx.xxx"
        hostnames:
         - "mysql-master"
         - "proxysql-server"
         - "redis-server"

3:Pod 滚动更新问题

详细描述:
    Pod 滚动更新问题
    在只配置一个POD副本且为配置滚动升级的情况下,需要对POD进行升级重启的时候,会马上把仅有的一个正常的POD关闭掉,同时启动一个新的POD,这个过程中服务会短暂不可用。
解题思路:
    无
原因分析:
    无
解决步骤:
    配置滚动更新策略
strategy:
    type: RollingUpdate
    rollingUpdate:
       maxUnavailable: 25%
       maxSurge: 25%
revisionHistoryLimit: 10
progressDeadlineSeconds: 600

4: 存活检测和工作负载检测

 

详细描述:
    存活检测和工作负载检测
    当POD内的进程不工作或者OOM了,需要进行自我重启工作,未配置liveness情况下是无法检测和处理类似情况
解题思路:
    无
原因分析:
    无
解决步骤:
    配置liveness和readiness探针
livenessProbe:
    exec:
        command:
           - curl
           - "http://127.0.0.1:8080"
    initialDelaySeconds: 60
    timeoutSeconds: 2
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3
readlinessProbe:
    tcpSocket:
        port: 8080
    initialDelaySeconds: 90
    timeoutSeconds: 3
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
这里需要说明一下liveness探针主要用来判断POD内的进程是否存活,readiness探针用来判断pod内的进程是否已准备就绪,在未就绪之前,对应service的流量不会转发到pod内。

5:java应用时区同步问题

详细描述:
    java应用时区同步问题
    JVM启动时候的时区。如果不指定,则默认取系统时区,这就会导致java应用的时间和容器时间差8个小时。
解题思路:
    无
原因分析:
    无
解决步骤:
    通过配置JAVA_OPTS设置java时区(同样JVM的内存参数也可以通过这种方式配置)
    -Duser.timezone=GMT+08 或者 -Duser.timezone=Asia/Shanghai
    yaml文件:
    env:
    -name: JAVA_OPTS
    value: >-
       -Duser.timezone=Asia/Shanghai

6:集群内外网络互通问题

详细描述:
    集群内外网络互通问题
解题思路:
    K8s集群不同node上的pod网络通信是通过cni网络插件(例如flannel、calico等)实现的,路由信息保存在etcd中,pod网络访问互联网通过node的iptables nat实现。
    但在实际应用环境中,需求总是多样的,当在k8s集群外部的主机需要直接访问pod网络的时候,就需要通过配置路由手段才能实现
原因分析:
    无
解决步骤:
    对应解决方案为添加路由:
    和node节点在同一个网段内的主机,将对应的网络的下一跳地址指向相应的node节点即可。
    和node节点不在同一网段内的主机,需要在上层路由器进行配置。

7:Pod间网络隔离

详细描述:
    Pod间网络隔离
解题思路:
    无
原因分析:
    默认Pod是未隔离的,POD之间的网络畅通无阻,实际应用中,会有配置网络隔离的需求,比如需要在pod间做流量的精细控制。
解决步骤:
    使用networkpolicy(要求集群的CNI插件可以支持networkpolicy)

 

 

 

 

 

&lt;think&gt;嗯,用户之前问了后端系统的安全性,现在转向了Kubernetes的常见用法,看来他对系统架构和运维方面比较感兴趣。需要整理k8s的常见用法,可能用户刚开始接触k8s,或者想系统化自己的知识。用户可能是在准备面试,或者在实际工作中需要部署和管理容器化应用,所以需要一份清晰的指南。 首先,我得确定用户对k8s的了解程度。之前的回答结构很详细,用户可能期待类似的层次结构。需要覆盖基本概念、核心功能、常用操作、网络存储、运维监控、安全、扩展和生态系统等方面。 要确保回答结构清晰,分点列出,每个部分有子项。例如,核心功能包括部署、扩缩容、配置管理、服务发现、存储管理、自动修复、滚动更新、任务调度。常用操作涉及kubectl命令,可能需要具体例子,但用户可能需要太详细的命令,而是分类说明。 还要注意用户可能关心的实际应用场景,比如如何做CI/CD集成,监控方案选型,或者安全策略。之前的回答中有提到安全维度,所以在k8s这里也需要涉及RBAC、网络策略、密钥管理等内容。 用户可能还需要了解k8s的生态系统,比如Helm、Operators、Service Mesh等工具,这些能帮助他们扩展功能。另外,常见问题如Pod故障排查、资源优化、网络问题等也是实际使用中会遇到的问题,需要给出解决思路。 需要避免太技术化的术语,但保持专业性。比如解释Deployment和StatefulSet的区别时,要简明扼要。同时,结合之前的回答风格,可能用户喜欢表格和公式,比如在核心功能部分用表格区分控制器类型,或者在资源配额部分用数学表达式。 还要注意用户可能没提到的深层需求,比如如何选择存储类型,或者如何监控集群健康状态,这些在整理常见用法时也应涵盖。最后,确保回答有总结,强调k8s的优势和适用场景,帮助用户形成整体认识。&lt;/think&gt;以下是对Kubernetes常见用法的系统化整理,采用分层结构说明核心功能和应用场景: --- ### 一、核心功能模块 | 功能分类 | 实现方式 | 典型应用场景 | 数学表达示例 | |----------------|---------------------------|----------------------------------|-----------------------------------| | **部署管理** | Deployment | 无状态应用滚动更新 | 副本数 $replicas = \lceil \frac{QPS}{1000} \rceil$ | | **有状态服务** | StatefulSet | 数据库集群部署 | 有序编号 $pod\_name = {sts-name}-{0..N-1}$ | | **配置注入** | ConfigMap/Secret | 环境变量动态配置 | 数据映射 $\forall k \in ConfigMap, v \to Pod$ | | **服务发现** | Service/Ingress | 内外网流量路由 | 负载均衡 $endpoints = \sum_{healthy\;pod} ip:port$ | | **存储管理** | PersistentVolume(PV) | 数据库持久化存储 | 容量规划 $PV_{size} \geq \sum_{pod} request_{storage}$ | | **自动扩缩容** | HPA(HorizontalPodAutoscaler) | 应对流量波动 | 扩缩规则 $desiredReplicas = \lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \rceil$ | --- ### 、常用操作指令 ```bash # 声明式资源管理 $ kubectl apply -f deployment.yaml # 应用YAML配置(幂等操作) # 实时监控与调试 $ kubectl get pods -l app=nginx --watch # 标签筛选+实时状态监控 $ kubectl logs -f pod/nginx-7cdbd8cdc9-zwxrb # 流式日志跟踪 $ kubectl exec -it pod/nginx -- /bin/sh # 进入容器调试 # 集群状态诊断 $ kubectl describe node worker-01 # 节点资源详情分析 $ kubectl top pod --containers # 容器级资源消耗排名 ``` --- ### 三、网络模型实践 1. **Service类型选择矩阵** | 类型 | 流量特征 | 典型场景 | 网络开销 | |--------------|------------------------|---------------------------|----------| | ClusterIP | 集群内部通信 | 微服务间调用 | 低 | | NodePort | 单节点外部暴露 | 开发环境测试 | 中 | | LoadBalancer | 云厂商负载均衡集成 | 生产环境公网访问 | 高 | | Ingress | 七层路由规则管理 | 多域名HTTPS卸载 | 可变 | 2. **网络策略示例** ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy spec: podSelector: matchLabels: app=db ingress: - from: - podSelector: matchLabels: app=api ports: - protocol: TCP port: 5432 # 只允许api服务访问数据库的5432端口 ``` --- ### 四、存储方案选型 1. **存储类(StorageClass)配置维度** - 性能等级:$IOPS \propto \frac{1}{latency}$ - 数据持久性:$RPO \leq 15\text{min}, RTO \leq 5\text{min}$ - 挂载方式:ReadWriteOnce/ReadOnlyMany/ReadWriteMany 2. **典型存储方案对比** | 存储类型 | 适用场景 | 数据一致性 | 扩容复杂度 | |----------------|-------------------|--------------|------------| | 本地SSD | 高性能数据库 | 强一致性 | 可扩容 | | Ceph RBD | 通用块存储 | 最终一致性 | 动态扩容 | | NFS | 文件共享 | 弱一致性 | 手动扩容 | | 云盘(如AWS EBS)| 云环境持久化存储 | 强一致性 | 在线扩容 | --- ### 五、运维监控体系 1. **监控指标采集公式** - 节点健康度:$$ \text{NodeScore} = 0.4 \times \text{CPU\_free} + 0.3 \times \text{Mem\_free} + 0.3 \times \text{Disk\_IOPS} $$ - Pod驱逐预测:$$ \text{EvictRisk} = \begin{cases} 1 &amp; \text{if } \frac{current\_memory}{limit} &gt; 0.9 \\ 0.5 &amp; \text{if } \frac{current\_cpu}{limit} &gt; 0.8 \\ 0 &amp; \text{otherwise} \end{cases} $$ 2. **常用工具链组合** ```mermaid graph LR A(Prometheus) --&gt;|采集| B(Node Exporter) A --&gt;|告警| C(AlertManager) D(Grafana) --&gt;|可视化| A E(Fluentd) --&gt;|日志| F(Elasticsearch) ``` --- ### 六、安全加固措施 1. **RBAC权限矩阵** | 角色 | 权限范围 | API资源限制 | |-------------------|------------------------------|----------------------------| | dev-user | 特定namespace的Pod读写 | verbs: get, list, watch | | cluster-admin | 全集群管理权限 | resources: * | | storage-manager | PersistentVolumeClaims管理 | resourceNames: &quot;ssd-*&quot; | 2. **安全基线配置** ```yaml securityContext: runAsNonRoot: true capabilities: drop: [&quot;NET_RAW&quot;] seccompProfile: type: RuntimeDefault ``` --- ### 七、进阶使用模式 1. **Operator设计范式** ```go func Reconcile() error { current := GetCurrentState() desired := CalculateDesiredState() if !reflect.DeepEqual(current, desired) { return UpdateCluster(desired) # 实现声明式状态收敛 } return nil } ``` 2. **混合云调度策略** ```python def schedule_pod(pod): if pod.requires_gpu: return filter_nodes(has_gpu=True) elif pod.low_latency: return min_distance(user_region) else: return cheapest_zone() ``` --- **总结建议**: 生产环境建议采用$GitOps$模式(如Argo CD),配合$Service\;Mesh$(如Istio)实现细粒度流量治理。对于有状态服务,优先使用Operator模式封装领域知识。监控体系应满足$SLO = \frac{成功请求数}{总请求数} \geq 99.9\%$的服务级别目标。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值