使用Kompose从Docker Compose 迁移到 Kubernetes
使用Kompose从Docker Compose 迁移到 Kubernetes
您的代码库是否在容器化环境中运行呢？
这很好 ！
但是如何使它可用？
您可以使用多种解决方案，例如 Swarm、Kubernetes……从一定数量的应用程序和/或基础设施中，Kubernetes在高可用性和弹性方面往往占主导地位。这就是为什么本文的目的是向您解释如何从使用 Docker Compose 的环境迁移到 Kubernetes。
Docker-compose
“Compose 是一种用于定义和运行多容器 Docker 应用程序的工具。使用 Compose，您可以使用 YAML 文件来配置应用程序的服务。然后，使用单个命令，您可以从配置中创建并启动所有服务。”
Compose是Docker提供的解决方案，用于轻松快速地构建完整的应用程序堆栈。 这在本地环境中非常有趣：一旦开发人员编写了代码，他就可以重新编译镜像，并在任何地方运行他的整个应用程序（包括数据库、后端、前端、worker 等）。
image.png
Kubernetes
Kubernetes引擎使用通过配置文件描述的资源声明系统。它允许您创建、配置和链接资源。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
所以问题是：我们如何使用当前的Docker Compose堆栈为 Kubernetes 生成配置文件？
Kompose
“Kompose 是一个帮助熟悉 docker-compose 的用户迁移到 Kubernetes 的工具。”
我们知道这是一个将 Docker Compose 配置迁移到Kubernetes清单的工具。 Kompose 工具是一个开源项目，5 年来一直得到社区的一致支持。几个月来，一些拉取请求也得到了验证。这些都是项目稳定性和一定成熟度的良好指标，即使这些值通常仍然很低。 在此，部署了一个 Odoo 堆栈，这里是 docker-compose.yaml 文件...
version: "3.3"
services:
# Traefik
traefik:
image: "traefik:v2.4"
container_name: "traefik"
command:
- "--providers.docker=true"
- "--providers.docker.exposedbydefault=false"
- "--entrypoints.websecure.address=:443"
- "--certificatesresolvers.myresolver.acme.tlschallenge=true"
- "--certificatesresolvers.myresolver.acme.email=$ACME_EMAIL"
- "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
ports:
- "443:443"
volumes:
- "./traefik:/letsencrypt"
- "/var/run/docker.sock:/var/run/docker.sock:ro"
# Database
db:
image: postgres:9.4
container_name: "odoo-database"
environment:
- POSTGRES_PASSWORD=$POSTGRES_PASSWORD
- POSTGRES_USER=$POSTGRES_USER
volumes:
- ./postgresql:/var/lib/postgresql/data
restart: always
# Odoo
odoo10:
image: odoo:10.0
container_name: "odoo-10"
depends_on:
- db
volumes:
- ./odoo-10/addons:/mnt/extra-addons
- ./odoo-10/etc:/etc/odoo
restart: always
labels:
- "traefik.enable=true"
- "traefik.http.routers.odoo.rule=Host(`$ODOO_URL`)"
- "traefik.http.routers.odoo.entrypoints=websecure"
- "traefik.http.routers.odoo.tls.certresolver=myresolver"
# PGAdmin
pgadmin:
image: dpage/pgadmin4:4.25
container_name: pgadmin4
environment:
- PGADMIN_DEFAULT_EMAIL=me@example.org
- PGADMIN_DEFAULT_PASSWORD=odoo
- PGADMIN_LISTEN_PORT=80
volumes:
- ./pgadmin:/var/lib/pgadmin
restart: always
labels:
- "traefik.enable=true"
- "traefik.http.routers.pgadmin.rule=Host(`$PGA_URL`)"
- "traefik.http.routers.pgadmin.entrypoints=websecure"
- "traefik.http.routers.pgadmin.tls.certresolver=myresolver"
通过kompose迁移后, kompose convert成为一个易于部署的 Kubernetes 清单列表。
但是，按原样部署项目将不起作用。生成的未填写的字段必须填写。例如，在我们的示例中，Odoo CRM 需要其 URL，以便 Traefik 重定向到它。 模板：
metadata:
annotations:
kompose.cmd: kompose convert
kompose.version: 1.26.1 (HEAD)
traefik.enable: "true"
traefik.http.routers.odoo.entrypoints: websecure
traefik.http.routers.odoo.rule: Host(``) # <-- ici
traefik.http.routers.odoo.tls.certresolver: myresolver
使用 Kompose 之类的工具可以让Kubernetes 管理员的生活更轻松。但是仅仅依靠这个工具在集群上部署应用程序是一个很大的错误。事实上，Kompose 有一些超出 Kubernetes 使用标准的偏见。
Volume
非常重要的第一件事：Kompose 不会生成文件来声明持久卷(PV)。因此，这些必须单独声明，因为它们与应用程序部分分离。 应用上面示例中给出的配置不允许直接启动应用程序。这些卷已迁移到 Persistent Volume Claims (PVC)，但是如果没有任何关联的 PV 配置，它们将无法正确部署：
pod has unbound immediate PersistentVolumeClaims
这会导致Pod无法部署，因此会导致部署失败。原因很容易猜到：由于数据存储是特定于每个基础架构的，并且每个公司在可用性和归档方面都有特定的需求，因此很容易理解，Kompose 不希望就此主题给出任何特别的建议。。
IngressController
Kubernetes的标准是使用Ingress Controller。提醒一下，这充当了外部世界和集群内应用程序之间的代理。因此，在单个 Ingress Controller 上，可以重新路由路由。这些，使用 Ingress 声明，将重定向到与应用程序部署相关的服务，这最终将允许访问 Pod。 但是，Kompose 无法识别这种类型的资源。此外，将模拟容器配置traefik ，以便在功能上对应于所请求的内容：在特定端口上打开的服务，并允许在容器中的给定端口上接收请求。 在Kubernetes 世界，这相当于在NodePort模式下创建一个服务，它将收集所有传入的流量。它最终的行为与真正的 Ingress Controller 工作的行为非常相似，但它会在您的集群中引起特殊性。使用您自己的流重定向系统需要您确定自己在做什么，因为您最终将不得不处理特定于该网络层实现的问题。帮助调试的资源将更难找到。 另一个副作用：在部署. 但是，在 Kubernetes 集群上部署第二个相同类型的堆栈，使用另一个 Traefik 实例，会报错：此处使用的端口 443已被部署的第一个堆栈占用。
最后
Kompose 解决了从Docker Compose文件轻松生成即用型 Kubernetes 清单的问题。但是，与任何代码生成器工具一样，并非一切都好。然后，有些人必须在将配置部署到生产环境之前对配置进行批判性和知情的观察。 在 PoC 过程中使用 Kompose 很有趣，因为它可以节省大量时间。但是为了自动部署配置而将其直接集成到自动化 CI/CD 流程中并不是一个很好的用途。 Kubernetes集群管理是一项全职工作，需要对工具有很好的了解才能尽可能多地避免出现问题。