Estratégias de implantação canary e blue-green para SAS Viya®

Conheça alguns conceitos e estratégias para implantação de soluções que aproveitam das capacidades da nuvem e de containers com o SAS Container Runtime (SCR)

O SAS, líder global de dados e IA, atua há quase 50 anos no desenvolvimento de soluções analíticas. Há alguns anos, integra suas soluções ao universo open-source e, mais recentemente, vem investindo fortemente na plataforma "cloud native" SAS Viya®.

Quando pensamos no conceito "cloud native", ou seja, aplicações totalmente guiadas para implantação e utilização das capacidades da nuvem, temos alguns pontos e benefícios relevantes a citar:

Utilização de Microsserviços: serviços menores, independentes e responsáveis pela execução de funções pré-estabelecidas que compõem uma solução maior;
Elasticidade: capacidade de expandir ou diminuir a capacidade e uso de recursos dinamicamente com o passar do tempo para atender cargas de trabalho variáveis;
Alta disponibilidade: capacidade de manter-se disponível, normalmente através de redundância de serviços e/ou abrangendo diferentes datacenters, zonas e regiões;
Alta resiliência: resistência a falhas ou capacidade de recuperar-se delas sem intervenção humana;
Alta portabilidade: possibilidade de transferir a aplicação para diferentes plataformas e provedores de tecnologia;

Neste artigo, meu objetivo é demonstrar em alto nível alguns conceitos e estratégias utilizadas para implantação de soluções que aproveitem das capacidades em nuvem. Além disso, pretendo traçar um paralelo com uma das soluções mais recentes do SAS para execução de modelos e decisões em tempo real (ou batch) utilizando o conceito de "containers": O SAS Container Runtime (SCR).

Sobre o SAS Container Runtime (SCR)

O SAS Container Runtime (SCR) é uma solução compatível com "Open Container Initiative” (OCI), iniciativa aberta com a finalidade de especificar e padronizar as estruturas e formatos de containers e runtimes. A utilização deste padrão permite ao SAS criar imagens de containers utilizando os códigos gerados de modelos e fluxos de decisões a partir das soluções SAS Model Manager e SAS Intelligent Decisioning. A imagem gerada combina arquivos essenciais de sistema, necessários para execução e os códigos dos modelos e decisões desenvolvidos nas soluções SAS.

Esse formato une os benefícios das soluções visuais SAS para desenvolvimento de modelos analíticos complexos e decisões, e a implantação destes mesmos modelos e decisões totalmente isolados e independentes. Desta forma, cria-se uma imagem com tudo que é necessário para processar fora da plataforma SAS. Algumas vantagens deste modelo:

Para cada modelo ou decisão, uma imagem de container SAS Container Runtime (SCR) é criada;
Cada imagem possui todos os componentes e dependências necessárias para processamento do container, incluindo bibliotecas e arquivos necessários do modelo ou fluxo de decisão;
A imagem gerada, em geral, é imutável, ou seja, para substituir por uma nova versão é necessário criar uma nova imagem de container. O ambiente destino pode ser configurado para substituição sem interrupções. Há ainda a possibilidade de substituição do binário da imagem de container publicada através de REST API, porém, com algumas limitações;
Rápida inicialização, pois a imagem de container possui apenas os arquivos essenciais para o correto funcionamento do modelo ou do fluxo de decisão;
Implantação flexível, pois permite que seja implantado em qualquer ambiente que seja compatível com o formato OCI;
Alta escalabilidade, sendo possível orquestração para replicar/escalar os modelos ou fluxos de decisões individualmente dentro do ambiente.

Arquitetura de Referência SAS Viya® + Node Pool Exclusivo SAS Container Runtime (SCR)

Arquitetura de Referência - SAS Viya® + SAS Container Runtime (SCR)

Para este artigo, estou utilizando um ambiente em laboratório implantado na Azure contendo um cluster gerenciado AKS (Azure Kubernetes Service). Esse cluster possui node pools (pool de servidores) conforme abaixo:

stateful: Pool dedicado a serviços e aplicações que necessitem persistir no tempo dados e informações de estado;
stateless: Pool dedicado a serviços e aplicações que não necessitem persistir dados e informações de estado;
compute: Pool dedicado a serviços e motor para processamento utilizando dados principalmente em disco;
cas: Pool dedicado a serviços e motor CAS (Cloud Analytics Services) do SAS. Motor para processamento e armazenamento de dados principalmente em memória;
system: Pool dedicado a serviços de sistema, monitoramento, logging e gerenciamento do cluster;
scr: Pool dedicado a implantação das imagens de containers dos modelos e fluxos de decisão do SAS Container Runtime (SCR);

