Megosztás a következőn keresztül:

SQL Server Linux-tárolók üzembe helyezése a Kubernetesen StatefulSets használatával

A következőkre vonatkozik:SQL Server Linux rendszeren

Ez a cikk ajánlott eljárásokat és útmutatást tartalmaz az SQL Server-tárolók Kubernetesen és StatefulSets használatával való futtatásához. Javasoljuk, hogy podonként egy SQL Server-tárolót (példányt) telepítsen a Kubernetesben. Így podonként egy SQL Server-példány van üzembe helyezve a Kubernetes-fürtben.

Hasonlóképpen, az üzembehelyezési szkript ajánlása egy SQL Server-példány üzembe helyezése a replicas értékének 1beállításával. Ha 1 értékként replicas-nél nagyobb számot ad meg, akkor ennyi SQL Server-példányt kap korrelált névvel. Ha például az alábbi szkriptben a szám 2 van hozzárendelve replicasértékeként, akkor két SQL Server-podot helyezne üzembe, mssql-0 és mssql-1 névvel.

Egy másik ok, amiért üzembehelyezési szkriptenként egy SQL Servert ajánlunk, az a konfigurációs értékek, a kiadás, a nyomkövetési jelzők és más beállítások egymástól függetlenül történő módosításának engedélyezése minden üzembe helyezett SQL Server-példány esetében.

Az alábbi példában a StatefulSet számítási feladat nevének meg kell egyeznie a .spec.template.metadata.labels értékkel, amely ebben az esetben mssql. További információ: StatefulSets.

Fontos

A SA_PASSWORD környezeti változó elavult. Használjon inkább MSSQL_SA_PASSWORD.

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mssql # name of the StatefulSet workload, the SQL Server instance name is derived from this. We suggest to keep this name same as the .spec.template.metadata.labels, .spec.selector.matchLabels and .spec.serviceName to avoid confusion.
spec:
 serviceName: "mssql" # serviceName is the name of the service that governs this StatefulSet. This service must exist before the StatefulSet, and is responsible for the network identity of the set.
 replicas: 1 # only one pod, with one SQL Server instance deployed.
 selector:
  matchLabels:
   app: mssql  # this has to be the same as .spec.template.metadata.labels
 template:
  metadata:
   labels:
    app: mssql # this has to be the same as .spec.selector.matchLabels. See <https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/>:
  spec:
   securityContext:
     fsGroup: 10001
   containers:
   - name: mssql # container name within the pod.
     image: mcr.microsoft.com/mssql/server:2022-latest
     ports:
     - containerPort: 1433
       name: tcpsql
     env:
     - name: ACCEPT_EULA
       value: "Y"
     - name: MSSQL_ENABLE_HADR
       value: "1"
     - name: MSSQL_AGENT_ENABLED
       value: "1"
     - name: MSSQL_SA_PASSWORD
       valueFrom:
         secretKeyRef:
          name: mssql
          key: MSSQL_SA_PASSWORD
     volumeMounts:
     - name: mssql
       mountPath: "/var/opt/mssql"
 volumeClaimTemplates:
   - metadata:
      name: mssql
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi

Ha úgy dönt, hogy az SQL Server példány több replikáját is üzembe helyezi ugyanazzal a telepítéssel, ezt a forgatókönyvet a következő szakasz fogja tárgyalni. Ezek azonban különálló független SQL Server-példányok, és nem replikák (ellentétben az SQL Server rendelkezésre állási csoport replikáival).

Válassza ki a számítási feladat típusát

A megfelelő számítási feladat üzembe helyezési típusának kiválasztása nem befolyásolja a teljesítményt, de a StatefulSet identitásmegtartó követelményeket biztosít.

StatefulSet számítási feladatok

Az SQL Server egy adatbázis-alkalmazás, ezért leginkább StatefulSet számítási feladattípusként kell üzembe helyezni. A számítási feladatok StatefulSet-ként való üzembe helyezése olyan funkciókat biztosít, mint az egyedi hálózati azonosítók, az állandó és stabil tárolás stb. Az ilyen típusú számítási feladatokról a Kubernetes dokumentációjában talál további információt.

Amikor több SQL Server tároló-replikát telepít ugyanazzal az YAML telepítési szkripttel, mint egy StatefulSet munkaterhelés, egy fontos paramétert figyelembe kell venni: a podkezelési szabályzatokat, azaz .spec.podManagementPolicy.

Ehhez a beállításhoz két érték használható:

  • OrderedReady: Ez az alapértelmezett érték, és a viselkedés a üzembe helyezési és méretezési garanciákszerint alakul.

  • Párhuzamos: Ez az a másodlagos szabályzat, amely párhuzamosan hozza létre és indítja el a podokat (ebben az esetben az SQL Server-podokat), anélkül, hogy várnia kellene a többi pod létrehozására. Hasonlóképpen, a leállítás során az összes pod párhuzamosan törlődik. Ezt a lehetőséget akkor használhatja, ha egymástól független SQL Server-példányokat helyez üzembe, és nem kíván követni egy sorrendet az SQL Server-példányok elindításához vagy törléséhez.

    apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mssql
