我有一个Kubernetes JOB，用于对CloudSQL数据库进行迁移。
从GKE访问CloudSQL数据库的一种方法是使用CloudSQL代理容器，然后通过localhost连接。很好-到目前为止都可以了。但由于我是在K8s JOB中执行此操作，因此该作业未标记为成功完成，因为代理继续运行。
$ kubectrl get po
NAME READY STATUS RESTARTS AGE
db-migrations-c1a547 1/2 Completed 0 1m
即使输出显示“完成”，但最初的两个容器之一仍在运行 - 代理。
我该如何让代理在完成容器1内的迁移后退出？
我发现最好的方法是在容器之间共享进程命名空间，并使用SYS_PTRACE securityContext功能来允许您终止sidecar。
apiVersion: batch/v1
kind: Job
metadata:
name: my-db-job
spec:
template:
spec:
restartPolicy: OnFailure
shareProcessNamespace: true
containers:
- name: my-db-job-migrations
command: ["/bin/sh", "-c"]
args:
- |
<your migration commands>;
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid;
securityContext:
capabilities:
add:
- SYS_PTRACE
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.17
command:
- "/cloud_sql_proxy"
args:
- "-instances=$(DB_CONNECTION_NAME)=tcp:5432"
my-db-job-migrations 容器时才能正常工作。 - Yasha0.0.0.0 的部分 ;) - Philipp Kyeck有三种方法可以做到这一点。
1- 使用私有IP连接K8s作业与Cloud SQL，如@newoxo在其中一个答案中所述。要做到这一点，您的集群需要是一个VPC原生集群。我的不是，而且我也不想将所有的东西都移到一个新的集群中。因此，我无法做到这一点。
2- 将Cloud SQL代理容器放在一个单独的部署中，并使用服务进行管理，如@Christian Kohler所述。这看起来是一个很好的方法，但Google Cloud Support不推荐使用。
我本来要朝着这个方向（解决方案#2）前进，但我决定尝试其他的东西。
以下是对我有效的解决方案：
3- 您可以使用文件系统在同一Pod / Job中的不同容器之间通信。思路是告诉Cloud SQL代理容器主要作业何时完成，然后杀死cloud sql代理。以下是如何操作：
在yaml文件（my-job.yaml）中
apiVersion: v1
kind: Pod
metadata:
name: my-job-pod
labels:
app: my-job-app
spec:
restartPolicy: OnFailure
containers:
- name: my-job-app-container
image: my-job-image:0.1
command: ["/bin/bash", "-c"]
args:
- |
trap "touch /lifecycle/main-terminated" EXIT
{ your job commands here }
volumeMounts:
- name: lifecycle
mountPath: /lifecycle
- name: cloudsql-proxy-container
image: gcr.io/cloudsql-docker/gce-proxy:1.11
command: ["/bin/sh", "-c"]
args:
- |
/cloud_sql_proxy -instances={ your instance name }=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
PID=$!
while true
do
if [[ -f "/lifecycle/main-terminated" ]]
then
kill $PID
exit 0
fi
sleep 1
done
securityContext:
runAsUser: 2 # non-root user
allowPrivilegeEscalation: false
volumeMounts:
- name: cloudsql-instance-credentials
mountPath: /secrets/cloudsql
readOnly: true
- name: lifecycle
mountPath: /lifecycle
volumes:
- name: cloudsql-instance-credentials
secret:
secretName: cloudsql-instance-credentials
- name: lifecycle
emptyDir:
基本上，当您的主要工作完成后，它将在 /lifecycle 中创建一个文件，并由添加到 cloud-sql-proxy 容器中的 watcher 所识别，该 watcher 将关闭代理并终止容器。
希望有所帮助！如果您有任何问题，请告诉我。
spec中设置concurrencyPolicy: Replace，这将在需要再次运行时使用新实例来替换当前的Pod。但是，您必须确保后续的cron运行足够分离。很不幸，其他答案对我来说都无法工作，因为CloudSQLProxy在一个没有shell的distroless环境中运行。
我通过将CloudSQLProxy二进制文件与我的部署捆绑在一起，并运行一个bash脚本来启动CloudSQLProxy，然后启动我的应用程序来解决了这个问题。
Dockerfile：
FROM golang:1.19.4
RUN apt update
COPY . /etc/mycode/
WORKDIR /etc/mycode
RUN chmod u+x ./scripts/run_migrations.sh
RUN chmod u+x ./bin/cloud_sql_proxy.linux-amd64
RUN go install
ENTRYPOINT ["./scripts/run_migrations.sh"]
Shell脚本（run_migrations.sh）：
#!/bin/sh
# This script is run from the parent directory
dbConnectionString=$1
cloudSQLProxyPort=$2
echo "Starting Cloud SQL Proxy"
./bin/cloud_sql_proxy.linux-amd64 -instances=${dbConnectionString}=tcp:5432 -enable_iam_login -structured_logs &
CHILD_PID=$!
echo "CloudSQLProxy PID: $CHILD_PID"
echo "Migrating DB..."
go run ./db/migrations/main.go
MAIN_EXIT_CODE=$?
kill $CHILD_PID;
echo "Migrations complete.";
exit $MAIN_EXIT_CODE
K8s（通过 Pulumi）：
import * as k8s from '@pulumi/kubernetes'
const jobDBMigrations = new k8s.batch.v1.Job("job-db-migrations", {
metadata: {
namespace: namespaceName,
labels: appLabels,
},
spec: {
backoffLimit: 4,
template: {
spec: {
containers: [
{
image: pulumi.interpolate`gcr.io/${gcpProject}/${migrationsId}:${migrationsVersion}`,
name: "server-db-migration",
args: [
dbConnectionString,
],
},
],
restartPolicy: "Never",
serviceAccount: k8sSAMigration.metadata.name,
},
},
},
},
{
provider: clusterProvider,
});