Kubernetes AntipatternsKubernetes 反模式

In Kubernetes, identifying and avoiding anti-patterns is crucial for maintaining a robust container orchestration environment. These misleading practices may initially appear effective but can lead to complications. This reading explores ten prevalent Kubernetes anti-patterns and recommends alternative practices for a smoother and more sustainable deployment.
在 Kubernetes 中，识别和避免反模式对于维护一个稳健的容器编排环境至关重要。这些具有误导性的做法最初可能看似有效，但会导致复杂问题。本阅读探讨了十个常见的 Kubernetes 反模式，并推荐替代做法以实现更顺畅和可持续的部署。

1. Avoid baking configuration in container images 1. 避免在容器镜像中嵌入配置

Containers offer the advantage of using a consistent image throughout the production process. To achieve adaptability across different environments, building images without embedding configuration directly into containers is essential.
容器提供了在整个生产过程中使用一致镜像的优势。为了实现跨不同环境的适应性，构建不直接将配置嵌入容器的镜像至关重要。

Issue: Problems arise when images contain environment-specific artifacts that deviate from the tested version, necessitating image rebuilds and risking inadequately tested versions in production. Identification of environment-dependent container images involves spotting features like hardcoded IP addresses, passwords, and environment-specific prefixes.
问题：当镜像包含与测试版本不符的环境特定工件时，会出现问题，导致需要重建镜像，并可能将未经充分测试的版本投入生产。识别依赖环境的容器镜像涉及识别诸如硬编码的 IP 地址、密码和环境特定前缀等特征。

Best practice: Create generic images independent of specific runtime settings. Containers enable the consistent use of a single image throughout the software lifecycle, promoting simplicity and efficiency.
最佳实践：创建独立于特定运行时设置的通用图像。容器能够在整个软件生命周期中始终如一地使用单个图像，促进简化和效率。

2. Separate application and infrastructure deployment 2. 分离应用程序和基础设施部署

Infrastructure as Code (IaC) allows defining and deploying infrastructure like writing code. While deploying infrastructure through a pipeline is advantageous, separating infrastructure and application deployment is crucial.
基础设施即代码（IaC）允许像编写代码一样定义和部署基础设施。虽然通过管道部署基础设施具有优势，但分离基础设施和应用程序部署至关重要。

Issue: Using a single pipeline for both infrastructure and application deployment leads to resource and time wastage, especially when changes in application code outpace infrastructure changes.
问题：使用单个管道进行基础设施和应用程序部署会导致资源和时间的浪费，尤其是在应用程序代码变更快于基础设施变更时。

Best practice: Split infrastructure and application deployment into separate pipelines to optimize efficiency and resource utilization.
最佳实践：将基础设施和应用部署拆分为独立的管道，以优化效率和资源利用率。

3. Eliminate specific order in deployment 3. 消除部署中的特定顺序

Maintaining application stability despite delays in dependencies is crucial in container orchestration. Unlike traditional fixed startup orders, Kubernetes and containers initiate components simultaneously.
在容器编排中，尽管依赖项延迟，保持应用稳定性至关重要。与传统固定的启动顺序不同，Kubernetes 和容器同时启动组件。

Issue: Challenges arise when poor network latency disrupts communication, potentially causing pod crashes or temporary service unavailability.
问题：当网络延迟差时，通信受阻会导致问题，可能引发 Pod 崩溃或临时服务不可用。

Best practice: Proactively anticipate failures, establish frameworks to minimize downtime, and adopt strategies for simultaneous component initiation to enhance application resilience.
最佳实践：主动预见故障，建立框架以最小化停机时间，并采用同时启动组件的策略以增强应用程序的弹性。

4. Set memory and CPU limits for pods problem 4. 为 Pod 设置内存和 CPU 限制问题

The default Kubernetes setting without specified resource limits allows an application to potentially monopolize the entire cluster, causing disruptions.
默认情况下，如果没有指定资源限制，Kubernetes 允许应用程序可能垄断整个集群，从而造成中断。

Best practice: Establish resource limits for all applications, conduct a thorough examination of each application's behavior under various conditions, and strike the right balance to optimize cluster performance.
最佳实践：为所有应用程序建立资源限制，全面检查每个应用程序在不同条件下的行为，并找到最佳平衡点以优化集群性能。

5. Avoid pulling the latest tag in production problem 5. 避免在生产环境中拉取最新标签

The utilization of the "latest" tag in production settings often results in unforeseen pod crashes, triggered by sporadic image pulls lacking specificity. This absence of clear versioning makes troubleshooting challenging, particularly during downtime resolution where swift identification of issues is paramount.
在生产环境中使用"最新"标签往往会导致不可预见的 Pod 崩溃，这是由缺乏明确性的随机镜像拉取触发的。版本控制的缺失使得故障排除变得困难，尤其是在解决停机问题时，快速识别问题至关重要。