Em resumo, o ambiente SAS Viya® utilizará para os seus serviços os pools stateful, stateless, compute e cas, os serviços ligados ao AKS, monitoramento e logging utilizarão o pool system, enquanto as imagens de containers geradas do SAS Container Runtime (SCR) serão implantadas no pool scr.

Outros tipos de ambiente podem ser utilizados para implantação das imagens de container do SAS Container Runtime (SCR), como por exemplo servidores Docker privados on-premise, EKS da AWS, GKE do Google, entre outros serviços gerenciados como o Azure Containers. Neste exemplo optei apenas por acrescentar node pool adicional em cluster AKS do laboratório já existente, visando a separação da carga de trabalho.

Outros serviços Azure suportam a implementação, como por exemplo, armazenamento das imagens geradas (Azure Container Registry), autorização e autenticação dos usuários do ambiente SAS (Azure Entra ID), abstração das credenciais utilizadas para autorização entre o cluster AKS e o Container Registry (Azure App Registration).

O ambiente e arquitetura de referência demonstrados aqui não são exclusivos para desenvolvimento dos modelos, fluxos de decisão e uso do SCR. A arquitetura de referência segue um padrão IAC (Infrastructure as Code) do SAS, mas nada impede que as camadas e tipos de máquinas sejam diferentes e inclusive menores.

Desenvolvimento de Fluxo de Decisão Simples e Publicação de Imagem SAS Container Runtime (SCR)

Para demonstrar o conceito de implantação do SAS Container Runtime, desenvolvi um fluxo de decisão simples utilizando o SAS Intelligent Decisioning e apenas um node Python, retornando uma variável decimal - calculada a partir de variáveis de entrada também decimais - e uma variável caractere. A variável caractere possui valor inicial contendo a versão: "Essa versão é a >>> Green <<<" ou "Essa versão é a >>> Blue <<<". Como o foco é demonstrar a implantação, as variáveis servirão apenas para identificarmos mais facilmente a versão por meio da reposta.

SAS Intelligent Decisioning - Fluxo de decisão com node Python simples

Com o fluxo de decisão criado e validado, vamos para a etapa de publicação. Neste exemplo, equivale a gerar a imagem de container do SAS Container Runtime (SCR) a partir do fluxo de decisão que acabamos de desenvolver.

Para esse processo, precisamos vincular um ACR (Azure Container Registry) ao nosso cluster AKS (Azure Kubernetes Service) e incluir algumas permissões para permitir a gravação da imagem no ACR. Precisamos então utilizar um App da Azure (App Registration) que irá abstrair a credencial (client_id e client_secret) e permitirá que o usuário que está publicando o fluxo de decisão/imagem dentro do SAS Viya no AKS possa gravar no ACR.

SAS Intelligent Decisioning - Detalhe janela publicação

Após a configuração ao solicitar a publicação, a imagem de container será gravada no Azure Container Registry (ACR) com as seguintes versões:

Substituirá, caso exista a versão "latest";
Criará uma versão com id sequencial;
Criará uma versão por "tag" preenchida. Nesse caso "Green".

Observação: O processo de publicação também pode ser realizado/automatizado através de API's próprias do SAS em um modelo de pipeline/esteira.

Azure Container Registry (ACR) - Detalhe do repositório e imagens criadas

Com as duas imagens agora publicadas, uma com a versão nomeada "Green" e outra com versão diferente "Blue", podemos seguir para a próxima etapa: a implantação das imagens de container SCR.

Implantação de imagem SAS Container Runtime (SCR)

Para esse exemplo optei por implantar o deployment em um node pool adicional do cluster Azure Kubernetes Services (AKS) já existente. Isso pode ser feito de forma imperativa, utilizando comando k8's "kubectl create deploy ..." ou de forma declarativa, através de um YAML "kubectl apply -f <file>.yaml". Abaixo um exemplo do yaml utilizado:

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: scr-top-decision-green

type: canary

workload.sas.com/class: scr

namespace: scr

spec:

replicas: 1