spec:
  serviceName: "mssql"
  replicas: 2 # two independent SQL Server instances to be deployed
  podManagementPolicy: Parallel
  selector:
    matchLabels:
      app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      securityContext:
        fsGroup: 10001
      containers:
        - name: mssql
          image: mcr.microsoft.com/mssql/server:2022-latest
          ports:
            - containerPort: 1433
              name: tcpsql
          env:
            - name: ACCEPT_EULA
              value: "Y"
            - name: MSSQL_ENABLE_HADR
              value: "1"
            - name: MSSQL_AGENT_ENABLED
              value: "1"
            - name: MSSQL_SA_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mssql
                  key: MSSQL_SA_PASSWORD
          volumeMounts:
            - name: mssql
              mountPath: "/var/opt/mssql"
  volumeClaimTemplates:
    - metadata:
        name: mssql
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 8Gi

Mivel a Kubernetesben üzembe helyezett SQL Server-podok függetlenek egymástól, Parallel a podManagementPolicyáltalában használt érték.

A következő minta a kubectl get allmintakimenetét mutatja, közvetlenül a podok párhuzamos irányelvvel való létrehozása után.

NAME          READY   STATUS              RESTARTS   AGE
pod/mssql-0   0/1     ContainerCreating   0          4s
pod/mssql-1   0/1     ContainerCreating   0          4s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   201.0.0.1    <none>        443/TCP   61d

NAME                     READY   AGE
statefulset.apps/mssql   1/1     4s

Üzembehelyezési munkaterhek

Az SQL Server központi telepítési típusát használhatja olyan helyzetekben, amikor az SQL Server-tárolókat állapot nélküli adatbázis-alkalmazásként szeretné üzembe helyezni, például ha az adatmegőrzés nem kritikus fontosságú. Néhány ilyen példa tesztelési/minőségbiztosítási vagy CI/CD-célokra szolgál.

Elkülönítés névtereken keresztül

A névterek lehetővé teszik az erőforrások csoportjainak elkülönítését egyetlen Kubernetes-fürtben. A névterekről és azok használatáról további információt névterekcímű témakörben talál.

Az SQL Server szempontjából, ha olyan Kubernetes-fürtön tervezi futtatni az SQL Server-podokat, amely más erőforrásokat is üzemeltet, az SQL Server-podokat a saját névterükben kell futtatnia a könnyű kezelés és felügyelet érdekében. Tegyük fel például, hogy több részleg is ugyanazt a Kubernetes-fürtöt használja, és egy SQL Server-példányt szeretne üzembe helyezni az Értékesítési csapathoz, egy másikat pedig a marketing-csapathoz. Két névteret fog létrehozni sales és marketingnéven, az alábbi példában látható módon:

kubectl create namespace sales
kubectl create namespace marketing

A névterek létrehozásának ellenőrzéséhez futtassa a kubectl get namespaces, és az alábbi kimenethez hasonló lista jelenik meg.

NAME              STATUS   AGE
default           Active   39d
kube-node-lease   Active   39d
kube-public       Active   39d
kube-system       Active   39d
marketing         Active   7s
sales             Active   26m

Most már üzembe helyezheti az SQL Server-tárolókat ezen névterek mindegyikében az alábbi példában látható YAML-minta használatával. Figyelje meg az üzembe helyezési YAML-hez hozzáadott namespace metaadatokat, így az üzembe helyezés összes tárolója és szolgáltatása a sales névtérben lesz üzembe helyezve.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageAccountType: Standard_LRS
  kind: Managed
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mssql-sales
  namespace: sales
  labels:
    app: mssql-sales
spec:
  serviceName: "mssql-sales"
  replicas: 1
  selector:
    matchLabels:
      app: mssql-sales
  template:
    metadata:
      labels:
        app: mssql-sales
    spec:
      securityContext:
        fsGroup: 10001
      containers:
        - name: mssql-sales
          image: mcr.microsoft.com/mssql/server:2022-latest
          ports:
            - containerPort: 1433
              name: tcpsql
          env:
            - name: ACCEPT_EULA
              value: "Y"
            - name: MSSQL_ENABLE_HADR
              value: "1"
            - name: MSSQL_AGENT_ENABLED
              value: "1"
            - name: MSSQL_SA_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mssql
                  key: MSSQL_SA_PASSWORD
          volumeMounts:
            - name: mssql
              mountPath: "/var/opt/mssql"
  volumeClaimTemplates:
    - metadata:
        name: mssql
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 8Gi
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-sales-0
  namespace: sales
