我有一个与此 github 问题类似的问题。
但是,我可以使用守护程序集而不是服务来代替服务,而不是使用服务吗?这个想法是与同一节点上的所有 Pod 共享同一个套接字。它是否会遇到与同一问题的答案中提到的相同的安全问题。我问是因为挎斗容器方法阻止了我生成更多的 pod。事实上,我有不同类型的服务在云SQL上使用相同的数据库。每个 pod 都必须为代理保留一些 CPU 和内存,这对我来说听起来是多余的。
是的,你可以这样做。 但是,守护程序集的 pod 将不再侦听本地主机。 因此,您必须将cloud_sql_proxy和数据库连接配置为使用节点的 hostIP。
您必须将cloud_sql_proxy
设置为收听0.0.0.0
- command:
- /cloud_sql_proxy
- -instances=project:region:db=tcp:0.0.0.0:5432
- -credential_file=/secrets/cloudsql/credentials.json
您还必须更改数据库连接以使用 hostIP
env:
- name: DB_HOST
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.hostIP
使用 @Doug 的答案,我成功地从将云 sql 代理作为挎斗运行过渡到守护程序集。我的守护程序集定义如下。我添加了对具有某些 pod 的节点的亲和力,因为我只需要可用于核心应用程序的代理,而不是外围系统,如 redis。
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: cloudsql-proxy
labels:
app: cloudsql-proxy
spec:
template:
metadata:
labels:
app: cloudsql-proxy
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- sentry-web-internal
- sentry-web-external
- sentry-worker
- sentry-base
- sentry-cron
- data-scrubber
topologyKey: "kubernetes.io/hostname"
containers:
- name: cloudsql-proxy
image: 'gcr.io/cloudsql-docker/gce-proxy:1.13'
command:
- /cloud_sql_proxy
args:
- --dir=/cloudsql
- -instances=project:region:db=tcp:0.0.0.0:5432
- -credential_file=/secrets/cloudsql/credentials.json
ports:
- name: cloudsql-port
containerPort: 5432
hostPort: 5432
livenessProbe:
tcpSocket:
port: cloudsql-port
initialDelaySeconds: 30
timeoutSeconds: 5
readinessProbe:
tcpSocket:
port: cloudsql-port
initialDelaySeconds: 5
timeoutSeconds: 1
resources:
limits:
cpu: 150m
memory: 150Mi
requests:
cpu: 100m
memory: 100Mi
volumeMounts:
- name: cloudsql-instance-credentials
mountPath: /secrets/cloudsql
readOnly: true
volumes:
- name: cloudsql-instance-credentials
secret:
secretName: cloudsql-instance-credentials
我在同一个存储库中问了同样的问题。团队的回答是肯定的。您可以使用守护程序集方法。但是,我对守护程序集方法没有任何实践经验。因此,请谨慎使用它。