selector:

matchLabels:

app: scr-top-decision-green

strategy: {}

template:

metadata:

creationTimestamp: null

labels:

app: scr-top-decision-green

type: canary

workload.sas.com/class: scr

spec:

containers:

- image: <acr-name>.azurecr.io/top_decision:Green

imagePullPolicy: Always

ports:

- containerPort: 8080

env:

- name: SAS_SCR_APP_PATH

value: /scr-decisions/top-decision

resources: {}

tolerations:

- effect: NoSchedule

key: workload.sas.com/class

operator: Equal

value: scr

status: {}

Aproveito e compartilho alguns detalhes do YAML que utilizei para criação do deployment:

Variável de ambiente SAS_SCR_APP_PATH para alterar a url a qual ele responderá;
O padrão do SAS Container Runtime é rodar na porta 8080.
Aplicada "tolerations" para forçar que o pod seja agendado para rodar em node "SCR";
Política para sempre recarregar a imagem "Always" apenas para facilitar no exemplo;
Image para obter a imagem publicada a partir do nosso Azure Container Registry;
Label configurada com "type = canary" para demonstrar diferentes cenários de implantação no exemplo;
Opções adicionais são possíveis, incluindo, mas não limitado a configurações de TLS, acesso a recursos externos de bancos de dados, REDIS, customizações de monitoramento e logs, entre outras.

As formas de deployment podem variar dependendo do serviço/tipo de servidor utilizado.

Após o "apply" é possível ver o Deployment e ReplicaSet criados, bem como o pod recém-criado e já rodando.

Obtenho o endereço IP (cluster IP) e realizo uma request POST através de um novo pod "CURL" testando o fluxo de decisão. Na resposta é retornado o valor da variável decimal "Output_Var" e a variável caractere "Version" retornando o valor "Essa versão é a >> Green <<<" conforme esperado:

SAS Container Runtime - K8's Image Deployment

O nosso fluxo de decisão já está implantado (deployment) utilizando a imagem de container na versão GREEN. Agora podemos replicar esse mesmo fluxo de decisão para aumentarmos a capacidade da nossa aplicação. O componente responsável por esse controle, em monitorar o estado pretendido (número x de pods da nossa aplicação rodando de forma saudável) é o ReplicaSet. Assim que realizamos a implantação da aplicação (deployment), ele foi gerado automaticamente no K8's.

Ao executarmos o comando "kubectl scale deployment.apps/scr-top-decision-green --replicas=10" solicitando que ele mantenha 10 réplicas do nosso fluxo de decisão rodando, temos agora 10 pods prontos para receberem tráfego.

SAS Container Runtime - K8's ReplicaSet

Cada POD possui um IP e responderá individualmente pelas requisições que fizermos a ele. Porém precisaremos de um objeto que será responsável por agrupar todos esses pod's/IP's em um mesmo "canal" e, mais do que isso, como precisamos lidar com o ciclo de vida desses pod's - vez ou outra serão substituídos por pod's novos com ips diferentes - utilizaremos um "serviço".

Esse serviço consiste em uma abstração de um grupo de pod's selecionados e agrupados a partir das label's que possuem. Ao efetuar essa seleção, os pod's e seus IP's/endpoints serão agrupados em um mesmo "canal" e as regras para acessá-los geridas por esse serviço. Abaixo você pode conferir o YAML exemplo desse serviço:

apiVersion: v1

kind: Service

metadata:

labels:

app: scr-top-decision-green

namespace: scr

spec:

type: ClusterIP

ports:

- port: 8080

protocol: TCP

selector:

app: scr-top-decision-green

status:

loadBalancer: {}

Com isso em mente e ao aplicarmos o YAML, temos agora:

1 deployment da versão "Green";
1 serviço selecionando e organizando o acesso aos endpoints do nosso fluxo de decisão (1 endpoint por pod e 10 no total);
1 replicaset que monitorará o estado desejado do nosso deployment (nesse momento configurado para 10 réplicas do nosso fluxo de decisão);
10 pod's idênticos contendo o nosso fluxo de decisão.

SAS Container Runtime - Implantação e Componentes K8's

Logo, para ter acesso a toda essa capacidade de trabalho eu só preciso chamar o IP e endpoint do serviço, que ele balanceará entre todos os IP's/endpoints dos 10 pods do nosso fluxo de decisão.