spec:
  type: LoadBalancer
  selector:
    statefulset.kubernetes.io/pod-name: mssql-sales-0
  ports:
    - protocol: TCP
      port: 1433
      targetPort: 1433
      name: tcpsql

Az erőforrások megtekintéséhez futtassa a kubectl get all parancsot a megadott névtérrel az erőforrások megtekintéséhez:

kubectl get all -n sales

NAME                READY   STATUS    RESTARTS   AGE
pod/mssql-sales-0   1/1     Running   0          17m

NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/mssql-sales-0   LoadBalancer   10.0.251.120   20.23.79.52   1433:32052/TCP   17m

NAME                           READY   AGE
statefulset.apps/mssql-sales   1/1     17m

A névterek az erőforrások és podok korlátozására is használhatók, a limit tartomány és/vagy az erőforráskvóta szabályzatok alkalmazásával, a névtéren belüli teljes erőforrás-létrehozás kezeléséhez.

Pod szolgáltatásminőségének konfigurálása

Ha több podot helyez üzembe egyetlen Kubernetes-fürtön, az erőforrásokat megfelelően kell megosztania a Kubernetes-fürt hatékony futtatásához. A podokat úgy konfigurálhatja, hogy egy adott szolgáltatásminőséghez (QoS) legyenek hozzárendelve.

A Kubernetes a QoS-osztályokat használja a podok ütemezésével és kizárásával kapcsolatos döntések meghozatalához. További információ a különböző QoS-osztályokról: Podok szolgáltatásminőségének konfigurálása.

Az SQL Server szempontjából azt javasoljuk, hogy az SQL Server-podokat a QoS Guaranteed használatával helyezze üzembe termelési munkaterhelésekhez. Figyelembe véve, hogy egy SQL Server-pod csak egy SQL Server-tárolópéldánysal rendelkezik, amely a pod garantált QoS-jének eléréséhez fut, meg kell adnia a tároló processzor- és memória-kéréseit,, amelyeknek meg kell egyeznie a memória és a processzor korlátaival. Ez biztosítja, hogy a csomópontok biztosítsák és véglegesítsék az üzembe helyezés során megadott szükséges erőforrásokat, és kiszámítható teljesítménnyel rendelkezzenek az SQL Server-podok számára.

Íme egy minta üzembe helyezési YAML, amely egy SQL Server-tárolót helyez üzembe az alapértelmezett névtérben, és mivel az erőforrás-kérelmek nincsenek megadva, de a korlátokat a Garantált szolgáltatásminőség példában szereplő irányelveknek megfelelően határozták meg, azt látjuk, hogy a következő példában létrehozott pod QoS beállítása Guaranteed. Ha nem adja meg az erőforrás-igényeket, a Kubernetes az erőforrás-korlátokat az erőforrás-igényekkel megegyezőnek tekinti.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
     name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Standard_LRS
  kind: Managed
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mssql
 labels:
  app: mssql
spec:
 serviceName: "mssql"
 replicas: 1
 selector:
  matchLabels:
   app: mssql
 template:
  metadata:
   labels:
    app: mssql
  spec:
   securityContext:
     fsGroup: 10001
   containers:
   - name: mssql
     command:
       - /bin/bash
       - -c
       - cp /var/opt/config/mssql.conf /var/opt/mssql/mssql.conf && /opt/mssql/bin/sqlservr
     image: mcr.microsoft.com/mssql/server:2022-latest
     resources:
      limits:
       memory: 2Gi
       cpu: '2'
     ports:
     - containerPort: 1433
     env:
     - name: ACCEPT_EULA
       value: "Y"
     - name: MSSQL_ENABLE_HADR
       value: "1"
     - name: MSSQL_SA_PASSWORD
       valueFrom:
         secretKeyRef:
          name: mssql
          key: MSSQL_SA_PASSWORD
     volumeMounts:
     - name: mssql
       mountPath: "/var/opt/mssql"
     - name: userdata
       mountPath: "/var/opt/mssql/userdata"
     - name: userlog
       mountPath: "/var/opt/mssql/userlog"
     - name: tempdb
       mountPath: "/var/opt/mssql/tempdb"
     - name: mssql-config-volume
       mountPath: "/var/opt/config"
   volumes:
     - name: mssql-config-volume
       configMap:
        name: mssql
 volumeClaimTemplates:
   - metadata:
      name: mssql
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi
   - metadata:
      name: userdata
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi
   - metadata:
      name: userlog
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi
   - metadata:
      name: tempdb
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi

A kubectl describe pod mssql-0 parancs futtatásával megtekintheti a QoS-t Guaranteed, az alábbiakban látható kódrészlethez hasonló kimenettel.

...
QoS Class:                 Guaranteed
Node-Selectors:            <none>
Tolerations:               node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                           node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                           node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
...

