Jak nakonfigurovat Kubernetes pro průběžnou aktualizaci

Úvod

Průběžné aktualizace jsou důležitou součástí životního cyklu moderní aplikace, přičemž uživatelé neustále očekávají nové funkce a nulové prostoje. Zatímco Kubernetes v minulosti používal k povolení této funkce řadiče replikace, novější verze doporučují používat nasazení.

Tento kurz ukazuje, jak provádět průběžné aktualizace pomocí Kubernetes Deployments. Tato metoda vám umožňuje rychle aktualizovat vaše aplikace a dosáhnout nulových prostojů a zároveň zajistit podporu vrácení.

Předpoklady

• Cluster Kubernetes
• Přístup do okna terminálu
• Nástroj příkazového řádku kubectl

Povolit průběžné aktualizace

Kubernetes Deployments fungují jako obaly kolem ReplicaSets, což jsou řadiče Kubernetes, kteří mají na starosti správu podů. Nasazení poskytují další funkce ReplicaSets – provádějí kontroly stavu, postupné aktualizace a vrácení zpět.

1. Nejprve vytvořte yaml soubor se specifikacemi nasazení pomocí textového editoru, jako je Nano:

nano nginx-test.yaml

Ukázkový soubor níže obsahuje základní deklarace nezbytné pro nasazení Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

        ports:
        - containerPort: 80

2. Uložte a ukončete soubor.

3. Poté vytvořte nasazení pomocí kubectl create příkaz a yaml soubor, který jste právě vytvořili:

kubectl create -f nginx-test.yaml

4. Zkontrolujte rozmístění:

kubectl get deployment

Výstup by měl potvrdit, že je nasazení připraveno:

4. Dále zkontrolujte ReplicaSets spuštěním příkazu:

kubectl get rs

Ukázkový soubor specifikoval čtyři repliky, které se všechny zobrazují jako připravené:

5. Nakonec zkontrolujte, zda jsou lusky nahoře:

kubectl get pod

Výstup zobrazuje moduly jako připravené a spuštěné:

Zajistěte nulový výpadek

Chcete-li nakonfigurovat postupné aktualizace s nulovými prostoji, musíte určit strategii aktualizace.

1. Přidejte následující deklaraci k nasazení yaml soubor pod spec kategorie:

minReadySeconds: 5
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

• minReadySeconds říká Kubernetes, jak dlouho má čekat, než vytvoří další modul. Tato vlastnost zajišťuje, že všechny aplikační moduly jsou během aktualizace ve stavu připravenosti.
• maxSurge určuje maximální počet (nebo procento) podů nad zadaný počet replik. Ve výše uvedeném příkladu bude maximální počet podů 5 od 4 repliky jsou specifikovány v yaml soubor.
• maxUnavailable deklaruje maximální počet (nebo procento) nedostupných modulů během aktualizace. Pokud maxSurge je nastaveno na 0 , toto pole nemůže být 0 .

Přidání výše uvedené specifikace do nasazení yaml soubor stačí k zahájení provádění průběžných aktualizací Kubernetes. Nezaručuje však nulové prostoje. Kubernetes nedokáže říct, kdy je nový pod připravený – odstraní starý pod, jakmile se vytvoří nový. Tento problém způsobuje výpadky, dokud nebude nový modul schopen přijímat požadavky.

K vyřešení tohoto problému nabízí Kubernetes koncept Readiness Probes . Sondy kontrolují stav modulů a umožňují, aby postupné aktualizace pokračovaly pouze tehdy, když jsou všechny kontejnery v modulu připraveny. Pody jsou považovány za připravené, když je sonda připravenosti úspěšná a po době uvedené v minReadySeconds prošlo.

2. Chcete-li nastavit sondy připravenosti, přidejte následující řádky do spec.template.spec kategorie v souboru nasazení:

readinessProbe:
  httpGet:
    path: /
    port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
    successThreshold: 1

• initialDelaySeconds určuje, jak dlouho musí sonda čekat na spuštění po spuštění kontejneru.
• periodSeconds je čas mezi dvěma sondami. Výchozí hodnota je 10 sekund, přičemž minimální hodnota je 1 za druhé.
• successThreshold je minimální počet po sobě jdoucích úspěšných sond po neúspěšné, aby byl celý proces považován za úspěšný. Výchozí i minimální hodnota jsou 1 .

