One pill makes you larger
And one pill makes you smallWhite Rabbit, Jefferson Airplane
Nessa segunda publicação vamos começar a colocar na mão na massa! A 1a coisa que devemos fazer é criar os componentes necessários para o deploy do Airflow e a utilização do nó virtual para permitir os escalonamento automático. A ideia geral é construir um cluster K8s pequeno que permita o deploy dos containers do Airflow e um nó virtual para onde serão mandados as tarefas pesadas de ETL e de modelagem.
Sobre Azure
Para quem não conhece (estava em alguma caverna nos últimos 5 anos), o Azure é a nuvem da Microsoft. Nela é possível provisionar de forma simples máquinas virtuais, clusters AKS, e muitas outras coisas. Para saber mais, só dar uma olhada no site deles, o que mais tem por lá é material de documentação para fazer qualquer coisa… menos café que parece que vai ser implementado no próximo ano.
Criação do cluster K8s
Bom para criar um cluster K8s deve-se ter uma conta no Azure e é recomendada a criação de um Resource Group (vou colocar os termos em inglês pq é mais fácil encontrar as documentações). No Resource Group é possível procurar por Kubernets Services e seguir para a implantação.
Para iniciar a configuração é necessário colocar algumas informações básicas como o nome do cluster e o resource group, tem um negócio de “cluster present configuration” ele regula algumas configurações iniciais do cluster, mas no fim vamos mexer em todas… pode deixar como está. Região e zona de disponibilidade fica a critério do freguês, sobre a questão da zona, a sugestão é utilizar apenas uma se não for um sistema que tem que estar 24×7 ou mesmo em dev ainda (sai mais barato e o dinheiro anda bem caro). Sobre a versão do Kubernets, use a padrão a não ser que tenha um motivo muito bom para não fazer isso…
Agora vem algumas configurações um pouco mais interessantes… sobre o tipo de máquina que vamos utilizar para o cluster padrão será uma pequena 8Ram 2 Cores, ela servirá apenas para os containers de funcionamento do K8s, todos os demais containers vamos fazer o deploy em um node separado que vamos chamar de worker. Vamos desabilitar pelo mesmo motivo o escalonamento automático e setar o número de nós para 1.
Na segunda tela, vamos configurar o K8s para criar um outro grupo de instancias que vamos chamar de worker. Nessas instancias será feito o deploy dos containers do Airflow, RabbitMQ, Postgres e outros serviços que serão necessários, para isso basta clicar em “add node poll” e configurar o nó. Um ponto importante na configuração é habilitar os nós virtuais, sem isso o escalonamento automático para as tarefas no Airflow não será possível.
Sobre a configuração dos nó worker onde vamos fazer o deploy de todos os containers que não forem do sistema, não tem muito segredo. Existem apenas algumas configurações mais “pão-duro” que vale a pena habilitar, como impedir o escalonamento automático e reduzir o número de nós para 1 (estamos falando de um sistema de baixa requisição e não essencial… é um teste afinal!). Outra configuração importante é aumentar ao máximo o número total de pods que rodaram dentro de cada node, o número de pods não é um problema e sim o consumo de recursos: é possível fazer o deploy de 200 pods em uma máquina pequena desde que cada pod consuma pouco processamento e memória. Aqui vale gastar um pouco mais na máquina, afinal vai rodar bastante coisa nela.
Uma coisa interessante de fazer é atribuir uma label para o grupo de nós, por exemplo “function: worker” ou coisa do tipo. Dessa forma é possível utilizar critérios de afinidade durante o deploy dos contêineres para direcioná-los para o nós worker e não atrapalhar o nó de processos do sistema.
Na aba de rede, vale a pena habilitar a restrição de IPs para a conexão com a API do K8s. Conectar a API do K8s permite rodar inúmeros comandos que podem expor senhas, credenciais e dados… faz sentido guardar com segurança extra essa API. Ao habilitar essa opção, o usuário desenvolvedor só poderá logar no cluster a partir do IP estabelecido, mesmo a própria interface web deixa de funcinar para abas como workloads, services e outras informações mais detalhadas do cluster.
Houve alguma atualização do Azure, parece que a restrição de IP não conversa mais com os nós virtuais… se não conseguir montar o nó virtual no cluster, remova a restrição de IP do cluster ou crie um novo sem a restrição.
Nessa parte é feita a integração do K8s com o registry e com o Log Analytics. Vale a pena habilitar os dois, um para poder utilizar imagens privadas, que vãos ser essenciais para a construção dos modelos e ETLs e para ter maior observabilidade.
E voilà! Temos o nosso cluster K8s rodando e pronto para receber os nosso contêineres!
Criação do resto das coisas
Fora a criação do cluster, para o correto funcionamento do deploy é necessário disponibilizar discos para a persistência dos dados do Postgres e um IP estático para que seja utilizado no load balancer que irá expor o Airflow para a internet. Uma parte importante que vai facilitar bastante é criar os discos e outros elementos que serão utilizados pelo K8s dentro do resource group que foi criado junto com o AKS. No momento da criação do cluster o Azure automaticamente cria um novo resource group para conter os elementos que compõem o cluster AKS, como rede, máquinas que são utilizadas nos nós, load balancers, etc…
Para criar os discos e o IP estático isso é possível utilizar o próprio az cli e rodar isso no terminal:
################################################### # Criação de um IP estático para servir o Airflow # az network public-ip create \ --resource-group MC_AirflowK8s_AirflowK8sTest_brazilsouth \ --name api_gateway \ --sku Standard \ --allocation-method static
############################################################# # Criação de discos para persistância dos dados do Postgres # # Criando um disco para o Airflow az disk create \ --resource-group MC_AirflowK8s_AirflowK8sTest_brazilsouth \ --name pumpwood--postgres--airflow \ --size-gb 20 \ --location brazilsouth \ --zone 1 \ --query id --output tsv
É necessário (não testei se com a integração do repositório no cluster não precisa…) também a criação de um secrets do K8s para conter as credenciais para baixar as imagens Docker do repositório. Para isso é necessário habilitar o usuário administrador para ser possível logar utilizando usuário e senha. Tem como dar o acesso ao repositório usando IAM… mas me perdi nos passos, de qualquer forma usando o IAM parece mais correto.
Após habilitar o login por usuário de admin, é necessário criar um secret do K8s. Isso pode ser feito através do kubectl com o código abaixo:
az account set --subscription [identificador da conta] az aks get-credentials \ --resource-group [nome do grupo de recurso com o K8s] \ --name [nome do cluster] # assumes ACR Admin Account is enabled export ACR_NAME=airflowk8stest.azurecr.io export ACR_UNAME='[Username do ACR]' export ACR_PASSWD='[Um dos password do ACR]' # Aqui estamos criando um namespace para separar o deploy do airflow # do namespace default, se já existir vai dar um pau... # mas sem problemas kubectl create namespace airflow-test kubectl config set-context --current --namespace=airflow-test # Cria o secret para buscar as imagens no registry kubectl create secret docker-registry dockercfg \ --docker-server=$ACR_NAME \ --docker-username=$ACR_UNAME \ --docker-password=$ACR_PASSWD \ --docker-email=ignorethis@email.com
Para utilizar o secret para baixar as imagens, é possível setar no deployment:
apiVersion : "apps/v1"
kind: Deployment
metadata:
name: simple-airflow--webserver
spec:
replicas: 1
selector:
matchLabels:
type: app
endpoint: airflow
function: webserver
template:
metadata:
labels:
type: app
endpoint: airflow
function: webserver
spec:
# Aqui passamos a instrução para o K8s utilizar
# esse secret para baixar a imagem do registry
imagePullSecrets:
- name: dockercfg
[...]Próximos passos
Agora que temos todos os elementos necessários para fazer o deploy vamos seguir para colocar o Airflow no AKS. Nos vemos em breve!
Conheça um pouco mais do jeito Murabei acompanhando nosso perfil no Linkedin.