Nem éles számítási feladatok esetén, ahol a teljesítmény és a rendelkezésre állás nem prioritás, érdemes lehet a QoS-t Burstable vagy BestEffortértékre állítani.

Rugalmasságú QoS-minta

Egy Burstable YAML-példa definiálásához az erőforrás-kéréseketkell megadnia, nem pedig az erőforrás korlátait; vagy megadhatja a korlátokat, amely magasabb, mint kérések. Az alábbi kód csak az előző példához képest fennálló különbséget mutatja be, egy rugalmas kapacitású számítási feladat meghatározása érdekében.

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mssql
 labels:
  app: mssql
spec:
 serviceName: "mssql"
 replicas: 1
 selector:
  matchLabels:
   app: mssql
 template:
  metadata:
   labels:
    app: mssql
  spec:
   securityContext:
     fsGroup: 10001
   containers:
   - name: mssql
     command:
       - /bin/bash
       - -c
       - cp /var/opt/config/mssql.conf /var/opt/mssql/mssql.conf && /opt/mssql/bin/sqlservr
     image: mcr.microsoft.com/mssql/server:2022-latest
     resources:
      requests:
       memory: 2Gi
       cpu: '2'

A kubectl describe pod mssql-0 parancs futtatásával megtekintheti a QoS-t Burstable, az alábbiakban látható kódrészlethez hasonló kimenettel.

...
QoS Class:                 Burstable
Node-Selectors:            <none>
Tolerations:               node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                           node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                           node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
...

Legjobb erőfeszítés Szolgáltatásminőségi minta (QoS)

Egy BestEffort YAML-példa definiálásához távolítsa el az erőforrás-kéréseket és az erőforrás korlátait. A BestEffort erőfeszítésű QoS lesz, ahogyan az A BestEffort QoS-osztályához hozzárendelt pod létrehozása esetén meghatározásra kerül. A korábbiakhoz hasonlóan a következő kód csak a -példától való eltérést jeleníti meg a számítási feladatok legjobb munkamennyiségének meghatározásához. Ezek a legkevésbé ajánlott lehetőségek az SQL Server-podokhoz, mivel valószínűleg ezek lesznek az elsők, amelyeket le kell zárni erőforrás-versengés esetén. Még tesztelési és minőségbiztosítási forgatókönyvek esetén is javasoljuk, hogy használja a Burstable lehetőséget az SQL Serverhez.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mssql
  labels:
    app: mssql
spec:
  serviceName: "mssql"
  replicas: 1
  selector:
    matchLabels:
      app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      securityContext:
        fsGroup: 10001
      containers:
        - name: mssql
          command:
            - /bin/bash
            - -c
            - cp /var/opt/config/mssql.conf /var/opt/mssql/mssql.conf && /opt/mssql/bin/sqlservr
          image: mcr.microsoft.com/mssql/server:2022-latest
          ports:
            - containerPort: 1433

A kubectl describe pod mssql-0 parancs futtatásával megtekintheti a QoS-t BestEffort, az alábbiakban látható kódrészlethez hasonló kimenettel.

...
QoS Class:                 BestEffort
Node-Selectors:            <none>
Tolerations:               node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                           node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                           node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
...

Memóriakorlátok konfigurálása a vezérlőcsoport (cgroup) v2 használatával

Az SQL Server 2025 (17.x) és az SQL Server 2022 (16.x) CU 20-tól kezdve az SQL Server észleli és tiszteletben tartja a vezérlőcsoport (cgroup) v2 korlátozásait, javítja a teljesítménystabilitást és az erőforrások elkülönítését Docker- és Kubernetes-környezetekben és OpenShift-környezetekben. A vezérlőcsoportok lehetővé teszik a Linux-kernel részletes vezérlését olyan rendszererőforrások felett, mint a CPU és a memória.

A cgroup v2 támogatásával az SQL Server enyhíti a tárolóalapú üzemelő példányokban korábban észlelt memóriakihasználtsági (OOM-) hibákat, különösen a Kubernetes-fürtökön (például AKS v1.25+), ahol a tároló specifikációiban meghatározott memóriakorlátokat nem kényszerítették ki.

A cgroup verziójának ellenőrzése

stat -fc %T /sys/fs/cgroup

Az eredmények a következők:

Result Description
cgroup2fs Cgroup v2-t használ
cgroup A cgroup v1-et használja

Váltás cgroup v2-re

A legegyszerűbb út egy olyan disztribúció kiválasztása, amely a dobozon kívül támogatja a cgroup v2-t.

Ha manuálisan kell váltania, adja hozzá a következő sort a GRUB-konfigurációhoz:

systemd.unified_cgroup_hierarchy=1

Ezután futtassa a következő parancsot a GRUB frissítéséhez:

sudo update-grub

További információt a következő források tartalmaznak:

Kapcsolódó tartalom

  • Last updated on