关于 Kubernetes 部署的问题

Question

我们要归档以下内容：

• 在 Google Kubernetes 上运行的 Magento 商店
• 通过配置文件（例如stage.yaml、live.yaml）等进行部署
• PHP 7.2
• MySQL 5.6 / MariaDB
• Redis
• nginx:高山
• https
• Magento 和 MySQL 的持久卷声明

我现在正在学习 Kubernetes 几个星期，但我在一些设计概念上苦苦挣扎，并且出现了一些基本问题。

我第一次尝试 docker-compose，而不是通过 Dockerfiles 构建 docker 镜像，偶然发现了 helm 和 kubectl。现在我遇到了构建 pod 和构建部署。现在我知道很多不同的事情，但一个现实生活中的例子或一些最佳实践知识将不胜感激。谷歌很棒..但似乎不止一种方法。

1。关于 Pods

我明白，豆荚应该可以很容易地更换/销毁/重新创建...

有一个像这样的 POD 配置会更好吗 - nginx容器 - php容器 - mysql容器 - redis 容器 编辑：正如我刚刚读到的，pod 共享一个 IP 地址，所以在这里包含 mysql 或 redis 是没有意义的，对吧？

或者更好的是一个带有 - mysql容器 和一个带有容器的吊舱 - nginx - php

还有一个 - redis 容器

2。在本地挂载持久卷声明或远程 webroot（如 /var/www/html）以进行处理。

本地 webroot 的内容来自 git repo。

3。处理类型：pod vs. type:deployment

我可以创建一个 yaml 文件来定义我的 pod (type:pod) 中的容器。但我也可以定义一个 deployment.yaml (type:deployment)。

我是否必须在 deployment.yaml 中引用我的 pod.yaml，或者部署是否包含所有 pod 配置并替换 pod.yaml？

Answer 1

关于 Pod。 您可以使用所需的一切创建一个 pod。但这将是非常胖的豆荚。请记住，pod 仅在一个节点上运行，不可能在一个节点上部分运行一个 pod，而在另一个节点上部分运行一个 pod。一个 pod 只在一个节点上运行。这意味着从可扩展性的角度来看，许多小 pod 都比一个大 pod 好。许多小型 pod 通常还可以在节点之间提供更均匀的资源和负载分布。

此外，当您更新 pod 中的一个容器时 - 整个 pod 都会重新启动。因此，如果您在同一个 pod 中有应用程序和数据库 - 如果您更新应用程序代码 - 数据库也将重新启动。不酷，嗯？

但在某些情况下，在一个 pod 中运行多个容器可能是合理的。请记住，pod 中的所有容器共享网络地址和 localhost。因此 pod 中的容器具有非常低的网络延迟。

Pod 中的容器也可以在彼此之间共享卷。这在某些情况下也很重要。

持久卷 您不能将 Git 存储库挂载到 pod 中。好吧，至少那不是你应该做的。您应该将您的 webroot 打包到 Docker 映像中并在 Kubernetes 中运行。这应该由 Jenkins 来完成，它可以建立在提交之上。

如果您想在部署副本之间共享文件，您也可以将文件放在共享持久卷上。这也是可能的，您必须找到可以在多个 pod 之间共享的所谓的 ReadWriteMany 卷，例如 NFS 或 GlusterFS。

Answer 2

通过配置文件（例如stage.yaml、live.yaml）等进行部署

我发现 Helm 可以很好地解决这个问题。可以使用 YAML 文件中的一组相应“值”部署 Helm“图表”，这些值可用于配置整个部署的各个部分。

Helm 的一个有用部分是a standard library of charts。如果您说需要 MySQL，您可以helm install stable/mysql 并获得预打包的安装，而无需担心有状态集、持久卷等的具体细节。

您可以将此处建议的所有内容打包到一个图表中，该图表将为不同的 Kubernetes 部分提供多个（模板化的）YAML 文件。

处理类型：pod vs. type:deployment

部署将创建一些（可配置的）数量相同的 Pod 副本。部署规范中的 pod 规范包含它需要的所有详细信息。这 部署 YAML 替换现有的 pod YAML。

您通常不会直接创建 pod。尤其是手动升级生命周期可能有点棘手，而部署会为您完成所有艰苦的工作。

拥有像...这样的 POD 配置会更好吗？

请记住，事物的一般操作是部署会创建一定数量的 pod 副本。当您拥有软件的更新版本时，您会将其推送到 Docker 映像存储库并更改部署规范中的映像标记。 Kubernetes 将使用新的 pod 规范启动额外的 pod 副本，然后销毁旧的。

这里有两个基本规则：

1. 如果组件的生命周期不同，则它们需要位于不同的部署中。例如，您不想在更新代码时破坏数据库，因此这些需要在单独的部署中。

2. 如果副本数量不同，则需要在不同的部署中。您的主要服务可能需要 3 或 5 个副本，具体取决于负载； nginx 只是路由 HTTP 消息，可能只需要 1 或 3 个；数据库无法复制，只能使用1个。

在您展示的设置中，我有四个单独的部署，每个部署一个用于 MySQL、Redis、nginx 代理和主应用程序。

webroot 的内容来自一个 git repo。

最简单的方法是把它构建成一个镜像，可能是 nginx 镜像。

如果它“大”（千兆字节），您可能会发现完全在 Kubernetes 之外的某个地方托管此静态内容更有用。任何具有静态文件托管的东西都可以正常工作。

据我所知，没有一种直接的方法可以在不编写容器的情况下将任意内容复制到持久卷中。

---

您的问题根本没有提到 Kubernetes 服务。这些是核心，您应该阅读它们。特别是当您的应用程序与两个数据存储进行通信时，它会直接引用服务而不是 MySQL pod。

根据您的环境，还可以考虑在 Kubernetes 之外托管数据库的可能性。它们的生命周期非常与您的应用程序容器不同：您永远不想停止数据库，并且您真的不希望数据库的托管存储被意外删除。您可能会发现使用裸机数据库设置或使用托管数据库设置更容易、更安全。 （我的个人经验主要是使用 AWS，您可以将 RDS 用于 MySQL 实例，将 Elasticache 用于 Redis，将 S3 用于上面讨论的静态文件托管。）