连接到部署在 Kubernetes 中的 SQL Server Docker 容器时，用户 SA 登录失败

Question

我正在关注有关微服务的教程 https://www.youtube.com/watch?v=DgVjEo3OGBI

有时，我使用此 Yaml 文件在 Kubernetes 中部署 SQL Server 映像：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mssql-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      containers:
        - name: mssql
          image: mcr.microsoft.com/mssql/server:2019-latest
          ports:
            - containerPort: 1433
          env:
          - name: MSSQL_PID
            value: "Express"
          - name: ACCEPT_EULA
            value: "Y"
          - name: SA_PASSWORD 
            valueFrom:
              secretKeyRef:
                name: mssql5 
                key: SA_PASSWORD
          volumeMounts:
          - mountPath: /var/opt/mssql/data
            name: mssqldb
      volumes:
      - name: mssqldb
        persistentVolumeClaim:
          claimName: mssql-claim
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-clusterip-srv
spec:
  type: ClusterIP
  selector:
    app: mssql
  ports:
  - name: mssql
    protocol: TCP
    port: 1433
    targetPort: 1433
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: mssql
  ports:
  - protocol: TCP
    port: 1433
    targetPort: 1433

还有 PVC.yaml：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mssql-claim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 200Mi

然后，我在 Kubernets 中创建一个秘密，保存 SQL Server sa 帐户的密码，然后在 Yaml 文件中使用该秘密。

kubectl create secret generic mssql5 --from-literal=SA_PASSWORD="MyC0m9l&xPassw0rd"

然后应该可以使用 sa 帐户和密码直接连接到本地主机端口 1433 上的 SQL Server 容器。

但是，我在尝试连接时收到“用户 SA 登录失败”错误。我已经尝试了所有方法，包括将 SA_PASSWORD 更改为 MSSQL_SA_PASSWORD、更改密码的复杂性、在 SQL Server 中启用 sa 用户登录，该功能之前被禁用，并且像我以前从未用 google 过一样进行 google 搜索。 TCP/IP 设置在 SQL Server 配置管理器中启用。我无法访问。谁能解释一下这个问题？

Answer 1

如果你关闭该服务，它就会工作

Answer 2

TL;DR 这个特定问题的解决方案是 https://stackoverflow.com/users/52045/soeren 在其计算机上运行一个 SQL Server 实例，该实例在到达 K8s 之前拦截端口 1433 请求。禁用计算机上的 SQL Server 实例解决了问题，端口 1433 流量路由到 K8s 负载均衡器。

原始解决方案如下...

我已将上面的 YAML 逐字复制/粘贴到文件

deployment.yaml

和

pvc.yaml

中，然后运行这些命令。

kubectl create -f pvc.yaml
kubectl create secret generic mssql5 --from-literal=SA_PASSWORD="MyC0m9l&xPassw0rd"
kubectl create -f deployment.yaml

我可以通过本地主机连接并创建数据库。

结论是您的 YAML 看起来不错。

如果我再次删除/创建部署...

kubectl delete -f deployment.yaml
kubectl create-f deployment.yaml

..SSMS 连接仍然有效，并且测试数据库仍然存在。

我个人要做的唯一更改是从

- mountPath: /var/opt/mssql/data

中的

- mountPath: /var/opt/mssql/

更改为

deployment.yaml

，以便保留整个mssql路径。

当您包含

/data

文件夹时，这意味着

logs

和

secrets

文件夹仍在 POD 中，而不是持久卷中。这也许可以解释您上面提到的

ldf

日志文件权限问题？

所以，接下来我调查了持久卷

kubectl describe pv

，在我的系统上它显示以下内容：

Type:          HostPath (bare host directory volume)
    Path:          /var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4

我猜您正在使用hostPath，它将文件存储在包含节点/主机上。我使用的是 Docker Kubernetes，而不是 minikube。单节点集群。

如果您以 root 身份进入节点（而不是 POD）：

docker run -it --rm --privileged --pid=host justincormack/nsenter1

您可以

cd /var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4

查看持久卷声明的已安装卷。

您应该看到类似以下内容：

/ # cd /var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4
/var/lib/k8s-pvs/mssql-claim/pvc-42f91115-efdb-4cea-90d8-204fd592f6b4 # ls -l
total 89348
-rw-r-----    1 10001    root           256 Feb 14 17:33 Entropy.bin
-rw-r-----    1 10001    root       8388608 Feb 14 17:36 Test.mdf
-rw-r-----    1 10001    root       8388608 Feb 14 17:55 Test_log.ldf
-rw-r-----    1 10001    root       4653056 Feb 14 17:54 master.mdf
-rw-r-----    1 10001    root       2097152 Feb 14 18:00 mastlog.ldf
-rw-r-----    1 10001    root       8388608 Feb 14 17:49 model.mdf
-rw-r-----    1 10001    root      14090240 Feb 14 17:49 model_msdbdata.mdf
-rw-r-----    1 10001    root        524288 Feb 14 17:49 model_msdblog.ldf
-rw-r-----    1 10001    root        524288 Feb 14 17:49 model_replicatedmaster.ldf
-rw-r-----    1 10001    root       4653056 Feb 14 17:49 model_replicatedmaster.mdf
-rw-r-----    1 10001    root       8388608 Feb 14 17:49 modellog.ldf
-rw-r-----    1 10001    root      14090240 Feb 14 17:36 msdbdata.mdf
-rw-r-----    1 10001    root        524288 Feb 14 17:49 msdblog.ldf
-rw-r-----    1 10001    root       8388608 Feb 14 17:49 tempdb.mdf
-rw-r-----    1 10001    root       8388608 Feb 14 17:55 templog.ldf

如果您仅在上面映射了

mssql

，您将看到数据、日志和机密子目录。

显然，用你的名字替换你的PVC。

再说一次，总而言之，您的 YAML 看起来不错。因此，我怀疑您之前的尝试中残留了一些东西。

我遇到的唯一另一个问题是，有时最好在 PowerShell 中使用单引号，在 cmd 提示符中使用双引号。

您是否检查过您的 Pod 运行正常并且配置读取正常？ （将 pod id 替换为您的）

kubectl get pods
kubectl describe pod mssql-depl-7777487cf7-w9gj5

除此之外......我确信这与之前测试留下的需要清理的内容有关。

为了完整性，下面的原始答案...

您是否尝试过清除所有内容（使用命名空间使这更容易）。

我注意到，如果您使用持久卷声明，master.mdf 可能会保留旧密码（SELECT * FROM master.dbo.syslogins），因为 master.mdf 不会像使用非卷那样重新创建。持续量。

作为一个实验，当我一切正常时，我删除了部署，但保留了持久卷声明。

我删除了 SA_PASSWORD 机密并使用不同的密码重新创建它，然后再次应用部署。

即使新 POD 在环境变量 SA_PASSWORD 中包含新密码，我也能够使用旧密码从 1433 上的 SSMS 连接到 SQL。

总之，我会尝试清除您的持久卷声明并重新开始，以便重新创建 master/msdb 数据库。

值得一试吗？

顺便说一句，NodePort 就是您所需要的，而不是 ClusterIP 和 LoadBalancer（这显然取决于您的集群环境。我猜您使用的是 minikube 或本地 Docker？）

Answer 3

只需确保服务器名称中有“localhost”。参考截图：

• 检查 services.msc > SQLSERVER 服务已关闭。
• 检查“sa”用户的密码