SAS Container Runtime - K8's CURL Service

Resta ainda uma decisão a tomar: o serviço, da forma que configuramos (ClusterIP), é acessível apenas internamente ao cluster AKS e precisaremos dele interagindo com outras aplicações externas. O próprio serviço poderia ser modificado para ser "exposto" para fora do cluster (NodePort ou LoadBalancer por exemplo), entretanto, a ideia para esse desenho é utilizar um outro componente já devidamente configurado a um IP Publico da Azure, o NGINX Ingress Controller. Um novo recurso "ingress" permitirá que o tráfego vindo de fora do cluster seja direcionado ao respectivo serviço que balanceará entre todos os pod's da aplicação.

Nesse caso, o YAML seria algo similar a esse:

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

labels:

namespace: scr

spec:

ingressClassName: "nginx"

rules:

- host: <dnsname>.eastus.cloudapp.azure.com

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

- host: '*.<dnsname>.eastus.cloudapp.azure.com'

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

tls:

- hosts:

- <dnsname>.eastus.cloudapp.azure.com

- '*.<dnsname>.eastus.cloudapp.azure.com'

secretName: sas-ingress-certificate-khkfgbh7dm

status:

loadBalancer:

ingress:

- ip: <IP Address>

Após a aplicação do YAML/criação do recurso Ingress, o endpoint estará acessível de fora do cluster. Com firewalls, quando existentes, links e NSG/Azure configurados corretamente, poderemos testar utilizando outras ferramentas, como o Postman, a partir do nosso chamador ou estação de trabalho. Segue abaixo um exemplo:

SAS Container Runtime - Postman

Após realização dessas etapas, teríamos, resumidamente, os componentes - listados em verde - no namespace scr:

SAS Container Runtime - Green Deployment

Estratégias de implantação Canary e Blue-Green

Faz parte do cotidiano de pipelines CI/CD duas estratégias comuns de implantação, que possuem como principal objetivo reduzir ou até mesmo eliminar por completo indisponibilidades da aplicação durante a liberação de novas versões: Canary e Blue-Green.

As duas estratégias normalmente visam esse objetivo, mas se referem a formas que, embora parecidas, possuem particularidades e cenários distintos. Trago abaixo um detalhamento para ajudá-los a entender um pouco mais.

Estratégia de implantação baseada no Modelo Blue-Green

A estratégia baseada no modelo Blue-Green consiste na implementação em dois "ambientes" idênticos, um chamado Blue e outro Green. Um deles atenderá ao tráfego de produção (Blue) enquanto o outro (Green) é utilizado para testes e validações de versão futura. Quando os testes e validações para a nova versão forem concluídas e os riscos mitigados, todo o tráfego de produção será direcionado para o ambiente Green.

Normalmente, exigem dois ambientes idênticos, ou no mínimo, que possam ser escalados para se obter a mesma capacidade. É possível, entretanto reproduzir esse mesmo comportamento inicialmente a partir do nosso laboratório em uma escala menor para entender o conceito, replicando todos os componentes, tanto para o deployment com a versão "Blue" quanto para versão "Green", mantendo-os independentes, com seus respectivos deployments, pods, replicaset's e serviços. O recurso ingress seria responsável por direcionar o tráfego produtivo para endpoints do deployment ativo (nesse caso o Green), enquanto os testes e validações da versão nova poderiam ser realizados diretamente no serviço da versão Blue. Desta forma teríamos, resumidamente, os componentes abaixo:

SAS Container Runtime - Blue-Green Deployment - Green Ingress

Para o deployment Green estamos utilizando os mesmos YAMLs descritos antes. E logo abaixo os YAML's para o deployment Blue e serviço:

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: scr-top-decision-blue

type: canary

workload.sas.com/class: scr

namespace: scr

spec:

replicas: 1

selector:

matchLabels:

app: scr-top-decision-blue

strategy: {}

template:

metadata:

creationTimestamp: null

labels:

app: scr-top-decision-blue

type: canary

workload.sas.com/class: scr

spec:

containers:

- image: <acr-name>.azurecr.io/top_decision:Blue

imagePullPolicy: Always

ports:

- containerPort: 8080

env:

- name: SAS_SCR_APP_PATH

value: /scr-decisions/top-decision

resources: {}

tolerations:

- effect: NoSchedule

key: workload.sas.com/class

