容器
Kubernetes：诚实地争论的编排器
Kubernetes 是容器编排器，它成为基础设施的默认大系统底层：部署、服务、入口、持久卷和描述所需状态的 API。它也是巨大的。关于 Kubernetes 的诚实文章从何时不使用它开始，然后介绍了真正的架构、托管选项（托管与 k3s）以及它所需的操作规则。
要点
- 核心对象模型确实很好：部署描述了所需的副本状态，服务提供稳定的网络，ConfigMaps/Secrets 单独的配置，入口到达外部；声明性协调（控制器修复偏差）是其他所有内容所构建的架构。
- 操作权重是真实的：控制平面组件（API 服务器、etcd、调度程序、控制器管理器）每个都需要 HA 和监控； etcd 备份是决定集群是否可恢复的一项单调乏味的任务；升级规则（每个步骤一个次要版本，首先是金丝雀节点）是一项长期义务。
- 托管与自我管理分叉：GKE/EKS/AKS 贸易控制可减少操作，k3s/microk8s 是小型机群的合法迷你发行版，而自我管理 HA master 仍然是一个大型团队项目；对于托管业务来说，少数节点上的 k3 通常是正确的上限。
- 存储是大多数第一个集群受到伤害的地方：不同云上存储类的 PV/PVC 不同，hostPath 是一把枪，块存储支持的类具有真正的 IOPS/速率语义；在第一个有状态工作负载之前规划存储类和备份策略（velero 类）。
- 网络是它自己的学科：CNI 选择（flannel、calico、cilium）控制覆盖与本机路由和出口策略； Ingress (nginx/traefik) 加上 cert-manager 处理 TLS；市场工具在网关 API 成熟度方面存在差异；选择前先衡量一下。
- 我们容器类别中的诚实结论：当多节点调度、自动扩展和 API 驱动的部署自动化承担工作负载时，采用 Kubernetes；不要使用 k8s 单个 WordPress 服务器； k3s 级发行版扩展了实用区域，但最小的诚实集群仍然比 compose 花费更多的操作。
一线手记
“需要 Kubernetes”的客户实际上需要两台主机上的四个服务，k3s 为他们提供了一个控制平面来照顾这一特权。我们将它们迁移到普通的撰写堆栈，并且它们的待命寻呼机变得安静。最好的 Kubernetes 决策通常不是您做出的。
常见问题
我们的小型托管堆栈是否应该迁移到 Kubernetes？
可能不是：如果您的工作负载是跨少量主机的少量服务，则 compose 或 Podman 管理的堆栈更容易保护和监控； k8s 的回报始于真正的动态调度需求或 API 驱动的大规模自动化。
GKE、EKS、AKS 还是自我管理的 k3？
托管控制平面对卸载升级进行贸易控制；适用于本地部署和成本上限的 k3s 级；自我管理的完整 Kubernetes 是一个专业项目，很少是托管业务配置文件的正确答案。
最常见的操作故障是什么？
etcd 未备份：接下来显示控制平面中的证书到期；将集群备份（etcd 快照或 velero）视为集群本身之后部署的第一件事。
我们如何合理地保护集群？
RBAC 最小权限，每个团队具有实际角色，实际分段命名空间流量的网络策略，准入时的图像扫描（三级策略挂钩），以及通过外部秘密管理器而不是原始 YAML 处理的集群内秘密。
Kinetikatech 如何在容器方面为您提供帮助
这是我们的日常工作：生产环境中容器的管理、编排与安全。我们的服务器管理和Linux 服务器安全服务提供端到端覆盖：评估、实施、24/7 监控，以及 30 分钟内的应急响应。