Aktualizacja nodów w AKS

Dzisiaj artykuł o aktualizacji systemu na którym działa Azure Kubernetes Service ( AKS ). Nie chodzi o podniesienie wersji AKS tylko o upgrade samych nodów. Microsoft Azure zarządza za nas tak zwanym „Matser Node” instaluje tam najnowsze aktualizacje poprawki itp. Dba o jego bezpieczeństwo a my nie mamy do niego dostępu. Inaczej jest pozostałymi nodami na których są uruchomione nasze kontenery. Azure Kubernetes Service ( AKS ) owszem instaluje na nich poprawki, ale sam nie uruchomi ponownie automatycznie tych węzłów przez co aktualizacja AKS się nie zakończy.

Węzły z systemem Windows Server nie otrzymują codziennie aktualizacji tylko wykonywana jest aktualizacja całego AKS która wdraża nowe węzły z najnowszym obrazem i poprawkami. Informacje na ten temat możesz znaleźć pod adresem https://docs.microsoft.com/pl-pl/azure/aks/use-multiple-node-pools#upgrade-a-node-pool

Ja w artykule zajmę się natomiast  węzłami z systemem Linux, ponieważ częściej ich używam. W tym przypadku można użyć darmowego narzędzia Kured które swoją drogą jest zalecane także przez Microsoft.

AKS jeśli zainstalował aktualizacje i potrzebuje ponownego uruchomienia nodów informuje nas o tym zapisując taką informację w pliku /var/run/reboot-Required

KURED

Usługa Kured którą uruchomimy sprawdza plik /var/run/reboot-Required  i restartuje nody, jeśli jest taka potrzeba. Spokojnie. Można określić, żeby była uruchamiana tylko w określonym czasie. Dzięki temu nie zaskoczy nas niespodziewany restart. Dodatkowo można podpiąć ją do Prometheusa i naszego komunikatora np. Slacka żebyśmy dostali informacje o restartach.

Ja uruchamiam Kured jako DaemonSet.

Na początku dodajemy ServiceAccount, oraz przydzielamy mu uprawnienia i role:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kured
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs:     ["get", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs:     ["list","delete","get"]
- apiGroups: ["apps"]
  resources: ["daemonsets"]
  verbs:     ["get"]
- apiGroups: [""]
  resources: ["pods/eviction"]
  verbs:     ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kured
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kured
subjects:
- kind: ServiceAccount
  name: kured
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: kube-system
  name: kured
rules:
# Allow kured to lock/unlock itself
- apiGroups:     ["apps"]
  resources:     ["daemonsets"]
  resourceNames: ["kured"]
  verbs:         ["update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: kube-system
  name: kured
subjects:
- kind: ServiceAccount
  namespace: kube-system
  name: kured
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kured
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kured
  namespace: kube-system
---

W drugiej części pliku tworzymy DeamonSet z odpowiednią konfiguracją:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kured            
  namespace: kube-system 
spec:
  selector:
    matchLabels:
      name: kured
  updateStrategy:
   type: RollingUpdate
  template:
    metadata:
      labels:
        name: kured
    spec:
      serviceAccountName: kured
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
      hostPID: true 
      restartPolicy: Always
      containers:
        - name: kured
          image: docker.io/weaveworks/kured:1.5.0
          imagePullPolicy: IfNotPresent
          securityContext:
            privileged: true # Give permission to nsenter /proc/1/ns/mnt
          env:
            - name: KURED_NODE_ID
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
          command:
            - /usr/bin/kured
            - --ds-name=kured
            - --ds-namespace=kube-system
            - --reboot-days=mon
            - --reboot-sentinel=/var/run/reboot-required
            - --start-time=2am
            - --end-time=6am
            - --period=0h30m0s
            - --time-zone=Europe/Warsaw
            - --slack-hook-url=https://mattermost.primesoft.pl/hooks/84kbr5kkq3ycbkri1983xxt73w
            - --slack-channel=arthurdoc-gitlab
            - --slack-username=restartk8s
            - --prometheus-url=http://10.7.7.4:9090

Konfiguracja:

• nazwa naszej usługi –ds-name=kured
• namespace w którym jest nasza usługa –ds-namespace=kube-system
• wypisujemy dni w które ma sprawdzać czy potrzebny jest restart –reboot-days=mon
• podajemy ścieżkę do pliku jaki ma sprawdzać –reboot-sentinel=/var/run/reboot-required
• informacja o której godzinie może zacząć –start-time=2am
• informacja o której godzinie ma zakończyć –end-time=6am
• przedział czasu co jaki ma sprawdzać w określonych przez nas godzinach –period=0h30m0s
• strefa czasowa –time-zone=Europe/Warsaw
• adres do naszego weebhoocka –slack-hook-url=https://WKLEJ_WYGENEROWANY_ADRES
• nazwa kanału –slack-channel=PODAJ_NAZWĘ_KANAŁU
• nazwa użytkownika jaka ma się wyświetlać  –slack-username=restartk8s
• adres prometheusa –prometheus-url=http://ADRES_PROMETHEUSA:9090

Powyższe części kodu zapisujemy w pliku YAML i wdrażamy w standardowy sposób np:

kubectl apply -f NAZWA_PLIKU.yaml

Logi odczytujemy w tradycyjny sposób :

kubectl logs NAZWA_KONTENERA -n kube-system

Gdy wszystko dobrze się uruchomi i podacie prawidłową nazwę kontenera to powinniście zobaczyć coś takiego:

Aktualny stan węzłów i informacje o nich otrzymamy uruchamiając polecenie:

kubectl get nodes -o wide

TEST

Jeśli chcecie sprawdzić czy zadziała restart i aktualizacja nodów AKS, to  poprawcie konfiguracje Kured a następnie zalogujcie się na noda i wykonajcie na przykład komendę :

touch /var/run/reboot-required

Maszyny wirtualne(nody), na których są nasze kontenery można znaleźć w grupie zasobów(ResourceGroup) utworzonej automatycznie przy tworzeniu AKS. To ta co zaczyna się zazwyczaj na MC_nazwaAKS… Logujemy się tam jak do zwykłej VM.

Więcej na temat kured znajdziecie na GitHub https://github.com/weaveworks/kured

Więcej artykułów na temat AKS znajdziecie w kategorii Kubernetes.

Azure – Integracja ACR z AKS

K8S – wieczny stan ‘Terminating’