operator: Equal

value: scr

status: {}

apiVersion: v1

kind: Service

metadata:

labels:

app: scr-top-decision-blue

namespace: scr

spec:

type: ClusterIP

ports:

- port: 8080

protocol: TCP

selector:

app: scr-top-decision-blue

status:

loadBalancer: {}

Após validações e testes, quando o objeto ingress for alterado e direcionar para o serviço que engloba os pods da versão Blue, teríamos os componentes abaixo:

SAS Container Runtime - Blue-Green Deployment - Blue Ingress

A alteração do tráfego ocorre quando alteramos o objeto ingress para o sub-item (parte do yaml ingress):

- backend:

service:

para

- backend:

service:

Essa alteração, seja por edição da objeto ingress ou substituição dela, fará com que o tráfego produtivo seja direcionado ao serviço responsável pelos pods e deployment blue. Abaixo a listagem dos componentes presentes no namespace scr:

SAS Container Runtime - Blue-Green Deployment - Green Backend Service Ingress

E logo abaixo os testes para a virada da versão de produção Green integralmente para a versão Blue:

Primeiras requisições retornando a versão "Green":

SAS Container Runtime - Postman Green Response - Green Backend Service Ingress

Requisições subsequentes retornando a versão "Blue":

SAS Container Runtime - Postman Green Response - Blue Backend Service Ingress

Estratégia de implantação baseada no modelo Canary

A estratégia baseada no modelo canary consiste na implementação de novas versões da aplicação (nesse exemplo a versão "Blue" do fluxo de decisão), sendo expostas a uma pequena poção inicial de tráfego, grupo de usuários ou cargas de trabalho.

Com o passar do tempo e aprofundamento dos testes, monitoramento e feedbacks de uso, efetua-se incrementos graduais até a substituição por completo da versão antiga. Podemos iniciar por exemplo com a substituição de um pequeno percentual dos pods que contenham a nova versão (normalmente entre 1% e 10%), o que resultará em um tráfego direcionado nesta mesma proporção.

Enquanto trabalha-se com o percentual reduzido na nova versão, vários testes, feedbacks de usuários e monitoramentos são realizados e qualquer comportamento inesperado fará com que a substituição de pods pare ou recue, até que análises mais detalhadas e correções sejam implementadas para a versão, evitando assim, grandes impactos no negócio.

Após o período de "amadurecimento" da nova versão, já com uma ampla visão dos bugs existentes e correções efetuadas, validações e agora com risco mitigado, substitui-se por completo a versão anterior. Temos então uma nova versão do fluxo de decisão implantada no ambiente, a versão "Blue".

Esse é um modelo de implantação que tende a reduzir custos de infraestrutura pois etapas importantes de testes e validações são realizadas diretamente com parte dos pods e tráfego produtivo.

Mais detalhes sobre o exemplo de implantação Canary

Para trabalharmos com esse cenário, temos algumas alternativas para "gestão deste tráfego". Uma opção é utilizarmos um mesmo objeto ingress e um serviço compartilhado com o seletor apontando para a label "type: canary", que é compartilhada entre as duas versões (Blue e Green), conforme abaixo:

apiVersion: v1

kind: Service

metadata:

namespace: scr

labels:

type: canary

spec:

type: ClusterIP

ports:

- port: 8080

protocol: TCP

selector:

type: canary

status:

loadBalancer: {}

Nesse caso, será necessário remover/alterar o ingress para referenciar o nome do novo serviço e remover os serviços anteriores. Confira o YAML Ingress:

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

labels:

namespace: scr

spec:

ingressClassName: "nginx"

rules:

- host: <dnsname>.eastus.cloudapp.azure.com

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

- host: '*.<dnsname>.eastus.cloudapp.azure.com'

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

tls:

- hosts:

- <dnsname>.eastus.cloudapp.azure.com

- '*.<dnsname>.eastus.cloudapp.azure.com'

secretName: sas-ingress-certificate-khkfgbh7dm

status:

loadBalancer:

ingress:

- ip: <IP Address>

Após removermos/alterarmos o objeto ingress e serviço antigos, teríamos resumidamente a seguinte estrutura:

SAS Container Runtime - Canary Deployment - Tráfego 10% - App Blue

