Cum se face o actualizare Canary la configurația personalizată istio existentă?

Cum se face o actualizare Canary la configurația personalizată istio existentă.

Cerinţă:

• Avem o configurație personalizată existentă a istio 1.7.3 (instalată folosind metoda istoctl și nicio revizuire setată pentru aceasta) pentru AKS 1.18.14.
• Acum trebuie să facem upgrade la istio 1.8 fără timp de nefuncționare sau minim.
• Actualizarea ar trebui să fie mai sigură și nu va distruge mediul nostru de producție în niciun fel.

Cum am instalat actualul mediu personalizat istio:

1) a creat manifest.
     istioctl manifest generate --set profile=default -f /manifests/overlay/overlay.yaml > $HOME/generated-manifest.yaml
2) istio instalat.
     istioctl install --set profile=default -f /manifests/overlay/overlay.yaml
3) Istio verificat față de manifestul implementat.
     istioctl verify-install -f $HOME/generated-manifest.yaml
    

Procesul de actualizare planificat Referinţă

1) Preverificare pentru upgrade.
     istioctl x preverificare

2) exportați configurația curentă utilizată a istio folosind comanda de mai jos într-un fișier yaml.
     kubectl -n istio-system get iop installed-state-install -o yaml > /tmp/iop.yaml

3) Descărcați istio 1.8 binar și extrageți directorul și navigați în director până unde avem versiunea 1.8 istioctl binar.
      cd istio1.8\istioctl1.8

4) din directorul noua versiune istio, creați un nou plan de control pentru istio(1.8) cu setul corect de revizuire și utilizați starea instalată exportată anterior „iop.yaml”.
     ./istioctl1.8 install --set revision=1-8 --set profile=default -f /tmp/iop.yaml
     
Așteptați-vă că va crea un nou plan de control cu ​​configurația existentă costamised și acum vom avea două implementări și servicii de plan de control care rulează unul lângă altul:

      $ kubectl obține pods -n istio-system -l app=istiod
          STAREA NUMELE GATA REINCEPE VARSTA
          istiod-786779888b-p9s5n 1/1 Alergare 0 114m
          istiod-1-7-6956db645c-vwhsk 1/1 Alergare 0 1m   
                              
5) După aceasta, trebuie să schimbăm eticheta existentă a tuturor spațiilor de nume ale clusterului în care trebuie să injectăm containerele proxy istio. Trebuie să eliminați vechea etichetă „istio-injection” și să adăugați eticheta istio.io/rev pentru a indica versiunea canară 1-8.
    $ kubectl label namespace test-ns istio-injection- istio.io/rev=1-8
                       
      Sper că, în acest moment, mediul este stabil și cu configurațiile istio vechi și putem lua decizia asupra aplicațiilor care pot fi repornite pentru a face modificările noului plan de control în funcție de timpul nostru de nefuncționare și este permis să rulăm unele aplicații cu un plan de control mai vechi și altul cu configurații noi pentru planul de control în acest punct.
    de exemplu: kubectl rollout restart deployment -n test-ns (primul) 
         kubectl lansare repornire implementare -n test-ns2 (mai târziu)
         lansarea kubectl repornirea implementării -n test-ns3 (din nou după ceva mai târziu)

6) Odată ce am planificat timpul de nefuncționare și am repornit implementările așa cum ne-am hotărât, confirmați că toate podurile folosesc acum doar injectorul proxy plan de date din versiunea 1.8    
        kubectl obține pods -n test-ns -l istio.io/rev=1-8
                       
7) Pentru a verifica dacă noile poduri din spațiul de nume test-ns folosesc serviciul istiod-canary corespunzător versiunii canary        
        istioctl proxy-status | grep ${pod_name} | awk '{print $7}'

8) După actualizarea atât a planului de control, cât și a planului de date, puteți dezinstala vechiul plan de control
        istioctl x uninstall -f /tmp/iop.yaml.



                       

Trebuie să ștergeți punctele de mai jos înainte de upgrade.

1. Sunt toți pașii pregătiți pentru upgrade-ul de mai sus sunt buni pentru a continua pentru mediul Prod foarte utilizat?
2. Prin exportarea stării instalate iop este suficient pentru a obține toate etapele personalizate pentru a continua upgrade-ul Canary? sau există vreo șansă de a frâna upgrade-ul sau de a pierde vreo setare?
3. Dacă pasul 4 de mai sus va crea planul de control 1.8 istio cu toate personalizările pe care le avem deja fără nicio pauză sau să lipsească ceva?
4. după pasul 4, avem nevoie de vreo configurație suplimentară legată de configurarea serviciului istiod> documentul următor nu este clar despre asta,
5. pentru pasul 5 de mai sus, cum putem identifica toate spațiile de nume, unde avem activată istio-injection și să modificăm doar acele spații de nume și să le lăsăm pe altele așa cum era înainte?
6. Deci, pentru pasul 8 de mai sus, cum să ne asigurăm că dezinstalăm doar avionul de control vechi? trebuie să obținem binarul pentru planul de control vechi, să spunem (1.7 în cazul meu) și să folosim acel binar cu același /tmp/iop.yaml exportat?
7. Nicio idee despre cum să anulați orice probleme s-au întâmplat între ele... înainte sau după ștergerea vechiului plan de control