我现在正在学习kubernetes几周了，但是我在努力设计一些概念，并提出了一些基本问题。
我首先尝试使用docker-compose，而不是通过Dockerfiles构建docker镜像，却偶然发现了头盔和kubectl。现在我遇到了构建Pod和构建部署的过程。现在，我知道许多不同的东西，但是可以欣赏现实生活中的例子或一些最佳实践知识。 Google很棒。.但是似乎不止一种方法。
我了解，吊舱应该能够轻松更换/销毁/重建...
具有像这样的POD配置更好吗 -Nginx容器 -PHP容器 -mysql容器 -Redis容器 编辑：正如我刚刚读到的那样，pod共享一个IP地址，因此在此处包含mysql或redis是没有意义的，对吧？
或一个更好的带有 -mysql容器 还有一个装有容器的豆荚 -Nginx -PHP
，另一个带有 -Redis容器
本地Webroot的内容来自git存储库。
我可以创建一个Yaml文件来定义我的pod内部的容器（类型：pod）。但我也可以定义一个deployment.yaml（类型：部署）。
我是否必须在我的deployment.yaml中引用我的pod.yaml，或者该部署是否包含所有pod配置并替换了pod.yaml？
答案 0 :(得分：2)
关于豆荚。 您可以使用所需的所有内容创建一个吊舱。但这将是非常胖的豆荚。请记住，pod仅在一个节点上运行，不可能在一个节点上部分运行，而在另一节点上部分运行一个pod。一个Pod仅在一个节点上运行。这意味着从可伸缩性的角度来看，许多小型Pod优于大型Pod。通常，许多小型Pod还可以在节点之间提供更统一的资源和负载分配。
此外，当您更新Pod中的一个容器时，整个Pod将重新启动。因此，如果您将应用程序和数据库放在同一个Pod中-如果更新应用程序代码-数据库也将重新启动。不酷吧？
但是在某些情况下，在一个吊舱中运行多个容器可能是合理的。记住，pod中的所有容器都共享网络地址和本地主机。因此，pod中的容器具有非常低的网络延迟。
pod中的容器也可以彼此共享卷。在某些情况下，这也很重要。
永久卷 您不能将Git存储库安装到Pod中。好吧，至少那不是您应该做的。您应该将Webroot打包到Docker映像中并在Kubernetes中运行它。詹金斯（Jenkins）应该做到这一点，而詹金斯可以在commit的基础上发展。
或者，如果要在部署副本之间共享文件，则可以将文件放在共享的持久卷上。这也是可能的，您必须找到可以在多个Pod之间共享的所谓的ReadWriteMany卷（例如NFS或GlusterFS）。
答案 1 :(得分：1)
通过配置文件（例如stage.yaml，live.yaml）等进行部署。
我发现Helm为此很好。可以在YAML文件中将Helm“图表”与一组相应的“值”一起部署，并且可以使用这些“值”来配置整个部署的各个部分。
Helm的一个有用部分是a standard library of charts。在需要MySQL的地方，可以helm install stable/mysql进行预打包安装，而不必担心有状态集，持久卷，等
您会将此处建议的所有内容打包到一个图表中，该图表将为Kubernetes的不同部分提供多个（模板化的）YAML文件。
处理类型：广告连播与类型：部署
部署将创建一些（可配置）数量的Pod相同副本。部署规范中的Pod规范包含其所需的所有详细信息。的 部署YAML替换了现有的pod YAML。
您通常不会直接创建广告连播。手动进行升级生命周期可能会有些棘手，部署会为您完成所有艰苦的工作。
具有像...这样的POD配置更好吗？
请记住，事物的一般操作是部署将创建一定数量的Pod副本。当您拥有该软件的更新版本时，可以将其推送到Docker映像存储库，并在部署规范中更改image标签。 Kubernetes将使用新的Pod规范启动Pod的其他副本，然后销毁旧的Pod。
这里的两个基本规则：
如果组件的生命周期不同，则它们需要处于不同的部署中。例如，您不想在更新代码时破坏数据库，因此它们需要在单独的部署中。
如果副本数量不同，则副本副本必须位于不同的部署中。您的主要服务可能需要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用于静态文件托管，如上所述）。