Azure Load Balancer Change SKU (Basic to Standard)

For increise SLA  I need to change Azure LoadBalancer SKU,

Azure LB Basic don't have SLA, different is for Standard SKU. 

Don't is possibile to change the sku with a upgrade, the only solution is create a new LoadBalancer (Standard)  e  configure it with the configuration of old LoadBalancer (Basic).

Luckily Microsoft have release a procedure for made it. 

https://docs.microsoft.com/en-us/azure/load-balancer/upgrade-basic-standard

We need check if our LoadBalancer is Public or Internal (No Outbound or With Outbound)

For any choose we have a script to use. Very easy. 

What are the steps of the script?

1- Save and change (with new free IPs) the frontend IPs of Basic LoadBalancer (the script support only 5 Frontend IPs, for more IPs you manually pass the IPs)

2- Create a new Standard LoadBalancer with the configuration of basic loadbalancer  (Frontend IP, Probe ecc..)

3- Migrate the backend pool 

In my upgrade we have been  a ten minutes of downtime.

AKS - Aggiornamento in arrivo a inzio Luglio

Come ogni 3 Mesi sono in arrivo degli aggiornamenti per il servio AKS (Azure Kubernetes Services):

• Nuova versione la 1.17  disponibile dal 1 Luglio (Sempre da quella data non saranno più in supporto le versioni 1.14)
• L'annuncio che a breve verranno rilasciati i nodi AKS con ubuntu 18.04 (Una volta rilasciata la nuova versione dei nodi tutti i successivi aggiornamenti di AKS si porteranno dietro anche l'aggiornamento di versione di Ubuntu)

Tutti i dettagli in questo link

AKS upgrade come verificare se dobbiamo aggiornare

Cluster Kubernetes, ormai sappiamo tutti di che cosa stiamo parlando.

Questa tipologia di cluster possiamo trovarla in tanti ambienti.. Cloud o on-prem, su VMware ecc.

Come tutte le infrastrutture si devono però mantenere ed è molto importante tenerle aggiornate ...anche sotto questo aspetto l'idea del “funziona e quindi perchè aggiornarla” è ormai obsoleta.

 

Mi è capitato ultimamente di confrontarmi con la soluzione AKS (Azure Kubernetes Services) ed essendo un servizio PaaS  è necessario rimanere al passo delle versioni che Microsoft rilascia per il suo cloud.

 

Quindi entriamo nel dettaglio:

 

Ogni 3 mesi vengono rilasciate delle versioni minori (La struttura  d[major].[minor].[patch])  e l’attuale 1.16.x è stata rilasciata a Marzo  2020 per cui:

·         La 1.17 mi aspetto che venga rilasciata a Giugno 2020

·         La 1.18 mi aspetto che venga rilasciata a Settembre 2020

Per verificare che versioni sono disponibili nella region su cui abbiamo il nostro cluster  il comando è il seguente:

 

   az aks get -versions --location <Region>  --output table

 

 

 

 

Se ad esempio la nostra infrastruttura è alla versione 1.15.7 e posso verificarlo con il seguente comando:

 

   az aks get-upgrades --resource-group  <Resource Group>  --name <nome del cluster AKS> --output table

 

 

Per la regola del N-2 la nostra versione va fuori supporto a Settembre 2020

 

A settembre come detto esce la 1.18, la regola del N-2 si applicata alla minor e quinti 18-2 = 16  quindi fino alla 1.16  siamo in supporto per quelle precedenti ( per cui la 1.15) siamo fuori supporto.

 

Per aggiornare una infrastruttura AKS  da  una versione fuori supporto a una in supporto.....  bisogna reinstallare il nostro cluster !

 

Connessione SSH nodi del cluster AKS (Azure Kubernetes Services)

###Attenzione per eseguire queste operazione dovete aver già dimestichezza con i comandi KUBECTL###

Per prima cosa devo generare la mia coppia di chiavi (Pubblica e Privata).
Utilizzando il mio Windows System Linux (WLS) con Ubuntu genero le chiavi:

ssh-keygen -m PEM -t rsa -b 4096 -C "azureuser"


Dove azureuser è l'utente standard presente sui nodi AKS, e quindi mi server come promemoria.

Adesso ho la coppia di chiavi nella mia directory /home/localadmin/.ssh/, devo scaricarli sul pc le chiavi create

I prossimi passaggi sono quelli di caricare la chiave sul pubblica sul nodo/i a cui voglio collegarmi e utilizzare la mia chiave privata per la connessione ssh utilizzando un container ponte.

Bene adesso  mi devo collegare via Powershell alla  tenant e alla subscription dove è deployato il mio cluster AKS

Connect-AzAccount -Tenant  <ID del Tenant>

az account set --subscription "<Nome della subscription>"

$CLUSTER_RESOURCE_GROUP=$(az aks show --resource-group <resource group del AKS> --name <nome dell'AKS> --query nodeResourceGroup -o tsv)
az vm list --resource-group $CLUSTER_RESOURCE_GROUP -o table

Verrà visualizzato l'elenco delle su cui caricare la chiave pubblica.


az vm user update --resource-group $CLUSTER_RESOURCE_GROUP --name <nome del nodo> --username azureuser --ssh-key-value C:\temp\QTYK8\id_rsa.pub

il valore --ssh-key-value è dove abbiamo posizionato localmente la chiave pubblica da caricare sul nodo

Installo il container ponte 

kubectl run --generator=run-pod/v1 -it --rm aks-ssh --image=debian


Mi troverò già dentro al container ponte, a questo punto aprire una nuova powershell, effettuare la procedura di logon (Az Connect ecc..)
Copio la chiave privata sul container ponte (che si chiamerà aks-ssh)


kubectl cp .\id_rsa aks-ssh:/root/id_rsa 


Una volta copiata la chiave possiamo tornare alla sessione di powershell in cui siamo già loggati al container aks-ssh
Modificare i permessi al file id_rsa

chmod 06000 /root/id_rsa 

Installare il client SSH nel container.

apt-get update && apt-get install openssh-client -y

Possiamo finalmente loggarci al nostro host AKS per fare le attività richieste (di solito troubleshooting)

ssh -i /root/id_rsa azureuser@<ip del nodo>


Alcune considerazioni:
- Se usciamo dal container ponte AKS-SSH per rientrarci

 kubectl exec -it aks-ssh bash

- Se vogliamo vedere se il nostro pod AKS-SSH è presente

kubectl get pod


- L'indirizzo IP del nodo lo posso recuperare dal portale azure

Upgrade AKS

Nei prossimi giorni ....Upgrade AKS

https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster