Kompose工具:转换Compose项目为K8S项目

Docker与Kubernetes系列 转换Compose项目为K8S项目



【介绍】:本文介绍用于转换Compose项目为K8S项目的Kompose工具。


上一节:《暂无| 下一节:《 暂无


目 录


  • [1. 概述](#1. 概述)
    • [1.1 Kompose简介](#1.1 Kompose简介)
    • [1.2 Kompose的主要功能](#1.2 Kompose的主要功能)
  • [2. 安装Kompose](#2. 安装Kompose)
    • [2.1 二进制安装](#2.1 二进制安装)
    • [2.2 包管理器安装](#2.2 包管理器安装)
    • [2.3 源码安装](#2.3 源码安装)
  • [3. 基本用法](#3. 基本用法)
    • [3.1 转换Docker Compose文件](#3.1 转换Docker Compose文件)
    • [3.2 部署到Kubernetes集群](#3.2 部署到Kubernetes集群)
    • [3.3 访问部署的服务](#3.3 访问部署的服务)
  • [4. 高级功能](#4. 高级功能)
    • [4.1 支持的Docker Compose版本](#4.1 支持的Docker Compose版本)
    • [4.2 转换为不同的Kubernetes对象](#4.2 转换为不同的Kubernetes对象)
      • [4.2.1 Deployment](#4.2.1 Deployment)
      • [4.2.2 DaemonSet](#4.2.2 DaemonSet)
      • [4.2.3 ReplicationController](#4.2.3 ReplicationController)
    • [4.3 生成Helm Chart](#4.3 生成Helm Chart)
  • [5. 自定义转换](#5. 自定义转换)
    • [5.1 使用标签控制转换](#5.1 使用标签控制转换)
    • [5.2 重启策略](#5.2 重启策略)
    • [5.3 健康检查配置](#5.3 健康检查配置)
  • [6. 构建和推送镜像](#6. 构建和推送镜像)
    • [6.1 构建镜像](#6.1 构建镜像)
    • [6.2 推送镜像到仓库](#6.2 推送镜像到仓库)
    • [6.3 自定义构建和推送命令](#6.3 自定义构建和推送命令)
  • [7. 结论与回顾](#7. 结论与回顾)

[1. 概述](#1. 概述)

[1.1 Kompose简介](#1.1 Kompose简介)

Kompose 旨在帮助开发者和运维人员将Docker Compose 项目无缝迁移到Kubernetes 环境中。它的名称源自"Kubernetes "和"Compose"的组合。

虽然Docker Compose 项目并不一定要迁移到Kubernetes ,是事实上往往对于中小型企业的项目使用Docker Compose 不论从开发和维护都更加方便。不过,Kompose 的出现解终究是决了从容器化应用到Kubernetes 编排的过渡难题,使得已经熟悉Docker Compose 的团队能够更轻松地采用Kubernetes 。这个开源工具由Kubernetes 社区维护,确保了与最新的Docker ComposeKubernetes版本的兼容性。

[1.2 Kompose的主要功能](#1.2 Kompose的主要功能)

Kompose 提供了一系列功能,使得Docker ComposeKubernetes的转换过程变得简单高效:

  1. 文件转换 :将docker-compose.yml 文件转换为Kubernetes 资源定义文件(如DeploymentServicePersistentVolumeClaim等)。

  2. 多种输出格式 :支持生成Kubernetes YAML 文件、Helm charts ,以及OpenShift特定的资源定义。

  3. 灵活的部署选项 :可以直接将转换后的资源部署到Kubernetes集群,或者仅生成资源定义文件供后续使用。

  4. 标签支持 :通过在Docker Compose 文件中使用特殊标签,可以精细控制转换过程和生成的Kubernetes资源。

  5. 多版本兼容 :支持Docker Compose 文件的多个版本(v1、v2、v3),以及不同版本的Kubernetes API

  6. 自定义转换:允许用户通过命令行选项和标签自定义转换过程,以适应特定需求。

  7. 构建和推送镜像 :能够在转换过程中构建Docker镜像并推送到镜像仓库。

  8. 多平台支持 :可在LinuxmacOSWindows等多个操作系统上运行。

可见,Kompose极大地简化了容器化应用向Kubernetes的迁移过程。它不仅降低了学习成本,还提高了迁移效率。因此本文后续就将介绍这个工具的安装用法。

[2. 安装Kompose](#2. 安装Kompose)

[2.1 二进制安装](#2.1 二进制安装)

Kompose 提供了预编译的二进制文件,可以直接下载并安装在LinuxmacOSWindows等主流操作系统上。这种安装方式简单快捷,无需额外的依赖,适合大多数用户。

对于Linux 系统,可以使用以下命令下载并安装Kompose

bash 复制代码
curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-linux-amd64 -o kompose

下载完成后,需要为文件添加可执行权限,并将其移动到系统的可执行路径中:

bash 复制代码
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose

对于macOS 系统,安装过程类似,但需要下载特定的macOS版本:

bash 复制代码
curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-darwin-amd64 -o kompose
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose

Windows 用户可以下载.exe文件,并将其添加到系统的PATH环境变量中:

powershell 复制代码
curl.exe -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-windows-amd64.exe -o kompose.exe

下载完成后,将kompose.exe文件移动到一个包含在PATH环境变量中的目录,例如C:\Windows\System32

安装完成后,可以通过在终端或命令提示符中运行以下命令来验证安装是否成功:

bash 复制代码
kompose version

如果安装成功,将会显示Kompose的版本信息。

需要注意的是,上述命令中的版本号v1.34.0可能会随时间推移而变化。在安装时,建议访问Kompose 的官方GitHub发布页面,获取最新的版本号,并相应地更新下载命令中的版本号。

二进制安装方法的优点是简单直接,无需额外的包管理器或依赖项。然而,这种方法的缺点是需要手动更新Kompose。当新版本发布时,需要重复上述下载和安装步骤来获取最新版本。

[2.2 包管理器安装](#2.2 包管理器安装)

除了二进制安装方法,Kompose 还可以通过各种包管理器进行安装。这种方法的优势在于可以更方便地管理和更新软件。以下是在不同操作系统上使用包管理器安装Kompose的方法。

对于Linux 系统,Kompose 可以通过多种包管理器安装。在Ubuntu 或其他基于Debian 的系统上,可以使用apt 包管理器。首先,需要添加Kompose的官方仓库:

bash 复制代码
sudo apt update
sudo apt install -y curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://packages.cloud.google.com/apt kompose-project main" | sudo tee /etc/apt/sources.list.d/kompose.list

然后,更新包列表并安装Kompose

bash 复制代码
sudo apt update
sudo apt install kompose

对于使用CentOSRHEL 的系统,可以使用yum 包管理器安装Kompose 。首先,添加Kompose的仓库:

bash 复制代码
sudo tee /etc/yum.repos.d/kompose.repo <<EOF
[kompose]
name=Kompose Repository
baseurl=https://packages.cloud.google.com/yum/repos/kompose-project
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

然后,使用yum 安装Kompose

bash 复制代码
sudo yum install kompose

macOS 系统上,可以使用Homebrew 包管理器安装KomposeHomebrewmacOS上广泛使用的包管理工具,安装过程非常简单:

bash 复制代码
brew install kompose

对于Windows 系统,虽然没有官方支持的包管理器安装方法,但可以使用Chocolatey 这样的第三方包管理器。首先需要安装Chocolatey ,然后可以使用以下命令安装Kompose

powershell 复制代码
choco install kompose

使用包管理器安装Kompose 的一个主要优势是可以轻松地进行更新。例如,在使用apt 的系统上,可以通过以下命令更新Kompose

bash 复制代码
sudo apt update
sudo apt upgrade kompose

在使用HomebrewmacOS系统上,更新命令是:

bash 复制代码
brew upgrade kompose

包管理器安装方法的另一个优点是它会自动处理依赖关系。如果Kompose需要特定的库或其他软件包,包管理器会自动安装这些依赖项。

无论选择哪种安装方法,安装完成后都可以通过运行kompose version命令来验证安装是否成功,并查看安装的Kompose版本。

[2.3 源码安装](#2.3 源码安装)

对于希望从源代码构建Kompose 的用户来说,源码安装提供了更大的灵活性和定制化选项。这种方法适合开发者或者希望深入了解Kompose 内部工作原理的高级用户。源码安装需要在系统上安装Go 语言环境,因为Kompose 是用Go语言编写的。

首先,确保系统中已经安装了Go 语言环境。可以从Go 官方网站下载并安装适合自己操作系统的版本。安装完成后,需要设置GOPATH环境变量。在LinuxmacOS 系统中,可以将以下行添加到.bashrc.zshrc文件中:

bash 复制代码
export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

对于Windows系统,可以通过系统设置来添加这些环境变量。

接下来,使用git命令克隆Kompose的源代码仓库:

bash 复制代码
git clone https://github.com/kubernetes/kompose.git $GOPATH/src/github.com/kubernetes/kompose

进入Kompose源代码目录:

bash 复制代码
cd $GOPATH/src/github.com/kubernetes/kompose

使用Go的包管理工具安装依赖:

bash 复制代码
go mod download

编译Kompose

bash 复制代码
make

这个命令会在$GOPATH/bin目录下生成kompose可执行文件。如果之前正确设置了PATH环境变量,现在应该可以直接在终端中运行kompose命令了。

可以通过运行以下命令来验证安装是否成功:

bash 复制代码
kompose version

如果看到Kompose的版本信息,说明安装成功。

源码安装的一个主要优势是可以轻松地获取最新的开发版本,或者对代码进行自定义修改。如果需要切换到特定的版本或分支,可以使用git checkout命令:

bash 复制代码
git checkout v1.34.0  # 或者任何其他版本标签或分支名

然后重新编译:

bash 复制代码
make

需要注意的是,从源码安装需要更多的系统资源和技术知识。对于大多数用户来说,二进制安装或包管理器安装可能是更简单的选择。但是,对于那些希望深入了解Kompose工作原理或者需要对其进行定制的用户来说,源码安装是一个很好的选择。

此外,源码安装还允许贡献者更容易地参与到Kompose 的开发中。如果发现了bug或者有改进建议,可以直接修改代码,然后提交拉取请求(Pull Request)到KomposeGitHub仓库。

[3. 基本用法](#3. 基本用法)

[3.1 转换Docker Compose文件](#3.1 转换Docker Compose文件)

Kompose 的核心功能是将Docker Compose 文件转换为Kubernetes资源定义文件。这个过程简单直接,只需要几个步骤就可以完成。

首先,确保已经安装了Kompose,并且在系统的可执行路径中。可以通过运行以下命令来验证安装:

bash 复制代码
kompose version

如果安装正确,将会显示Kompose的版本信息。

接下来,准备好Docker Compose 文件。如果没有现成的文件,可以创建一个简单的示例文件来测试。例如,创建一个名为docker-compose.yml的文件,内容如下:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
  db:
    image: postgres:12
    environment:
      POSTGRES_PASSWORD: example

这个示例定义了两个服务:一个web 服务使用nginx 镜像,一个db 服务使用PostgreSQL镜像。

现在,在包含docker-compose.yml文件的目录中运行以下命令:

bash 复制代码
kompose convert

Kompose 将会分析Docker Compose 文件,并生成对应的Kubernetes 资源定义文件。默认情况下,它会为每个服务创建一个Deployment 和一个Service

转换完成后,将会在当前目录下生成多个YAML文件。通常,会看到类似以下的输出:

INFO Kubernetes file "web-service.yaml" created
INFO Kubernetes file "db-service.yaml" created
INFO Kubernetes file "web-deployment.yaml" created
INFO Kubernetes file "db-deployment.yaml" created

这些生成的文件包含了Kubernetes 资源的定义,可以直接用于创建Kubernetes集群中的资源。

如果需要查看转换后的内容,可以使用文本编辑器打开这些YAML 文件。例如,web-deployment.yaml文件可能看起来像这样:

yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: web
  template:
    metadata:
      labels:
        io.kompose.service: web
    spec:
      containers:
      - image: nginx:alpine
        name: web
        ports:
        - containerPort: 80

Kompose 还提供了一些额外的选项来控制转换过程。例如,可以使用--file-f选项指定不同名称的Docker Compose文件:

bash 复制代码
kompose convert -f my-compose-file.yml

如果需要将所有资源定义合并到一个文件中,可以使用--out-o选项:

bash 复制代码
kompose convert -o kubernetes.yaml

这将生成一个名为kubernetes.yaml的文件,包含所有转换后的资源定义。

对于更复杂的Docker Compose 文件,Kompose 也能够处理诸如卷挂载、环境变量、依赖关系等配置。它会尽可能地将这些配置转换为Kubernetes 中的等效概念,如PersistentVolumeClaimConfigMap等。

需要注意的是,虽然Kompose 能够处理大多数常见的Docker Compose 配置,但某些Docker 特定的功能可能无法直接转换为Kubernetes 资源。在这些情况下,Kompose 会生成警告信息,提示用户可能需要手动调整生成的Kubernetes配置文件。

通过这种方式,Kompose 大大简化了从Docker ComposeKubernetes 的迁移过程,使得开发者可以快速将现有的容器化应用适配到Kubernetes环境中。

[3.2 部署到Kubernetes集群](#3.2 部署到Kubernetes集群)

在使用KomposeDocker Compose 文件转换为Kubernetes 资源定义后,下一步就是将这些资源部署到Kubernetes 集群中。Kompose提供了直接部署的功能,但也可以选择手动部署转换后的资源文件。

首先,确保已经正确配置了kubectl 工具,并且能够连接到目标Kubernetes集群。可以通过运行以下命令来验证连接:

bash 复制代码
kubectl cluster-info

如果配置正确,将会显示集群的基本信息。

对于项目的部署,首先使用Kompose生成资源定义文件:

bash 复制代码
kompose convert

这将在当前目录下生成多个YAML 文件。接下来,可以使用kubectl命令来应用这些文件:

bash 复制代码
kubectl apply -f .

这个命令会应用当前目录下的所有YAML 文件,创建相应的Kubernetes资源。

如果需要更精细的控制,可以选择逐个应用资源文件:

bash 复制代码
kubectl apply -f web-deployment.yaml
kubectl apply -f web-service.yaml
kubectl apply -f db-deployment.yaml
kubectl apply -f db-service.yaml

在部署过程中,可能会遇到一些常见问题。例如,如果Docker Compose 文件中使用了本地构建的镜像,需要确保这些镜像已经被推送到Kubernetes 集群可以访问的镜像仓库中。否则,Kubernetes将无法拉取这些镜像。

另一个常见问题是持久化存储。如果Docker Compose 文件中定义了卷挂载,Kompose 会生成相应的PersistentVolumeClaim 。但是,需要确保Kubernetes 集群中有合适的存储类(StorageClass )来满足这些声明。如果没有,可能需要手动创建PersistentVolume或配置动态存储供应。

对于包含环境变量或敏感信息的配置,Kompose 通常会将其转换为ConfigMapSecret资源。在部署之前,应该仔细检查这些资源,确保敏感信息得到适当保护。

部署完成后,可以使用以下命令来检查资源的状态:

bash 复制代码
kubectl get pods
kubectl get services
kubectl get deployments

这些命令将显示已创建的PodServiceDeployment 的状态。如果遇到问题,可以使用kubectl describe命令来获取更详细的信息:

bash 复制代码
kubectl describe pod <pod-name>

通过这种方式,可以将Docker Compose 项目顺利迁移到Kubernetes 环境中。虽然Kompose 大大简化了这个过程,但在实际部署时仍然需要考虑Kubernetes特有的概念和最佳实践,以确保应用在新环境中能够稳定高效地运行。

[3.3 访问部署的服务](#3.3 访问部署的服务)

在使用KomposeDocker Compose 项目转换并部署到Kubernetes 集群后,下一步是访问这些已部署的服务。访问方式取决于服务的类型和集群的配置。Kubernetes 提供了多种将服务暴露给外部访问的方式,包括NodePortLoadBalancerIngress

默认情况下,Kompose 会将Docker Compose 中的服务转换为KubernetesClusterIP 类型的Service。这种类型的服务只能在集群内部访问。要使服务能够从集群外部访问,需要进行额外的配置。

对于开发和测试环境,最简单的方法是使用NodePort 类型的服务。可以通过在Docker Compose 文件中添加标签来指示Kompose 创建NodePort服务:

yaml 复制代码
services:
  web:
    image: nginx
    ports:
      - "80:80"
    labels:
      kompose.service.type: nodeport

转换后,可以使用以下命令查看服务的详细信息:

bash 复制代码
kubectl get services

这将显示服务列表,包括分配的NodePort。例如:

NAME   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
web    NodePort   10.96.100.100   <none>        80:30080/TCP   1m

在这个例子中,服务可以通过集群中任何节点的IP地址和端口30080访问。

如果使用的是Minikube,可以使用以下命令快速打开服务:

bash 复制代码
minikube service web

这将自动打开默认浏览器并访问服务。

对于生产环境,通常推荐使用LoadBalancer 类型的服务或Ingress 资源。LoadBalancer类型需要云提供商的支持,可以通过以下标签指定:

yaml 复制代码
services:
  web:
    image: nginx
    ports:
      - "80:80"
    labels:
      kompose.service.type: loadbalancer

转换并部署后,可以使用以下命令查看LoadBalancer的外部IP:

bash 复制代码
kubectl get services web

当外部IP分配完成后,可以直接通过该IP访问服务。

对于更复杂的路由需求,可以使用Ingress 资源。Kompose 支持通过标签创建Ingress

yaml 复制代码
services:
  web:
    image: nginx
    ports:
      - "80:80"
    labels:
      kompose.service.expose: "true"

这将创建一个基本的Ingress 资源。需要注意的是,集群中必须安装和配置Ingress 控制器才能使Ingress资源生效。

创建Ingress后,可以使用以下命令查看其详细信息:

bash 复制代码
kubectl get ingress

根据Ingress控制器的配置,可能需要配置DNS或修改本地hosts文件来访问服务。

对于需要安全访问的服务,可以配置TLS 。这通常涉及创建Secret 资源来存储证书,并在Ingress 配置中引用该Secret

在访问服务时,可能会遇到一些常见问题。例如,服务无法访问可能是由于防火墙规则、网络策略或服务未正确暴露。可以使用kubectl describe service <service-name>命令来检查服务的详细信息,包括端点(Endpoints)是否正确设置。

此外,对于基于HTTP的服务,可以使用kubectl port-forward命令在本地快速测试服务:

bash 复制代码
kubectl port-forward service/web 8080:80

这将创建一个从本地端口8080到服务端口80的转发,允许通过http://localhost:8080访问服务。

总的来说,Kompose 简化了将Docker Compose 服务转换为Kubernetes 资源的过程,但在访问这些服务时,仍然需要考虑Kubernetes的网络模型和特定的访问策略。根据应用的需求和部署环境,选择合适的服务暴露方式是确保应用可访问性和安全性的关键。

[4. 高级功能](#4. 高级功能)

[4.1 支持的Docker Compose版本](#4.1 支持的Docker Compose版本)

Kompose 作为一个强大的转换工具,支持多个版本的Docker Compose 文件格式。这种广泛的兼容性使得Kompose 能够适应不同项目的需求,无论这些项目使用的是较旧的还是最新的Docker Compose规范。

Kompose 主要支持Docker Compose 的三个主要版本:版本1、版本2和版本3。每个版本都有其特定的语法和功能,Kompose都能够很好地处理。

对于版本1的Docker Compose 文件,这是最早的格式,语法相对简单。虽然现在不太常用,但Kompose 仍然保持对它的支持,以确保兼容性。一个典型的版本1的Docker Compose文件可能如下所示:

yaml 复制代码
web:
  image: nginx
  ports:
    - "80:80"
db:
  image: postgres

版本2引入了更多的结构化语法,包括顶级的version键和services部分。这个版本增加了许多新特性,如网络定义和卷配置。Kompose完全支持这个版本,能够正确解析和转换其中的大多数元素。一个版本2的示例如下:

yaml 复制代码
version: '2'
services:
  web:
    image: nginx
    ports:
      - "80:80"
  db:
    image: postgres
volumes:
  db-data:

版本3是当前最广泛使用的Docker Compose 格式,它进一步增强了配置的灵活性,并添加了对Docker Swarm 模式的支持。Kompose对这个版本有很好的支持,能够处理其中的大多数新特性。一个版本3的示例可能如下:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    deploy:
      replicas: 3
    ports:
      - "80:80"
  db:
    image: postgres
    volumes:
      - db-data:/var/lib/postgresql/data
volumes:
  db-data:

在使用Kompose 转换时,工具会自动检测Docker Compose 文件的版本,并应用相应的解析逻辑。这意味着用户通常不需要为不同版本的Docker Compose文件指定特殊的转换参数。

然而,需要注意的是,虽然Kompose 支持这些版本,但并非所有的Docker Compose 特性都能完美地映射到Kubernetes 概念。例如,Docker Compose 版本3中的deploy部分包含一些特定于Docker Swarm 的配置,这些配置在Kubernetes 中可能没有直接对应的概念。在这些情况下,Kompose会尽可能地进行合理的转换,并在必要时提供警告或忽略不兼容的配置。

对于一些特定版本的高级特性,Kompose 可能需要额外的配置或标签来正确处理。例如,对于版本3中的部署模式配置,可能需要使用Kompose 特定的标签来指导转换过程。这可以通过在Docker Compose文件中添加标签来实现,如:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    deploy:
      replicas: 3
    labels:
      kompose.service.type: deployment

在这个例子中,kompose.service.type标签明确指示Kompose 将该服务转换为KubernetesDeployment资源。

[4.2 转换为不同的Kubernetes对象](#4.2 转换为不同的Kubernetes对象)

Kompose 提供了灵活的选项,允许用户将Docker Compose 服务转换为不同类型的Kubernetes 对象。默认情况下,Kompose 会将服务转换为Deployment 对象,但它也支持其他类型的控制器,如DaemonSetReplicationController 。这种灵活性使得用户可以根据特定的需求和用例选择最合适的Kubernetes对象类型。

[4.2.1 Deployment](#4.2.1 Deployment)

DeploymentKompose 的默认转换目标,也是Kubernetes 中最常用的控制器类型之一。Deployment 提供了声明式的更新和管理Pod的能力,非常适合无状态应用程序。

要显式地将服务转换为Deployment,可以使用以下命令:

bash 复制代码
kompose convert --controller deployment

这个命令会生成Deployment 对象的YAML 文件。例如,对于一个名为web的服务,生成的web-deployment.yaml文件可能如下所示:

yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: web
  template:
    metadata:
      labels:
        io.kompose.service: web
    spec:
      containers:
      - image: nginx:alpine
        name: web
        ports:
        - containerPort: 80

Deployment对象允许轻松地进行滚动更新和回滚,这使得它成为管理应用程序的理想选择。

[4.2.2 DaemonSet](#4.2.2 DaemonSet)

DaemonSet 确保所有(或部分)节点运行Pod 的副本。当需要在每个节点上运行守护进程或代理时,DaemonSet是一个很好的选择。

要将服务转换为DaemonSet,可以使用以下命令:

bash 复制代码
kompose convert --controller daemonset

这将生成DaemonSet 对象的YAML 文件。例如,对于一个名为agent的服务,生成的agent-daemonset.yaml文件可能如下所示:

yaml 复制代码
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: agent
spec:
  selector:
    matchLabels:
      io.kompose.service: agent
  template:
    metadata:
      labels:
        io.kompose.service: agent
    spec:
      containers:
      - image: datadog/agent:latest
        name: agent

DaemonSet特别适合需要在每个节点上运行的服务,如日志收集器、监控代理等。

[4.2.3 ReplicationController](#4.2.3 ReplicationController)

虽然ReplicationController 在较新版本的Kubernetes 中已经不太常用,但Kompose 仍然支持将服务转换为这种类型的对象。ReplicationController 确保指定数量的Pod副本在任何时候都在运行。

要将服务转换为ReplicationController,可以使用以下命令:

bash 复制代码
kompose convert --controller replicationcontroller

这将生成ReplicationController 对象的YAML 文件。例如,对于一个名为backend的服务,生成的backend-replicationcontroller.yaml文件可能如下所示:

yaml 复制代码
apiVersion: v1
kind: ReplicationController
metadata:
  name: backend
spec:
  replicas: 1
  template:
    metadata:
      labels:
        io.kompose.service: backend
    spec:
      containers:
      - image: my-backend:v1
        name: backend
        ports:
        - containerPort: 8080

虽然ReplicationController 提供了基本的复制和故障转移功能,但在大多数情况下,建议使用更现代的DeploymentStatefulSet对象。

在选择控制器类型时,需要考虑应用程序的特性和需求。对于大多数无状态应用,Deployment 是最佳选择。对于需要在每个节点上运行的服务,DaemonSet 是理想的选择。而对于有特殊需求的遗留应用程序,ReplicationController可能仍然有其用武之地。

Kompose 的这种灵活性使得用户可以根据具体情况选择最合适的Kubernetes对象类型,从而更好地适应不同的部署场景和应用需求。在实际使用中,建议仔细评估每种控制器类型的特点,并结合应用程序的具体需求来做出选择。

[4.3 生成Helm Chart](#4.3 生成Helm Chart)

Kompose 不仅可以将Docker Compose 文件转换为单独的Kubernetes 资源定义文件,还能够生成完整的Helm ChartHelmKubernetes 的包管理器,它使用Chart 来定义、安装和升级复杂的Kubernetes 应用。通过生成Helm ChartKompose 为用户提供了一种更加灵活和可维护的方式来管理Kubernetes应用。

要使用Kompose 生成Helm Chart ,只需在转换命令中添加--chart选项。例如:

bash 复制代码
kompose convert --chart

执行此命令后,Kompose 将在当前目录下创建一个新的文件夹,其名称默认为chart。这个文件夹包含了一个完整的Helm Chart结构。

生成的Helm Chart通常包含以下文件和目录:

  1. Chart.yaml:这个文件包含了Chart的元数据,如名称、版本号和描述。

  2. values.yaml:这个文件定义了Chart的默认配置值。用户可以通过修改这个文件来自定义部署。

  3. templates/目录:这个目录包含了所有的Kubernetes 资源模板文件。这些模板使用了Helm 的模板语言,允许根据values.yaml中的值动态生成Kubernetes资源定义。

  4. charts/目录:如果Chart 有依赖其他Chart,这些依赖会被放在这个目录中。

  5. README.md:这个文件包含了Chart的使用说明和文档。

例如,对于一个包含web 服务和database 服务的Docker Compose 文件,生成的Helm Chart结构可能如下所示:

chart/
├── Chart.yaml
├── README.md
├── templates/
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── web-deployment.yaml
│   ├── web-service.yaml
│   ├── database-deployment.yaml
│   └── database-service.yaml
└── values.yaml

values.yaml文件中,可能会看到类似以下的内容:

yaml 复制代码
web:
  image: nginx:alpine
  replicaCount: 1
  service:
    type: ClusterIP
    port: 80

database:
  image: postgres:12
  replicaCount: 1
  service:
    type: ClusterIP
    port: 5432

这些值可以在安装或升级Chart时被覆盖,提供了极大的灵活性。

生成Helm Chart 后,可以使用Helm 命令来安装或升级应用。例如,要安装生成的Chart,可以运行:

bash 复制代码
helm install my-release ./chart

这个命令会将应用部署到Kubernetes 集群,并命名为my-release

Kompose 生成的Helm Chart 为进一步定制和管理应用提供了良好的起点。用户可以根据需要修改生成的模板和值文件,添加更多的Kubernetes资源,或者引入复杂的逻辑来处理不同的部署场景。
需要注意的是,虽然Kompose 生成的Helm Chart 在大多数情况下都能正常工作,但对于复杂的应用,可能需要进行一些手动调整。例如,可能需要添加额外的Kubernetes 资源,如IngressConfigMap ,或者修改某些资源的配置以更好地适应Kubernetes环境。

[5. 自定义转换](#5. 自定义转换)

[5.1 使用标签控制转换](#5.1 使用标签控制转换)

Kompose 提供了一种强大的机制,允许用户通过在Docker Compose 文件中添加特定的标签来精细控制转换过程。这些标签可以影响生成的Kubernetes 资源的各个方面,从资源类型到具体的配置细节。通过使用这些标签,用户可以在不修改Kompose源代码的情况下,自定义转换结果以满足特定需求。

标签通常在Docker Compose 文件的服务定义中的labels部分添加。Kompose 识别的标签通常以kompose.为前缀,以区别于其他可能存在的标签。

一个常用的标签是kompose.service.type,它允许用户指定生成的Kubernetes Service 的类型。例如,要将一个服务暴露为NodePort 类型,可以在Docker Compose文件中这样定义:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
    labels:
      kompose.service.type: nodeport

在这个例子中,Kompose 会生成一个NodePort 类型的Service ,而不是默认的ClusterIP类型。

另一个有用的标签是kompose.service.expose,它用于创建Ingress 资源(在Kubernetes 中)或Route 资源(在OpenShift中)。例如:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
    labels:
      kompose.service.expose: "true"

这将导致Kompose 除了创建ServiceDeployment 外,还会创建一个Ingress资源,使得服务可以从集群外部访问。

对于需要持久存储的服务,可以使用kompose.volume.size标签来指定PersistentVolumeClaim的大小:

yaml 复制代码
version: '3'
services:
  db:
    image: postgres
    volumes:
      - data:/var/lib/postgresql/data
    labels:
      kompose.volume.size: 1Gi

这会生成一个大小为1GB的PersistentVolumeClaim

Kompose还支持通过标签来配置健康检查。例如,要为服务添加就绪探针,可以使用以下标签:

yaml 复制代码
version: '3'
services:
  web:
    image: myapp
    labels:
      kompose.service.healthcheck.readiness.http.path: "/healthz"
      kompose.service.healthcheck.readiness.http.port: "8080"

这将在生成的Deployment 中添加一个基于HTTP的就绪探针,检查路径为/healthz,端口为8080。

对于需要特定调度策略的服务,可以使用kompose.service.nodeport.port标签来指定NodePort的具体端口号:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
    labels:
      kompose.service.type: nodeport
      kompose.service.nodeport.port: "30080"

这将创建一个NodePort 类型的Service,并将其外部端口设置为30080。

Kompose 还提供了控制资源限制的标签。例如,可以使用kompose.service.resources.limits.memorykompose.service.resources.limits.cpu来设置容器的内存和CPU限制:

yaml 复制代码
version: '3'
services:
  app:
    image: myapp
    labels:
      kompose.service.resources.limits.memory: 512Mi
      kompose.service.resources.limits.cpu: 500m

这将在生成的Deployment中为容器设置512MB的内存限制和0.5个CPU核心的限制。

通过组合使用这些标签,用户可以精确控制Kompose 的转换过程,生成符合特定需求的Kubernetes 资源定义。这种方法既保留了Docker Compose 文件的简洁性,又提供了向Kubernetes 平滑迁移的灵活性。然而,需要注意的是,过度使用标签可能会使Docker Compose文件变得复杂难以维护。因此,在使用这些标签时,应当权衡便利性和可维护性,选择最适合项目需求的配置方式。

[5.2 重启策略](#5.2 重启策略)

Docker Compose 中,重启策略定义了容器在退出时应该如何处理。Kompose 在转换过程中会考虑这些重启策略,并尝试将其映射到Kubernetes 中的等效概念。然而,由于DockerKubernetes 在处理容器重启方面有一些差异,Kompose需要进行一些调整和解释。

Docker Compose 支持几种不同的重启策略:noalwayson-failureunless-stoppedKompose 会根据这些策略生成相应的Kubernetes 资源,通常是DeploymentPodCronJob

对于no重启策略,Kompose 会创建一个普通的Pod ,而不是Deployment 。这是因为no策略表示容器退出后不应该重新启动,这与Deployment 的行为不符。在生成的Pod 定义中,restartPolicy字段会被设置为Never。例如:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: myapp
    image: myapp:latest
  restartPolicy: Never

对于always重启策略,Kompose 会创建一个Deployment ,这是最常见的情况。Deployment 会确保容器始终运行,如果容器退出,Kubernetes 会自动重启它。在这种情况下,PodrestartPolicy默认为Always。例如:

yaml 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest

对于on-failure重启策略,Kompose 的行为会根据上下文有所不同。如果服务没有定义为CronJob (通过特定的标签),Kompose 会创建一个Pod ,并将其restartPolicy设置为OnFailure。这意味着容器只有在非正常退出时才会重启。例如:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: myapp
    image: myapp:latest
  restartPolicy: OnFailure

如果服务被标记为CronJob (使用kompose.service.type: cronjob标签),Kompose 会创建一个CronJob 资源,其中Pod 模板的restartPolicy同样设置为OnFailure

对于unless-stopped重启策略,Kompose 会将其视为等同于always,因为Kubernetes 没有直接对应的概念。这种情况下,会创建一个Deployment ,行为与always策略相同。

Docker Compose文件中,重启策略通常在服务定义中指定,如下所示:

yaml 复制代码
version: '3'
services:
  myapp:
    image: myapp:latest
    restart: always

当使用Kompose转换这个文件时,可以使用以下命令:

bash 复制代码
kompose convert -f docker-compose.yml

Kompose 会解析重启策略并生成相应的Kubernetes资源定义。

需要注意的是,Kubernetes 的重启策略比Docker 的更加简化。Kubernetes 主要关注的是Pod 级别的重启策略,而更复杂的重启行为通常由更高级别的控制器(如Deployment )来管理。因此,在某些情况下,可能需要在转换后手动调整Kubernetes 资源定义,以更精确地匹配原始Docker Compose中的行为。

此外,Kompose 还提供了一些标签,允许用户更细粒度地控制生成的Kubernetes 资源。例如,可以使用kompose.controller.type标签来明确指定要生成的控制器类型,从而覆盖默认的行为。这为用户提供了额外的灵活性,以适应特定的部署需求。

[5.3 健康检查配置](#5.3 健康检查配置)

在将Docker Compose 项目转换为Kubernetes 资源时,健康检查是一个非常重要的方面。Kompose 提供了灵活的方式来配置健康检查,使得用户可以确保在Kubernetes环境中应用程序的可用性和稳定性。

Kubernetes 支持两种主要类型的健康检查:存活探针(Liveness Probe)和就绪探针(Readiness Probe)。存活探针用于检测容器是否仍在运行,如果探测失败,Kubernetes 将重启容器。就绪探针用于检测容器是否准备好接受流量,如果探测失败,Kubernetes将暂时从服务负载均衡中移除该容器。

Kompose 允许用户通过在Docker Compose 文件中添加特定的标签来配置这些健康检查。这些标签以kompose.service.healthcheck为前缀,后面跟着具体的配置选项。

对于存活探针,可以使用以下标签:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    labels:
      kompose.service.healthcheck.liveness.http_get_path: "/healthz"
      kompose.service.healthcheck.liveness.http_get_port: "8080"
      kompose.service.healthcheck.liveness.initial_delay_seconds: "30"
      kompose.service.healthcheck.liveness.period_seconds: "10"

在这个例子中,Kompose 会生成一个Deployment ,其中包含一个HTTP GET类型的存活探针。探针会检查容器的8080端口上的/healthz路径。初始延迟设置为30秒,之后每10秒进行一次检查。

对于就绪探针,配置方式类似,只需将标签中的liveness替换为readiness

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    labels:
      kompose.service.healthcheck.readiness.tcp_port: "80"
      kompose.service.healthcheck.readiness.initial_delay_seconds: "5"
      kompose.service.healthcheck.readiness.period_seconds: "5"

这个配置会生成一个基于TCP的就绪探针,检查容器的80端口。初始延迟为5秒,之后每5秒进行一次检查。

Kompose还支持命令类型的健康检查。例如,可以使用以下配置来设置一个基于命令的存活探针:

yaml 复制代码
version: '3'
services:
  app:
    image: myapp
    labels:
      kompose.service.healthcheck.liveness.test: "CMD-SHELL"
      kompose.service.healthcheck.liveness.command: "pg_isready -U postgres || exit 1"
      kompose.service.healthcheck.liveness.interval: "10s"
      kompose.service.healthcheck.liveness.timeout: "5s"
      kompose.service.healthcheck.liveness.retries: "5"

在这个例子中,Kompose 会生成一个使用pg_isready命令检查PostgreSQL数据库是否就绪的存活探针。探针每10秒执行一次,超时时间为5秒,最多重试5次。

需要注意的是,虽然Kompose 提供了这些配置选项,但并非所有的Docker Compose 健康检查配置都能完全映射到Kubernetes 的探针配置上。在某些情况下,可能需要在转换后手动调整生成的Kubernetes资源定义。

此外,Kompose还支持禁用特定类型的探针。例如,如果希望禁用就绪探针,可以使用以下配置:

yaml 复制代码
version: '3'
services:
  web:
    image: nginx
    labels:
      kompose.service.healthcheck.readiness.disable: "true"

这在某些特殊场景下可能会有用,比如当应用程序有自己的健康检查机制,或者在特定的部署策略中不需要就绪探针时。

在配置健康检查时,建议根据应用程序的特性和需求来设置适当的参数。例如,对于需要较长启动时间的应用,可能需要设置较长的初始延迟。对于对响应时间敏感的服务,可能需要更频繁的检查和更短的超时时间。

通过合理配置健康检查,可以提高应用在Kubernetes 环境中的可靠性和可用性。Kompose 提供的这些配置选项,使得从Docker ComposeKubernetes的迁移过程中,能够保留和优化原有的健康检查策略,确保应用在新的环境中能够稳定运行。

[6. 构建和推送镜像](#6. 构建和推送镜像)

[6.1 构建镜像](#6.1 构建镜像)

Kompose 的转换过程中,构建镜像是一个重要的步骤,特别是当Docker Compose 文件中包含了需要构建的服务时。Kompose 提供了内置的功能来支持镜像构建,使得从Docker ComposeKubernetes的迁移过程更加流畅。

默认情况下,Kompose 不会自动构建镜像。然而,通过使用--build选项,可以指示Kompose 在转换过程中构建镜像。这个选项告诉KomposeDocker Compose文件中定义的、需要构建的服务执行构建操作。

要使用Kompose 构建镜像,可以在转换命令中添加--build标志。例如:

bash 复制代码
kompose convert --build

当执行这个命令时,Kompose 会检查Docker Compose 文件中的每个服务,如果发现服务定义中包含build指令,就会触发构建过程。构建过程使用Docker 引擎来执行,因此需要确保系统中安装了Docker ,并且Docker守护进程正在运行。

例如,考虑以下Docker Compose文件:

yaml 复制代码
version: '3'
services:
  webapp:
    build: ./webapp
    ports:
      - "8080:8080"
  database:
    image: postgres:12

在这个例子中,webapp服务需要构建,而database服务使用的是预构建的镜像。当运行kompose convert --build命令时,Kompose 会尝试构建webapp服务的镜像。

构建过程会在./webapp目录中查找Dockerfile,并使用该文件来构建镜像。如果构建成功,Kompose 会在生成的Kubernetes资源定义中使用这个新构建的镜像。

需要注意的是,Kompose 构建的镜像默认会使用项目名称和服务名称作为标签。例如,如果项目名为myproject,那么构建的镜像可能会被标记为myproject_webapp:latest

Kompose 还支持更复杂的构建配置。例如,如果Docker Compose 文件中指定了构建参数(args),Kompose会在构建过程中传递这些参数。例如:

yaml 复制代码
version: '3'
services:
  webapp:
    build:
      context: ./webapp
      args:
        VERSION: "1.0"
    ports:
      - "8080:8080"

在这种情况下,Kompose 会在构建过程中将VERSION参数传递给Docker构建命令。

对于使用多阶段构建的DockerfileKompose也能够正确处理。它会执行完整的构建过程,包括所有的构建阶段。

然而,需要注意的是,Kompose 的构建功能主要是为了方便开发和测试。在生产环境中,通常建议使用专门的持续集成/持续部署(CI/CD)管道来处理镜像的构建和推送。这样可以更好地控制构建过程,并确保镜像的一致性和安全性。

此外,当使用--build选项时,Kompose 会在本地构建镜像,但不会自动将镜像推送到远程仓库。如果需要将构建的镜像推送到远程仓库,需要额外使用--push-image选项。这个过程将在下一节中详细讨论。

[6.2 推送镜像到仓库](#6.2 推送镜像到仓库)

在将Docker Compose 项目转换为Kubernetes 资源并部署时,确保所有必要的镜像都可以被Kubernetes 集群访问是至关重要的。Kompose提供了内置功能,可以在转换过程中自动构建和推送镜像到指定的镜像仓库。这个功能特别有用,尤其是当Docker Compose文件中包含本地构建的镜像时。

要使用Kompose 推送镜像到仓库,需要在执行转换命令时添加--push-image标志。例如:

bash 复制代码
kompose convert --push-image

默认情况下,Kompose 会尝试将镜像推送到Docker Hub 。然而,在许多生产环境中,可能需要使用私有镜像仓库。为此,Kompose 提供了--push-image-registry选项,允许指定自定义的镜像仓库地址。

例如,要将镜像推送到私有的Harbor仓库,可以使用以下命令:

bash 复制代码
kompose convert --push-image --push-image-registry harbor.example.com

这个命令会将所有本地构建的镜像推送到harbor.example.com仓库。

在推送镜像之前,需要确保已经正确配置了Docker 客户端的认证信息。Kompose 使用Docker 的认证机制来访问镜像仓库。对于大多数Linux 系统,这些认证信息存储在$HOME/.docker/config.json文件中。在macOS上,认证信息通常存储在系统的钥匙串中。

如果使用私有仓库,首先需要使用Docker命令行工具登录到该仓库:

bash 复制代码
docker login harbor.example.com

登录成功后,Kompose就可以使用这些凭证来推送镜像。

需要注意的是,在macOS 上,如果使用了osxkeychain作为凭证存储,可能会遇到认证问题。在这种情况下,可以尝试在$HOME/.docker/config.json文件中手动设置凭证,或者使用环境变量来提供认证信息。

对于需要在镜像名称中包含仓库地址的情况,可以在Docker Compose文件中直接指定完整的镜像名称。例如:

yaml 复制代码
version: '3'
services:
  app:
    build: .
    image: harbor.example.com/myproject/myapp:latest

这样,当使用--push-image选项时,Kompose会将镜像推送到指定的地址。

在推送过程中,Kompose会显示每个镜像的推送进度。如果推送失败,会提供错误信息,帮助诊断问题。常见的失败原因包括网络问题、认证失败或仓库空间不足。

推送完成后,Kompose 生成的Kubernetes 资源定义文件中的镜像引用将使用推送后的完整镜像地址。这确保了Kubernetes集群可以正确拉取这些镜像。

对于大规模部署或持续集成/持续部署(CI/CD)场景,可以考虑将Kompose的镜像推送功能集成到自动化流程中。这可以通过脚本或CI/CD工具来实现,确保每次更新后镜像都被正确构建和推送到指定的仓库。
【注】值得一提的是,虽然Kompose 的镜像推送功能非常方便,但在生产环境中,可能还需要考虑更复杂的镜像管理策略。这可能包括版本控制、漏洞扫描、签名验证等。在这些情况下,可能需要结合使用其他专门的工具来补充Kompose的功能,以满足更严格的安全和合规要求。

[6.3 自定义构建和推送命令](#6.3 自定义构建和推送命令)

Kompose 提供了灵活的选项,允许用户自定义构建和推送镜像的过程。这个功能特别有用,尤其是在需要使用非标准的容器构建工具或特定的镜像仓库时。通过自定义构建和推送命令,用户可以将Kompose集成到现有的CI/CD流程中,或者适应特殊的开发环境需求。

要使用自定义的构建命令,可以使用--build-command选项。这个选项允许指定一个替代的命令来构建Docker 镜像。例如,如果想使用Buildah 而不是Docker 来构建镜像,可以这样使用Kompose

bash 复制代码
kompose convert --build --build-command 'buildah bud -t {{.Image}} {{.Context}}'

在这个命令中,{``{.Image}}{``{.Context}}Kompose 提供的模板变量。{``{.Image}}会被替换为Docker Compose 文件中指定的镜像名称,而{``{.Context}}会被替换为构建上下文路径。

类似地,对于推送镜像到仓库,可以使用--push-command选项来自定义推送过程。例如,如果需要使用Skopeo 来推送镜像,可以这样使用Kompose

bash 复制代码
kompose convert --push --push-command 'skopeo copy docker-daemon:{{.Image}} docker://{{.Image}}'

在这个命令中,{``{.Image}}会被替换为完整的镜像名称,包括仓库地址和标签。

这些自定义命令特别有用,例如在使用PodmanBuildah 等替代容器工具的环境中。以下是一个更复杂的例子,展示了如何在一个使用Podman的环境中自定义构建和推送过程:

bash 复制代码
kompose convert --build --push \
  --build-command 'podman build -t {{.Image}} {{.Context}}' \
  --push-command 'podman push {{.Image}}'

这个命令使用Podman 来构建和推送镜像,而不是默认的Docker命令。

自定义构建和推送命令还可以包含额外的参数或环境变量。例如,如果需要在构建过程中传递构建参数,可以这样做:

bash 复制代码
kompose convert --build \
  --build-command 'docker build --build-arg VERSION=1.2.3 -t {{.Image}} {{.Context}}'

这个命令在构建过程中传递了一个名为VERSION的构建参数。

需要注意的是,当使用自定义构建和推送命令时,确保命令中包含了所有必要的信息,如镜像名称和构建上下文。Kompose会替换模板变量,但不会自动添加缺失的信息。

此外,自定义命令应该考虑到错误处理和退出码。Kompose 会根据命令的退出码来判断构建或推送是否成功。如果自定义命令失败,应该确保它返回非零的退出码,以便Kompose能够正确地处理错误情况。

通过这种方式,Kompose 为用户提供了极大的灵活性,使其能够适应各种不同的构建和部署环境。无论是使用标准的Docker 工具链,还是采用替代的容器技术,Kompose 都能够无缝集成,帮助用户实现从Docker ComposeKubernetes的平滑迁移。

[7. 结论与回顾](#7. 结论与回顾)

本文全面介绍了Kompose 工具,详细讲解了其在将Docker Compose 项目转换为Kubernetes 资源方面的功能和用法。文章涵盖了Kompose 的安装方法、基本使用流程、高级功能如支持不同Docker Compose 版本和生成多种Kubernetes对象,以及自定义转换过程的方法。

此外,文章深入探讨了Kompose 在处理重启策略、健康检查配置方面的能力,以及其在构建和推送镜像过程中的灵活性。通过详细的示例和说明,文章展示了Kompose 如何简化从Docker ComposeKubernetes的迁移过程,同时提供了足够的定制选项以满足复杂的部署需求。

相关推荐
ZHOU西口1 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
牛角上的男孩2 小时前
Istio Gateway发布服务
云原生·gateway·istio
JuiceFS3 小时前
好未来:多云环境下基于 JuiceFS 建设低运维模型仓库
运维·云原生
景天科技苑4 小时前
【云原生开发】K8S多集群资源管理平台架构设计
云原生·容器·kubernetes·k8s·云原生开发·k8s管理系统
wclass-zhengge4 小时前
K8S篇(基本介绍)
云原生·容器·kubernetes
颜淡慕潇5 小时前
【K8S问题系列 |1 】Kubernetes 中 NodePort 类型的 Service 无法访问【已解决】
后端·云原生·容器·kubernetes·问题解决
川石课堂软件测试6 小时前
性能测试|docker容器下搭建JMeter+Grafana+Influxdb监控可视化平台
运维·javascript·深度学习·jmeter·docker·容器·grafana
昌sit!13 小时前
K8S node节点没有相应的pod镜像运行故障处理办法
云原生·容器·kubernetes
A ?Charis15 小时前
Gitlab-runner running on Kubernetes - hostAliases
容器·kubernetes·gitlab
wclass-zhengge16 小时前
Docker篇(Docker Compose)
运维·docker·容器