Celý soubor nasazení správně nakonfigurovaný pro průběžné aktualizace by měl vypadat takto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.0

        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            successThreshold: 1
        

3. Uložte soubor a ukončete.

4. Poté použijte kubectl apply aplikujte změny:

kubectl apply -f nginx-text.yaml --record

--record flag poslouží účelu v procesu vrácení zpět.

Výstup ukazuje, že nasazení bylo úspěšně nakonfigurováno.

Provést průběžnou aktualizaci

Existují tři způsoby, jak provádět průběžné aktualizace.

Chcete-li například změnit obrázek aplikace:

Možnost 1:Můžete použít kubectl set pro provedení akce na příkazovém řádku:

kubectl set image deployment nginx-deployment nginx=nginx:1.14.2 --record

Možnost 2:Případně upravte verzi obrázku v spec.templates.spec.containers části yaml soubor. Poté použijte kubectl replace k provedení aktualizace:

kubectl replace -f nginx-test.yaml

Možnost 3:Můžete také použít kubectl edit přímo upravit nasazení:

kubectl edit deployment nginx-deployment --record

Proveďte potřebné změny v editoru, který se otevře:

Změny se použijí, když zavřete editor.

Zkontrolujte stav zavedení

Zkontrolujte stav zavedení nasazení pomocí následující syntaxe:

kubectl rollout status deployment nginx-deployment

Výstup potvrzuje úspěšné zavedení:

Pozastavit a obnovit průběžnou aktualizaci

Pozastavte a obnovte průběžné aktualizace pomocí příslušného kubectl rollout příkazy.

Chcete-li aktualizaci pozastavit, spusťte:

kubectl rollout pause deployment nginx-deployment

Chcete-li aktualizaci obnovit, spusťte:

kubectl rollout resume deployment nginx-deployment

Naplánujte rozmístění modulů

Pomocí vlastností afinity a antiafinity můžete řídit, na kterých uzlech Kubernetes naplánuje konkrétní pody ve vašem nasazení.

Podpornost

Existují dva typy afinity aktuálně dostupné v Kubernetes:

• requiredDuringSchedulingIgnoredDuringExecution říká Kubernetes, aby spouštěl moduly pouze na uzlech, které splňují určitá kritéria, jako je konkrétní typ procesoru.
• preferredDuringSchedulingIgnoredDuringExecution umožňuje spouštění podů jinde, právě tehdy, když žádné uzly nesplňují daná kritéria.

Tyto vlastnosti jsou uvedeny v PodSpec soubor. Pod může být například specifikován takto:

apiVersion: v1
kind: Pod
metadata:
  name: affinity-test
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/test-name
            operator: In
            values:
            - test1
            - test2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: example-node-label-key
            operator: In
            values:
            - example-node-label-value
  containers:
  - name: affinity-test
    image: k8s.gcr.io/pause:2.0

Výše uvedený soubor říká Kubernetes, aby spouštěl pod pouze na uzlu se štítkem, jehož klíč je kubernetes.io/test-name a jehož hodnota je buď test1 nebo test2 . Kromě toho bude Kubernetes preferovat uzly, jejichž klíč je example-node-label-key , s example-node-label-value hodnota.

Pod Anti-Affinity

Afinita k podu je užitečné, pokud nechcete, aby všechny moduly běžely na stejném uzlu. Funguje podobně jako afinita, přičemž jsou k dispozici dva stejné typy – requiredDuringSchedulingIgnoredDuringExecution a preferredDuringSchedulingIgnoredDuringExecution .

Následující příklad specifikuje pravidlo anti-afinity, které říká Kubernetes, aby se přednostně vyhnul plánování „testovacích“ aplikačních podů do uzlů, které již „testovací“ pody mají:

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: 
          - test
      topologyKey: Kubernetes.io/hostname

Vrácení změn

Pokud se v procesu aktualizace něco pokazí, můžete vrátit změny a vrátit se k předchozí verzi aplikace. Chcete-li to provést, použijte následující kubectl rollout příkaz:

kubectl rollout history deployment nginx-deployment

Výstup obsahuje seznam dostupných revizí vytvořených přidáním --record příznak při provádění aktualizace:

Vyberte požadovanou revizi a zadejte následující příkaz pro vrácení změn:

kubectl rollout undo deployment nginx-deployment --to-revision=1

Výše uvedený příkaz se vrátí zpět k revizi 1 a vytvoří následující výstup: