Azure Red Hat OpenShift: Como provisionar o primeiro cluster
Este é o primeiro de uma série de artigos onde iremos explorar o Azure Red Hat OpenShift, partindo do provisionamento de um cluster, até o deploy automatizado de uma aplicação.
Neste primeiro artigo, vamos entender o que é o Azure Red Hat OpenShift e como ele funciona. Além disso, vamos provisionar na prática o nosso primeiro cluster utilizando a Azure CLI
Pré-requisitos
Para provisionar o ARO utilizando linha de comando, é necessário instalar os seguintes componentes:
A CLI do OpenShift é baseada na CLI do Kubernetes (kubectl), inclusive, é possível logar no OpenShift utilizando o próprio kubectl, porém, a OC (CLI do OpenShift) contém algumas funcionalidades específicas, como o oc new-app.
Para instalar a CLI em Linux:
cd ~
wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-client-linux.tar.gz
mkdir openshift
tar -zxvf openshift-client-linux.tar.gz -C openshift
echo 'export PATH=$PATH:~/openshift' >> ~/.bashrc && source ~/.bashrcPara instalar a CLI no Windows:
- Navegue até a página de downloads do OpenShift no portal da Red Hat
- Selecione a versão desejada
- Clique em Download Now
- Descompacte o arquivo ZIP
- Insira o binário do OC para um diretório e insira este diretório no seu PATH.
Azure Red Hat OpenShift
O Red Hat OpenShift é uma plataforma de Kubernetes enterprise-ready, ou seja, uma “distribuição” do Kubernetes que conta com uma série de operações automatizadas que simplificam e otimizam o desenvolvimento, deploy e o gerenciamento do ciclo de vida de suas aplicações. Além disso, o OpenShift já conta com uma série de ferramentas integradas como operators, como por exemplo, o Tekton para trabalhar com pipelines, o Knative para trabalhar com serveless, e o Istio para Service Mesh. Com isso, ele abstrai a complexidade do Kubernetes, sem que os usuários percam o controle sobre o cluster. Esta plataforma vem sendo adotada pelas maiores empresas devido a simplicidade de trabalhar com ela.
Até agora estamos falando da simplicidade no desenvolvimento e deploy de aplicações, porém, não tocamos em um ponto muito importante: O Gerenciamento da infraestrutura do Red Hat OpenShift. Para isso, temos o Azure Red Hat OpenShift (ARO) que é uma versão do OpenShift gerenciada pela Microsoft em conjunto com a Red Hat.
Como podemos ver na imagem acima, por ser um serviço gerenciado, o usuário foca apenas no ciclo de vida da aplicação, enquanto a Microsoft e a Red Hat focam em toda a infra-estrutura.
Além disso, temos a flexibilidade de utilizar os serviços já integrados ao OpenShift, ou utilizar serviços da Azure, como por exemplo, o Azure Container Registry e o Azure Monitor. Outro ponto muito importante é a possibilidade de utilizar Multi-Availability Zones para os nossos clusters. Dessa forma, podemos melhorar a resiliência do nosso cluster distribuindo os nodes entre 3 zonas de disponibilidade.
Arquitetura interna do ARO
Quando criamos um cluster, não precisamos nos preocupar com a infra-estrutura, e podemos visualizar o cluster no portal como um serviço PaaS.
Em background, este cluster está sendo executado em algum lugar, e, por mais que não seja responsabilidade do usuário, é importante compreender a arquitetura do ARO.
Primeiro, precisamos compreender dois conceitos muito importantes que são os mesmos do Kubernetes: Control Plane e Nodes. O cluster de OpenShift é um conjunto de servidores que possuem os componentes do OpenShift devidamente configurados, ou seja, por trás da plataforma, temos servidores, e estes servidores são chamados de nodes.
Os nodes podem fazer parte do control plane, que é o cérebro do cluster, onde estão localizados os componentes que fazem tudo funcionar, ou então, podem fazer parte do conjunto de máquinas que rodam os workloads(pods, deployments, services), que atualmente são chamadas apenas de nodes.
Tendo isso em mente, quando criamos o ARO, todo o cluster será provisionado dentro de uma rede virtual, onde os Nodes estarão em uma sub-rede, e o control plane em outra, e cada sub-rede possui um load balancer. Todos os recursos são provisionados automaticamente em um Resource Group chamado aro-xxx.
A partir da versão 4.5 do ARO, estes são os principais componentes da arquitetura:
-
aro-worker: Máquinas virtuais que representam os Worker Nodes do cluster, ou seja, onde o nosso workload será executado.
-
aro-master: Máquinas virtuais onde o control plane está funcionando, ou seja, o cérebro do nosso cluster.
-
aro-pls: Private Link utilizado pelos SREs da Microsoft e da Red Hat para gerenciar o cluster.
-
aro-internal: Internal Load Balancer que faz o balanceamento do tráfego de serviços internos, além de realizar a comunicação interna com o API Server e possibilitar a comunicação para que o Control Plane possa acessar o Azure Resource Manager e reportar a saúde do cluster.
-
aro: Public Load Balancer que é utilizado para qualquer tráfego público. Quando criamos uma route para uma aplicação, um front-end ip será configurado neste Load Balancer para o tráfego do Ingress. Ele também cobre a conexão com a internet a partir de qualquer pod dentro do cluster, e também permite a comunicação com o API Server.
-
aro-nsg: Network Security Group que abrange tanto o Control Plane quanto os Worker Nodes. Por parte dos worker nodes, quando expomos um service, a API cria uma regra neste NSG para que o tráfego passe e chegue até os nodes do control plane. Por parte do control plane, a NSG permite que o tráfego entre pela porta 6443 para os nós do control plane.
-
aro Container Registry: Este container registry é apenas read-only e de uso interno, onde as imagens e componentes do cluster são armazenados, como por exemplo, contêineres de logging ou monitoramento. As conexões com este registry ocorrem a partir de um Service Endpoint (logo, é uma conexão interna entre serviços da Azure).
Provisionamento do cluster
Agora vamos ao que interessa:
Preparação do ambiente
Vamos utilizar a CLI do Azure para provisionar o nosso primeiro cluster. Primeiramente, vamos fazer o login:
az login
Após logar em nossa conta, precisamos registrar alguns Resource Providers:
az provider register -n Microsoft.RedHatOpenShift --wait
az provider register -n Microsoft.Compute --wait
az provider register -n Microsoft.Storage --wait
az provider register -n Microsoft.Authorization --wait
az feature register --namespace Microsoft.RedHatOpenShift --name preview
Agora, vamos criar três variáveis de ambiente:
LOCATION=eastus
RESOURCEGROUP=rgAro
CLUSTER=aroExemplo
Após logar no diretório correto e criar as variáveis, é preciso validar se temos cota suficiente no nosso portal para os recursos que serão criados. O OpenShift requer um mínimo de 40 núcleos, e na maioria dos casos, a cota padrão de recursos da Azure pode não atender este requisito. Para resolver isso, basta solicitar um aumento da cota
Para validar se você possui a cota necessária, execute o seguinte comando:
az vm list-usage -l $LOCATION --query "[?contains(name.value, 'standardDSv3Family')]" -o table
Por que o ARO exige esta cota de núcleos? Apesar de ser um serviço gerenciado, quando criamos o nosso cluster, ele cria uma série de recursos em nossa subscription, dentre eles, as Máquinas Virtuais que serão utilizadas como control plane e nodes.
Agora, podemos criar um Resource Group para o nosso cluster
az group create --name $RESOURCEGROUP --location $LOCATIONCriação de VNet
O Azure Red Hat OpenShift requer uma rede virtual com duas sub-redes, sendo uma para os nodes do Control Plane, e outra para os nodes. Para criar a VNet:
az network vnet create --resource-group $RESOURCEGROUP --name aro-vnet --address-prefixes 10.0.0.0/22
Agora, vamos criar as duas sub-redes:
az network vnet subnet create --resource-group $RESOURCEGROUP --vnet-name aro-vnet --name master-subnet --address-prefixes 10.0.0.0/23 --service-endpoints Microsoft.ContainerRegistry
az network vnet subnet create --resource-group $RESOURCEGROUP --vnet-name aro-vnet --name worker-subnet --address-prefixes 10.0.2.0/23 --service-endpoints Microsoft.ContainerRegistry
Note que nas duas sub-redes utilizamos o parâmetro –service-endpoints Microsoft.ContainerRegistry. Isso é necessário pois na arquitetura do ARO, é criado um container registry interno em modo read-only. Este Container Registry é utilizado para armazenar as imagens e os componentes internos da plataforma. A conexão com este container registry ocorre através de um service endpoint, que é uma conexão interna entre os serviços da azure.
Vale observar que a faixa de IPs utilizado para as sub-redes pode ser alterada de acordo com a sua necessidade, porém, é necessário garantir que você não terá uma sobreposição de IPs entre as duas sub-redes, e é necessário que estas sub-redes possuam um tamanho mínimo /27.
Por fim, precisamos desabilitar as políticas de private endpoint na sub-rede do control plane. Isso é um requisito para poder acessar e gerenciar o cluster.
az network vnet subnet update --name master-subnet --resource-group $RESOURCEGROUP --vnet-name aro-vnet --disable-private-link-service-network-policies trueObtenção de Red Hat Pull Secret (Opcional)
Com a VNet e as sub-redes devidamente configuradas, o próximo passo é obter um Red Hat Pull Secret. Isso é opcional, porém, o pull secret permite que você acesse imagens dos container registries da Red Hat. O procedimento é bem simples:
Navegue para este link: https://cloud.redhat.com/openshift/install/azure/aro-provisioned e faça o login. Caso você ainda não tenha uma conta da Red Hat, você pode criar uma nova clicando em “Crie uma conta da Red Hat”.
Após logar no portal, basta clicar em Download Pull Secret e copiar o arquivo para a pasta onde você está trabalhando.
Criação do Cluster
Agora podemos criar o nosso cluster:
az aro create --resource-group $RESOURCEGROUP --name $CLUSTER --vnet aro-vnet --master-subnet master-subnet --worker-subnet worker-subnet --pull-secret @pull-secret.txt
Quando executamos o comando az aro create, definimos seu nome, o resource-group em que ele será criado, a vnet que criamos, referenciando qual a sub-rede para o Control Plane e qual a sub-rede dos Nodes, e, de forma opcional, o pull secret que acabamos de obter.
Este processo demora em torno de 30 minutos, e, quando for concluído, veremos 2 resource groups no portal:
O primeiro, é um resource group gerado automaticamente quando provisionamos o OpenShift, e, o segundo, é o resource group que criamos, onde estará localizado o cluster e a vnet.
Por curiosidade, podemos ver o que foi criado no primeiro Resource Group. Para isso, clique no resource-group e selecione a opção Summary View.
Aqui, podemos ver todos os recursos descritos na seção de arquitetura do cluster.
Login no cluster com o Web Console
Temos duas formas de conectar com o nosso cluster: Uma delas, é através da CLI do OpenShift, e a outra, é através do web console.
A Web Console é uma interface que pode ser acessada através do navegador, que pode ser utilizada para visualizar, pesquisar, e gerenciar os recursos do projeto.
Quando criamos um cluster, por padrão, temos o usuário kubeadmin configurado, e podemos utilizar este usuário para o primeiro acesso. Para obter as credenciais do kubeadmin, execute:
az aro list-credentials --name $CLUSTER --resource-group $RESOURCEGROUP
Agora, no Portal da Azure, clique no Resource Group que você criou, e então, clique no Azure Red Hat OpenShift.
Nesta tela você pode visualizar a URL do console em OpenShift Console. Clique na URL e faça o login com as credenciais obtidas, e então, você verá a tela inicial da web console.
Login no cluster com a CLI
Com a CLI do OpenShift, representada pelo comando oc, você pode criar aplicações e gerenciar os projetos do OpenShift a partir de um terminal.
Após instalar a CLI e obter as credenciais do cluster como no passo anterior, precisamos obter a URL da API Server do cluster, que é a API que permite controlar todos os recursos:
apiServer=$(az aro show -g $RESOURCEGROUP -n $CLUSTER --query apiserverProfile.url -o tsv)
Agora, podemos logar utilizando o comando oc login:
oc login $apiServer -u kubeadmin -p <kubeadmin password>
Vamos listar os nodes do cluster para validar que a conexão foi bem sucedida:
oc get nodes
Bônus: Integração do ARO com o Azure Monitor utilizando o Azure Arc-enabled Kubernetes
Atualmente, a maneira recomendada de integrar nosso cluster de ARO com o Container Insights é através do Azure Arc-Enabled Kubernetes. Utilizando o Arc-Enabled Kubernetes, é possível anexar e configurar diversos clusters de Kubernetes ou OpenShifts, mesmo que sejam on-premises na Azure, ou até mesmo em outros provedores de cloud.
Adicionar o cluster no Azure Arc-Enabled Kubernetes
Primeiro, vamos registrar os Resource Providers Necessários:
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
az provider register --namespace Microsoft.ExtendedLocation
Depois, execute o seguinte comando:
oc adm policy add-scc-to-user privileged system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa
Agora, adicione a extensão connectedk8s:
az extension add --name connectedk8s
Feito isso, vamos utilizar a extensão connectedk8s para conectar o cluster criado anteriormente ao Arc-enabled:
az connectedk8s connect --name $CLUSTER --resource-group $RESOURCEGROUP --distribution openshift
Para validar se a conexão foi feita com sucesso, você deve visualizar o seu cluster após executar este comando:
az connectedk8s list --resource-group $RESOURCEGROUP --output table
Para efetuar esta conexão, uma série de agentes são criados em nosso cluster, em um project (namespace) específico chamado azure-arc. Você pode visualizar os pods:
oc get deployments,pods -n azure-arcHabilitar o Azure Container Insights
Primeiro, vamos criar um workspace do Log Analytics:
WORKSPACE_NAME="arologs"
az monitor log-analytics workspace create --resource-group $RESOURCEGROUP --workspace-name $WORKSPACE_NAME
WORKSPACE_ID="$(az monitor log-analytics workspace show -n $WORKSPACE_NAME-g $ARC_RESOURCE_GROUP--query id -o tsv)"
Agora, podemos integrar o cluster com o Azure Monitor:
az k8s-extension create --name azuremonitor-containers --cluster-name $CLUSTER --resource-group $RESOURCEGROUP --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID=$WORKSPACE_IDConclusão
Neste primeiro artigo, entendemos o que é Azure Red Hat OpenShift, como ele funciona, e sua arquitetura, e então, criamos o nosso primeiro cluster. Além disso, também integramos com o Azure Monitor, pois o monitoramento de um cluster é extremamente importante. No próximo artigo, vamos fazer o deploy da nossa primeira aplicação utilizando OpenShift.