Best practice: Use specific and meaningful image tags, incorporating possibly the date and time of the build. Furthermore, it is crucial to uphold the immutability of container images and store data externally in persistent storage. Avoiding post-deployment modifications to containers ensures safer and more repeatable deployment processes.
最佳实践：使用具体且具有意义的镜像标签，可能包含构建的日期和时间。此外，必须坚持容器镜像的不可变性，并将数据存储在外部的持久存储中。避免部署后的容器修改，可以确保更安全、更可重复的部署流程。

6. Segregate production and non-production workloads problem 6. 生产与非生产工作负载隔离问题

Relying on a single cluster for all operational needs poses challenges. Security concerns arise from default permissions and complications with non-namespaced Kubernetes resources.
将所有操作需求依赖于单个集群会带来挑战。默认权限引发安全问题，非命名空间 Kubernetes 资源也存在复杂性问题。

Best practice: Establish a second cluster exclusively for production purposes, avoiding complexities associated with multi-tenancy. Maintain at least two clusters—one for production and one for non-production.
最佳实践：为生产目的专门建立第二个集群，避免与多租户相关的复杂性。至少维护两个集群——一个用于生产，一个用于非生产。

7. Refrain from ad-hoc deployments with kubectl edit/patch problem 7. 避免使用 kubectl edit/patch 进行临时部署问题

Configuration drift occurs when multiple environments deviate due to unplanned deployments or changes, leading to failed deployments.
当多个环境因非计划部署或变更而出现偏差时，会发生配置漂移，导致部署失败。

Best practice: Conduct all deployments through Git commits for comprehensive history, precise knowledge of cluster contents, and easy recreation or rollback of environments.
最佳实践：通过 Git 提交进行所有部署，以实现全面的版本历史记录、精确了解集群内容，并轻松地重建或回滚环境。

8. Implement health checks with liveness and readiness probes problem 8. 实施健康检查，使用存活和就绪探针问题

Neglecting health checks can lead to various issues. Overly complex health checks with unpredictable timings can cause internal denial-of-service attacks within the cluster.
忽视健康检查可能导致各种问题。过于复杂的健康检查以及不可预测的时间安排可能导致集群内部拒绝服务攻击。

Best practice: Configure health probes for each container, use liveness and readiness probes, and prioritize robust health checks for reliable application responsiveness.
最佳实践：为每个容器配置健康探针，使用存活和就绪探针，并优先考虑健壮的健康检查，以确保可靠的应用程序响应性。

9. Prioritize secret handling and use vault problem 9. 优先处理密钥管理并使用 Vault 问题

Embedding secrets directly into containers is poor practice. Using multiple secret handling methods or complex injection mechanisms can complicate local development and testing.
将密钥直接嵌入容器中是不良实践。使用多种密钥处理方法或复杂的注入机制可能会使本地开发和测试变得复杂。

Best practice: Use a consistent secret handling strategy, consider HashiCorp Vault, handle secrets uniformly across environments, and pass them to containers during runtime for enhanced resilience and security.
最佳实践：使用一致的密钥处理策略，考虑使用 HashiCorp Vault，在环境中统一处理密钥，并在运行时将它们传递给容器，以增强弹性和安全性。

10. Use controllers and avoid running multiple processes per container problem 10. 使用控制器并避免每个容器运行多个进程问题

Directly using pods in production poses limitations. Pods lack durability, automatic rescheduling, and data retention guarantees. Running multiple processes in a single container without controllers can lead to issues.
直接在生产环境中使用 Pod 会带来限制。Pod 缺乏耐用性、自动重新调度和数据持久性保证。在没有控制器的情况下，在单个容器中运行多个进程可能会导致问题。

Best practice: Utilize Deployment with a replication factor, define one process per container, use multiple containers per pod if necessary, and leverage workload resources like Deployment, Job, or StatefulSet for reliability and scalability.
最佳实践：使用具有副本数的 Deployment，每个容器定义一个进程，如有必要，每个 Pod 使用多个容器，并利用工作负载资源（如 Deployment、Job 或 StatefulSet）以提高可靠性和可扩展性。

Conclusion 结论

Understanding and avoiding these Kubernetes anti-patterns contribute to a more resilient and efficient container orchestration environment. Embracing best practices ensures smoother deployments, reduces technical debt, and enhances the overall stability of Kubernetes-based applications.
理解和避免这些 Kubernetes 反模式有助于构建更具弹性和效率的容器编排环境。采用最佳实践可以确保更顺畅的部署，减少技术债务，并提高基于 Kubernetes 的应用程序的整体稳定性。