匹兹堡和克利夫兰的 Kubernetes 咨询
KawaConnect 为匹兹堡、宾夕法尼亚州西部以及俄亥俄州东北部克利夫兰地区的企业设计、运行并支持生产环境的 Kubernetes。我们基于 Talos Linux 和 Cilium 构建，如果您其实不需要集群，我们也会如实告诉您。
聊聊您的集群 Linux 服务器支持
本服务涉及的平台
我们的服务内容
Kubernetes 把容器调度到多台机器上，并在出现故障时重新启动它们。我们设计集群，把您的应用程序部署上去，并持续保持升级。
Talos Linux 集群
一种不可变、通过 API 管理的 Kubernetes 节点操作系统，使节点不会因手动变更而逐渐出现差异。
Cilium 网络
Pod 网络和网络策略，用于控制哪些服务可以相互通信。
Helm 与 GitOps
应用程序在 Git 仓库中描述并自动应用，使每次变更都经过审查并且可以回退。
GitLab CI/CD
在每次变更时构建容器镜像、运行测试并发布到镜像仓库的流水线。
监控与备份
用于展示集群健康状况的 Grafana 仪表板，以及集群状态和持久化数据的备份，并经过测试恢复。
升级
有计划的 Kubernetes 和节点升级，一次升级一个节点，同时应用程序保持运行。
在物理服务器或 Proxmox 上设计集群
集群可以直接运行在物理服务器上，也可以运行在 Proxmox 下的虚拟机上。裸机让节点可以直接访问硬件。Proxmox 虚拟机则便于快照、重建和测试集群。我们会根据您的硬件、应用程序以及由谁来运维，与您一起选择。
- 控制平面：配置足够数量的节点，使其中一个出现故障时集群仍能继续运行。
- 存储：持久卷由本地磁盘或 Ceph 存储提供，视您的数据需求而定。
- 访问：入口、TLS 证书，以及谁可以访问集群 API。
交付与运维
我们把集群和应用程序的配置放在版本控制中。一次变更就是一个 GitLab 合并请求，集群随代码仓库同步。
运维包括升级、监控、告警、备份和容量管理。我们把每个部分的工作方式写下来，让您的团队或我们的团队都能运行它。如需深入了解，请阅读我们知识库中的 Kubernetes 指南和 Talos Linux 指南。
什么时候 Kubernetes 不是答案
运行集群比运行单台服务器需要更多工作。只有一个应用程序和一个数据库的情况，通常更适合运行在带有完善备份的 Linux 虚拟机上，这属于我们的 Linux 服务器支持范围。在单台主机上运行少量容器，则适合使用 Docker 和 Docker Compose。
当您需要跨机器的故障切换、滚动更新，或者有许多必须一起调度的服务时，我们会建议使用集群。如果您拿不准，请查看我们的 Linux 与 Kubernetes 概览，了解各种方案的对比。
合作流程
- 沟通了解。我们了解您运行什么、哪些必须保持在线，以及由谁来运维。
- 书面方案。一份设计或审查报告，包含工作顺序以及备份和回退计划。
- 搭建与交付。我们负责部署，测试故障与恢复，并记录运维方法。
- 长期运维。可选，由指定工程师负责，不设绑定。
我们的办公室位于宾夕法尼亚州的 Coraopolis 和 Beaver Falls。克利夫兰地区的现场工作根据项目安排，远程支持覆盖全美国。我们会在一个工作日内回复。
关于 Kubernetes 咨询的常见问题
你们能接手别人搭建的集群吗？
可以。我们先检查节点、访问权限、备份和部署方式，然后修复具体问题或接手运维。
为什么选择 Talos Linux？
Talos 没有 shell，也没有包管理器。节点通过 API 配置，这使它们保持一致，并减少了可能被错误配置或遭到攻击的部分。
我们的应用程序需要 Kubernetes 吗？
通常不需要。我们会在第一次通话中如实说明，如果 Linux 虚拟机或 Docker 更合适，我们会推荐它们。
你们能把我们的 Docker 工作负载迁移到 Kubernetes 吗？
可以。我们把 Compose 服务转换为 Helm chart，迁移数据，进行测试，并在您批准的时间切换。
适合哪些客户
- Docker 主机已成为单点故障的公司
- 需要镜像构建、流水线和可重复部署的开发团队
- 运行着集群、却没有时间做升级和备份测试的组织
- 需要有文档记录、可审计的基础设施的受监管企业
相关指南
来自我们知识库的通俗讲解。