O tráfego para o endpoint "/scr-decisions/top-decision" é recepcionado através no NGINX Ingress Controller, que a partir de objeto ingress criado, encaminhará ao serviço "scr-top-decision-svc". O serviço por sua vez é responsável pelo balanceamento entre os 9 pod's contendo a versão "Green" e 1 pod contendo a versão "Blue". Como reflexo teremos um tráfego equivalente, como é possível notar no teste via Postman. Executei 20 requisições e apenas 2 delas foram direcionadas a versão "Blue".

Postman - Canary Teste

IMPORTANTE: Mesmo com o balanceamento, não é possível assegurar o percentual totalmente. Variações de estado de cada pod podem ocorrer durante o tempo, refletindo consequentemente na distribuição do tráfego. Mantenha sempre um monitoramento preciso da volumetria das requisições e alertas quando desvios inesperados ocorrerem.

Com a realização de monitoramento, testes e feedbacks ao uso do fluxo de decisão para a nova versão ("Blue"), efetuaremos então a substituição gradual das réplicas da versão antiga (Green) de acordo com o percentual de evolução planejado. Nesse caso do exemplo, 10%, 50% e 100% respectivamente:

SAS Container Runtime - Canary Deployment - Tráfego 50% - App Blue

SAS Container Runtime - Canary Deployment - Tráfego 100% - App Blue

Ao término do processo, 100% dos pod's ativos possuirão a nova versão "Blue". O processo então recomeça quando nova versão estiver disponível para implantação.

Realizando o controle de tráfego aprimorado através do NGINX Ingress Controller

Uma alternativa para melhorarmos a assertividade no controle de tráfego e em casos de HPA (Horizontal Pod Autoscaling) implantado - faz com que haja um escalonamento de pod's automaticamente a partir de maior/menor utilização - é a utilização de deployment, serviços, replicasets e ingress independentes e anotações próprias para esses modelos de implantação diretamente no ingress. Alguns exemplos:

nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"

Nesse caso, há um objeto ingress convencional para a versão Green e um segundo objeto ingress, incluindo as duas anotações acima, para a versão Blue. Com esse formato habilitaríamos o controle de tráfego direcionando 10% do tráfego para o Blue, enquanto todo o restante do tráfego excedente (90%) será redirecionado para o Green. É possível fazer o mesmo para o modelo Blue-Green, direcionando para o Blue 100% ou 0%. Seguem exemplos de YAML abaixo:

Ingress Green (YAML):

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

labels:

namespace: scr

spec:

ingressClassName: "nginx"

rules:

- host: <dnsname>.cloudapp.azure.com

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

- host: '*.<dnsname>.eastus.cloudapp.azure.com'

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

tls:

- hosts:

- <dnsname>.eastus.cloudapp.azure.com

- '*.<dnsname>.eastus.cloudapp.azure.com'

secretName: sas-ingress-certificate-khkfgbh7dm

status:

loadBalancer:

ingress:

- ip: <IP Address>

Ingress Blue (YAML):

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

labels:

namespace: scr

annotations:

nginx.ingress.kubernetes.io/canary: "true"

nginx.ingress.kubernetes.io/canary-weight: "50"

spec:

ingressClassName: "nginx"

rules:

- host: <dnsname>.eastus.cloudapp.azure.com

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

- host: '*.<dnsname>.eastus.cloudapp.azure.com'

http:

paths:

- backend:

service:

port:

number: 8080

path: /scr-decisions/top-decision(/|$)(.*)

pathType: Prefix

tls:

- hosts:

- <dnsname>.eastus.cloudapp.azure.com

- '*.<dnsname>.eastus.cloudapp.azure.com'

secretName: sas-ingress-certificate-khkfgbh7dm

status:

loadBalancer:

ingress:

- ip: <IP Address>

Diante da exposição dos cenários acima, notamos uma infinidade de opções possíveis alterando camadas da arquitetura para atender a diferentes propósitos e objetivos de negócio. Outros cenários mais complexos devem ser incentivados, principalmente para ambientes mais robustos, aproveitando da facilidade para provisionamento de clusters entre diferentes zonas, clusters sincronizados entre diferentes regiões geográficas, atendendo regras de proximidades e mantendo alta disponibilidade de aplicações críticas e globais. Agradeço a quem permaneceu até o final e espero que tenham gostado! Quem sabe na próxima oportunidade implementemos cenários mais complexos ou, ainda, totalmente automatizados.