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.

Azure Load Balancer Change SKU (Basic to Standard)

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 – Aggiornamento in arrivo a inzio Luglio

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 !

 

AKS upgrade come verificare se dobbiamo aggiornare

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:tempQTYK8id_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

Connessione SSH nodi del cluster AKS (Azure Kubernetes Services)