Open thepip3r opened 4 years ago
yenneferofvengerberg
commented
3 years ago Hi, the issue still persists on k8s 1.20 even after manually upgraded the image paths to ha:2019-latest and server:2019-latest. We have to wait that ha-operator gets upgraded.
Dumh1233
commented
3 years ago Hi, I seem to have the same problem on OpenShift 4.5 and k8s (from version 1.17 to 1.20), looking into the logs of the operator pod it seems that there is a problem with the parsing:
- [sqlservers] ERROR: 2021/03/01 15:12:37 could not process update request: error getting Service ag1: v1.Service: ObjectMeta: v1.ObjectMeta: readObjectFieldAsBytes: expect : after object field, parsing 458 ...:{},"k:{\"... at { "kind": "Service", "apiVersion": "v1", "metadata": { "name": "ag1", "namespace": "ag1", "selfLink": "/api/v1/namespaces/ag1/services/ag1", "uid": "593a771b-6ef4-4d2f-b301-b883a1bb5f39", "resourceVersion": "171794318", "creationTimestamp": "2021-03-01T15:05:59Z", "managedFields": [ { "manager": "mssql-server-k8s-operator", "operation": "Update", "apiVersion": "v1", "time": "2021-03-01T15:05:59Z", "fieldsType": "FieldsV1", "fieldsV1": { "f:spec": { "f:clusterIP": {}, "f:ports": { ".": {}, "k:{\"port\":1433,\"protocol\":\"TCP\"}": { ".": {}, "f:name": {}, "f:port": {}, "f:protocol": {}, "f:targetPort": {} }, "k:{\"port\":5022,\"protocol\":\"TCP\"}": { ".": {}, "f:name": {}, "f:port": {}, "f:protocol": {}, "f:targetPort": {} } }, "f:selector": { ".": {}, "f:ag-service.mssql.microsoft.com/ag1": {} }, "f:sessionAffinity": {}, "f:type": {} } } } ] }, "spec": { "ports": [ { "name": "tds", "protocol": "TCP", "port": 1433, "targetPort": 1433 }, { "name": "dbm", "protocol": "TCP", "port": 5022, "targetPort": 5022 } ], "selector": { "ag-service.mssql.microsoft.com/ag1": "" }, "clusterIP": "None", "type": "ClusterIP", "sessionAffinity": "None" }, "status": { "loadBalancer": {} } }
It seems that it can't parse the backslash near the quotation mark \" as it should in the Config Map ag1 which ruins the parsing of the string.
The owners of this Config Map are: mssql1-3 which I get error 404 (won't exist) when going into them in OpenShift, seems to also be a problem...
Having a problem getting the SQL 2019 HA to deploy on my K8s 1.18
I've built all my configs and currently have:
Status Checks:
kubectl get all --all-namespaces reports:
To the problem: There are a number of articles talking about a SQL2019 HA build. It appears that every single one however, is in the cloud whereas mine is on-prem in a Vsphere env. They appear to be very simple: Run 3 scripts in this order: operator.yaml, sql.yaml, and ag-service.yaml.
My YAML's are based on: https://github.com/microsoft/sql-server-samples/tree/master/samples/features/high%20availability/Kubernetes/sample-manifest-files
For the blogs that actually screenshot the environment afterward, there should be at least 7 pods (1 Operator, 3 SQL Init, 3 SQL). If you look at my aforementioned all --all-namespaces output, I have everything (and in a running state) but no pods other than the running Operator...???
I actually broke the control plane back to a single-node just to try to isolate the logs. /var/log/container/ and /var/log/pod/ contain nothing of value to indicate a problem with storage or any other reason the the Pods are non-existent. It's probably also worth noting that I started using the latest sql2019 label: 2019-latest but when I got the same behavior there, I decided to try to use the old bits since so many blogs are based on CTP 2.1.
I can create PVs and PVCs using the VCP storage provider. I have my Secrets and can see them in the Secrets store.
I'm at a loss as to explain why pods are missing or where to look after checking journalctl, the daemons themselves, and /var/log and I don't see any indication there's even an attempt to create them -- the kubectl apply -f mssql-server2019.yaml that I adapted runs to completion and without error indicating 3 sql objects and 3 sql services get created. But here is the file anyway targeting CTP2.1:
Edit1: kubectl logs -n ag mssql-operator-*
I've looked over my operator and mssql2019.yamls (specifically around the kind: SqlServer, since that seems to be where it's failing) and can't identify any glaring inconsistencies or differences.
I'd like to reiterate that I was originally using the 2019latest bits instead of the CTP2.1. I went back to CTP2.1 since that's what all of the online documentation is referencing (including MS's).
Am being told on StackOverflow that this is a K8s version problem between the 2019 operator and my version of K8s. Is that correct?