kubernetes生产注意事项

Kubernetes是一种流行的容器编排工具，但在生产环境中部署和管理Kubernetes可能会面临一些挑战。为了确保生产环境的高可用性、可伸缩性和安全性，需要遵循一些最佳实践。这些实践包括使用合适的硬件和网络基础设施、使用可靠的存储和备份策略、进行监控和日志记录、使用适当的安全措施以及实施自动化和持续集成/持续交付流程。遵循这些最佳实践将有助于确保Kubernetes在生产环境中的稳定性和可靠性。

1）性能调优优先级网络优化 > 存储IO优化 > 资源利用率提升 > 成本优化2）必装工具清单监控：Prometheus + Grafana日志：Loki + Grafana安全：Falco + Trivy成本：kube-cost + Kubecost3）优化迭代流程通过系统化的优化策略，结合持续监控和迭代改进，可使Kubernetes集群在生产环境中实现最佳的性能、安全性和成本效益平衡。

就绪探针 /health/readiness 检查业务就绪状态（如数据库连接、线程池状态、缓存预热）版本兼容：Spring Boot Actuator 等框架需启用 /shutdown 端点（默认关闭）启动探针 /health/startup 检测应用初始化完成（如 JVM 启动、配置文件加载）存活探针 /health/liveness 仅检查进程存活状态（避免依赖外部服务）日志追踪：记录健康检查失败详情（如 kubectl logs --previous）

如果没有，则可以使用用户管理的负载平衡，在这种情况下，启动集群之前需要做一些准备。在某些环境中，如在具有专用负载均衡器组件（如某些云供应商提供的）的数据中心中。以便始终使用当前持有 vIP 的主机上的负载均衡器，而其它主机处于待机状态。为此，设置了管理虚拟 IP 的主机集群，每个主机运行一个负载均衡器的实例。下边的内容给出了一些有用的例子，当然还有许多其它配置负载均衡器的方法。负载均衡器自己也应该是高可用的，通常通过添加冗余的负载均衡器来实现。对于工作节点，假设有足够多的节点，这是集群功能的一部分。

建议每季度进行一次日志系统健康检查，重点验证备份完整性、安全策略有效性、存储容量规划三个核心项。当遇到日志堆积时，优先检查输出插件状态、网络带宽、存储IOPS三个关键瓶颈点。

Headless Service在Kubernetes网络拓扑中扮演着不可替代的角色，特别是在需要精确控制网络流量的场景下。通过合理运用本文介绍的技巧，开发者可以构建出既符合云原生标准，又能满足复杂业务需求的分布式系统架构。

不过，如果你预期服务请求会随着时间增长，或者因为类似季节或者特殊事件的原因而发生剧烈变化， 你就需要规划如何处理请求上升时对控制面和工作节点的压力，或者如何缩减集群规模以减少未使用资源的消耗。无论你是自行构造一个生产用 Kubernetes 集群还是与合作伙伴一起协作， 请审阅下面章节以评估你的需求，因为这关系到你的集群的控制面、工作节点、用户访问以及负载资源。添加节点到集群中：如果你自行管理你的集群，你可以通过安装配置你的机器， 之后或者手动加入集群，或者让它们自动注册到集群的 API 服务器。

官方链接 配置注意事项 当定义一个配置时，指定最新稳定版本的API 在推送到集群之前，配置文件必须使用版本控制的方式进行管理，这样可以在需要的时候快速回滚配置，也有助于集群的重新创建和恢复。 使用YAML而不是JSON编写配置文件。 虽然这些格式几乎可以在所有场景中互换使用，但YAML往往更加用户友好。 只要有意义，就将相关对象分组到一个文件中。 一个文件通常比几个文件更容易管理。 请参阅gue...

本章节主要介绍应用程序在服务器上部署方式演变以及kubernetes的概念、组件和工作原理。

哈喽，大家好，我是廖志伟，一个专注高并发、高可用、高可靠、微服务、分布式、海量数据、性能调优、项目管理的开发者，希望本篇文章能给你带来收获，喜欢的可以关注我哟。

在同一个k8s pod当中，有pause进程还有一个或多个容器共享一个网络命名空间，pause之间进行通信主要依赖2个设备，一个是虚拟网络设备，它的一端接在pod网络命名空间里面，另外一端接在宿主机的网络命名空间里面，这是一个全局的网络命名空间，然后在宿主机的这一端又接在了网桥设备，这个网桥设备又会把报文发送到相连的另外一个pod上的虚拟网络设备，从而通过虚拟网络设备发送到另外的一个pod当中，也就是说这个虚拟网络设备就是虚线的圈，类似于一个网线的2端。

在 Dockerfile 中，设置了 echo “source activate mytest” > ~/.bashrc 配置了自动激活，只在docker 创建的容器中生效，容器启动时会默认进入conda的mytest虚拟环境中。args: [“source /opt/conda/bin/activate mytest && 执行xxx程序”]但 Kubernetes 启动容器时使用的是非交互式 shell，默认不会加载 .bashrc，因此环境没有被激活。command 或者args中设置。

记录一下在k8s1.28.2集群部署istioctl的1.20.0版本的过程（X86架构）

特性数据来源Pod的YAML资源配置声明实时Metrics Server监控数据指标类型静态配置（Requests/Limits）动态消耗（CPU/内存实际用量）内存指标意义申请的内存配额上限工作集（含缓存，用于OOM判断）核心用途检查资源分配、调度瓶颈监控运行时负载、性能调优操作建议：日常监控应结合两者。通过top pod观察实时负载波动，通过验证资源分配是否符合预期，避免节点资源过载。若内存消耗接近Limit且工作集持续增长，需警惕OOM风险。

改为与“kubeadm init”命令中指定的 Pod 网络CIDR 地址范围保持一致。#清除nat表中所有网络地址转换规则。#清除filter表中的数据包过滤规则。#注释所有交换空间挂载配置。#关闭防火墙并开机不自启。###拷贝到node节点。修改cidr “ip”

k8s-(六）在kubernertes上部署运行项目： https://blog.csdn.net/qq_21187515/article/details/112320972。K8S二进制安装与部署 ：https://blog.csdn.net/fantuan_sss/article/details/139073366。二进制安装k8s： https://blog.csdn.net/qq_73990369/article/details/143217084。kubeadm：用来初始化集群的指令。