当前,我们的k8s项目具有以下用例,即名称空间被硬编码到values.yaml和应用程序源代码中
(apps) namespace - NS1
> micro-service-A1
> micro-service-A2
> micro-service-A3
(database) namespace - DB1
> mongo-service
(messaging) namespace - MB1
> kafka-zk-service
我们要在每个工程师(开发人员)定义的唯一命名空间中运行上述服务的多组(应用程序,数据库,消息传递) 这样,每个开发人员都可以安全地降低/变通更改属于他的完整集,而不必担心会影响其他开发人员的名称空间。
#Developer1(设置)
(apps) namespace - Dev1
> micro-service-A1
> micro-service-A2
> micro-service-A3
(database) namespace - Dev1_DB
> mongo-service
(messaging) namespace - Dev1_MB
> kafka-zk-service
#Developer2(设置)
(apps) namespace - Dev2
> micro-service-A1
> micro-service-A2
> micro-service-A3
(database) namespace - Dev2_DB
> mongo-service
(messaging) namespace - Dev2_MB
> kafka-zk-service
yamls和应用程序源代码的配置应该是什么,以便在开发人员选择的任何命名空间中都可以进行动态部署?
答案 0 :(得分:2)
外部化配置是件好事,这样您就可以使用其他配置而无需构建新映像。
使用ConfigMap进行地址如下的配置其他服务或数据库。有关地址,请参见DNS for Services and Pods。
apiVersion: v1
kind: ConfigMap
metadata:
name: config
data:
SERVICE_A: service-a.a-namespace.svc.cluster.local
SERVICE_B: service-b.b-namespace.svc.cluster.local
DB: db.local
通过在PodTemplate的Pod
或Deployment
中映射它,将ConfigMap中的值用作应用程序中的环境变量
containers:
- name: app-container
image: k8s.gcr.io/app-image
env:
- name: SERVICE_A_ADDRESS
valueFrom:
configMapKeyRef:
name: config
key: SERVICE_A
- name: SERVICE_B_ADDRESS
valueFrom:
configMapKeyRef:
name: config
key: SERVICE_B
如果您想将服务移至新的命名空间但保留地址,则可以保留Service with External Name
kind: Service
apiVersion: v1
metadata:
name: service-a
namespace: namespace-a
spec:
type: ExternalName
externalName: service-c.namespace-c.svc.cluster.local
ports:
- port: 80
答案 1 :(得分:0)
在应用配置时,您可以使用--namespace
标志来传递名称空间,而不是在配置文件中对其进行硬编码。
kubectl apply -f service.yml --namespace=test
kubectl apply -f service.yml --namespace=prod
通过这种方式,您可以使用相同的配置文件在不同的命名空间中创建服务资源。