我有一个docker-compose.yml
文件,我们一直用它来设置我们的开发环境。
该文件声明了一些服务,所有服务都或多或少遵循相同的模式:
services:
service_1:
image: some_image_1
enviroment:
- ENV_VAR_1
- ENV_VAR_2
depends_on:
- another_service_of_the_same_compose_file
在迁移到kubernetes
的视图中,运行时:
kompose convert -f docker-compose.yml
为每个服务生成一对部署/服务清单。
关于部署生成的两个问题:
1.
official documentation中的示例似乎暗示部署需要selector
字段以了解要管理的pod。
但是,创建的部署清单不包含selector
字段,如下所示:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.6.0 (e4adfef)
creationTimestamp: null
labels:
io.kompose.service: service_1
name: service_1
spec:
replicas: 1
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
io.kompose.service: service_1
spec:
containers:
- image: my_image
name: my_image_name
resources: {}
restartPolicy: Always
status: {}
2.
生成的部署清单中的apiVersion
是extensions/v1beta1
,但是Deployments
的official documentation部分中的示例默认为apps/v1
。建议似乎是
对于1.9.0之前的版本,使用apps / v1beta2
哪个版本使用正确? (使用kubernetes 1.8
)
让我们首先说Kubernetes和Kompose是两个不同的独立系统。 Kompose试图将所有依赖性与kubernetes相匹配。
目前,所有选择器的字段都是由kubernetes生成的。将来,它可能由我们完成。
如果您想检查选择器的字段,请使用以下命令
kubectl get deploy
kubectl describe deploy DEPLOY_NAME
在版本k8s 1.9之后,所有长时间运行的对象都将成为/ apps组的一部分。
我们很高兴地宣布apps / v1 Workloads API的一般可用性(GA),现在默认启用。 Apps Workloads API将DaemonSet,Deployment,ReplicaSet和StatefulSet API组合在一起,为Kubernetes中长期运行的无状态和有状态工作负载奠定了基础。请注意,Batch Workloads API(Job和CronJob)不是此工作的一部分,并且具有GA稳定性的单独路径。
我已附上该链接以供进一步研究