Nota do editor: Hoje temos o sexto de sete episódios de uma série de vídeos e postagens de blog do Google Developer Advocate Sandeep Dinesh sobre como extrair todo o potencial do seu ambiente Kubernetes.
Se você é como a maioria dos usuários do Kubernetes, provavelmente usa serviços externos ao cluster. Por exemplo, talvez você use a Twillio API para enviar mensagens de texto ou quem sabe a Google Cloud Vision API para analisar imagens.
Se seus aplicativos nos seus diversos ambientes se conectam ao mesmo ponto de extremidade externo e você não tem planos para levar o serviço externo ao seu cluster Kubernetes, não tem nenhum problema em usar o ponto de extremidade do serviço externo diretamente no código. Porém, muitas vezes esse não é o caso.
Um bom exemplo disso são os bancos de dados. Embora alguns bancos de dados nativos da nuvem, como o Cloud Firestore ou o Cloud Spanner , usem um único ponto de extremidade para todo o acesso, a maioria dos bancos de dados tem pontos de extremidade separados para cada instância.
Nesse momento, você pode estar pensando que uma boa solução para encontrar o ponto de extremidade seria usar ConfigMaps. É só armazenar o endereço do ponto de extremidade em um ConfigMap e usá-lo no código como uma variável do ambiente. Apesar de essa ser uma solução dar certo, ela tem alguns pontos negativos. Você precisa modificar sua implementação para incluir o ConfigMap e escrever mais código para ler pelas variáveis do ambiente. Mas a questão mais importante é que, se o endereço do ponto de extremidade mudar, você talvez precise reiniciar todos os contêineres ativos para obter o endereço atualizado.
Neste episódio do "Práticas recomendadas para o Kubernetes", vamos ver como usar os mecanismos de descoberta de serviços padrão do Kubernetes para buscar serviços que funcionam fora do cluster exatamente da mesma forma que se faz para serviços de dentro do cluster. Isso dá paridade entre seus ambientes de desenvolvimento e produção, e se você acabar levando o serviço para dentro do cluster, não vai precisar mudar nada no código.
VIDEO
Cenário 1: Banco de dados fora do cluster com endereço IP
Um cenário muito comum é o de hospedar o próprio banco de dados, mas fora do cluster, por exemplo, em uma instância do Google Compute Engine . Isso é muito comum se você executa alguns serviços dentro do Kubernetes e outros fora ou precisa de mais personalização ou controle do que o Kubernetes permite.
Por sorte, existe a possibilidade de transferir todos os serviços para dentro do cluster no futuro, mas você fica em um mundo híbrido até lá. Felizmente, é possível usar os serviços estáticos do Kubernetes para resolver parte dos problemas que isso gera.
Neste exemplo, criei um servidor MongoDB usando o Cloud Launcher . Como ele foi criado na mesma rede (ou VPC) que o cluster do Kubernetes, pode-se acessá-lo usando o endereço IP interno de alto desempenho . No Google Cloud, essa é a configuração padrão, então você não precisa configurar nada de especial.
Agora que temos o endereço IP, o primeiro passo é criar um serviço:
kind: Service
apiVersion: v1
metadata:
name: mongo
Spec:
type: ClusterIP
ports:
- port: 27017
targetPort: 27017
Você provavelmente vai perceber que não existe seletor de pod para esse serviço. O serviço criado não sabe para onde enviar o tráfego. Com isso, você pode criar um objeto "Endpoints" manualmente que receberá tráfego desse serviço.
kind: Endpoints
apiVersion: v1
metadata:
name: mongo
subsets:
- addresses:
- ip: 10.240.0.4
ports:
- port: 27017
Podemos perceber que "Endpoints" define manualmente o endereço IP do banco de dados e usa o mesmo nome do serviço. O Kubernetes usa todos os endereços IP definidos em "Endpoints" como se fossem pods comuns. Agora você pode acessar o banco de dados com uma string de conexão bem simples:
mongodb://mongo
> Não é preciso usar nenhum endereço IP no código! Se o endereço IP mudar no futuro, basta atualizar o "Endpoint" com o novo endereço IP — seus aplicativos não vão precisar mudar nada.
Cenário 2: Banco de dados hospedado remotamente com URI
Se você usa um serviço de banco de dados hospedado de terceiro, é provável que ele forneça a você um URI, ou identificador de recurso unificado, para você estabelecer a conexão com ele. Se você receber um endereço IP, o método do Cenário 1 vai funcionar.
Neste exemplo, tenho dois bancos de dados MongoDB hospedados no mLab . Um deles é o meu banco de dados de desenvolvimento e o outro é o de produção.
As strings de conexão desses bancos de dados são as seguintes:
mongodb://<dbuser>:<dbpassword>@ds149763.mlab.com:49763/dev
mongodb://<dbuser>:<dbpassword>@ds145868.mlab.com:45868/prod
mLab dá um URI dinâmico e uma porta dinâmica, e você pode perceber que ambos são diferentes. Vamos usar o Kubernetes para criar uma camada de abstração com base nessas diferenças. Neste exemplo, vamos conectar ao banco de dados de desenvolvimento.
Você pode criar um serviço "ExternalName" no Kubernetes para ter um serviço estático que redireciona o tráfego ao serviço externo. Esse serviço faz um redirecionamento de CNAME simples no nível do kernel, por isso o impacto no desempenho é mínimo.
O YAML do serviço fica assim:
kind: Service
apiVersion: v1
metadata:
name: mongo
spec:
type: ExternalName
externalName: ds149763.mlab.com
Agora você pode usar uma string de conexão muito mais simples:
mongodb://<dbuser>:<dbpassword>@mongo:<port>/dev
Como "ExternalName" usa redirecionamento de CNAME, não é possível fazer remapeamento de portas. Talvez isso não seja um problema para serviços com portas estáticas, mas infelizmente não é uma boa opção neste exemplo porque a porta é dinâmica. O plano gratuito do mLab dá um número de porta dinâmica, e você não pode mudá-lo. Isso significa que você precisa de strings de conexão diferentes para desenvolvimento e produção.
No entanto, se conseguir o endereço IP, você pode fazer o remapeamento de portas. Vou mostrar como na próxima seção.
Cenário 3: Banco de dados hospedado remotamente com URI e remapeamento de portas
Embora o redirecionamento de CNAME funcione muito bem para serviços com a mesma porta para cada um dos ambientes, ele não é adequado em cenários em que cada ponto de extremidade de cada ambiente usa uma porta. Por sorte, temos alternativas usando algumas ferramentas básicas.
O primeiro passo é pegar o endereço IP do URI.
Se você executar os comandos nslookup, hostname ou ping referenciando o URI, vai obter o endereço IP do banco de dados.
Agora você pode criar um serviço que remapeia a porta do mLab e um ponto de extremidade para esse endereço IP.
kind: Service
apiVersion: v1
metadata:
name: mongo
spec:
ports:
- port: 27017
targetPort: 49763
---
kind: Endpoints
apiVersion: v1
metadata:
name: mongo
subsets:
- addresses:
- ip: 35.188.8.12
ports:
- port: 49763
Observação: o URI pode usar DNS para balancear carga para diversos endereços IP, o que torna esse método arriscado caso os endereços IP mudem! Se você receber diversos endereços IP com o comando acima, basta incluí-los no Endpoints YAML para o Kubernetes balancear a carga de tráfego entre todos eles.
Com isso, você se conecta ao banco de dados remoto sem precisar especificar a porta. O serviço do Kubernetes faz o remapeamento de portas de forma transparente
mongodb://<dbuser>:<dbpassword>@mongo/dev
Conclusão
Mapear serviços externos como internos dá a você a flexibilidade de agregar esses serviços ao cluster no futuro e ainda minimizar os trabalhos de refatoração. Mesmo que você não planeje agregá-los hoje, nunca se sabe o dia de amanhã, não é? Além disso, desse jeito fica bem mais fácil gerenciar e entender que serviços externos sua organização usa.
Se o serviço externo tem um nome de domínio válido e não precisa de remapeamento de portas, usar o tipo de serviço "ExternalName" é um jeito rápido e fácil de mapear o serviço externo como interno. Caso você não tenha um nome de domínio ou precise fazer remapeamento de portas, é só adicionar os endereços IP a um ponto de extremidade e usá-lo.
Você vai à Google Cloud Next18 ? Venha trocar uma ideia comigo e com a equipe do Kubernetes na zona "Meet the Experts"! Espero ver você lá!
2 comentários :
Situs poker online dan agen judi terpercaya capsa365, disini kami memberi kenyamanan dan keamanan dalam bermain supaya anda dapat menghasilkan banyak uang. Permainan di website ini pokerlegendaterbilang cukup mudah seperti poker, domino dan bandar. Dilayani oleh admin-admin profesional karena kepuasan adalah target kami. Situs ini link alternatif pokeronlinecc 2019terbukti sudah masuk 5 besar situs penghasil uang cepat terbaik serta banyak penawaran spesial untuk anda karena disini rajacapsa anda bisa bermain dengan jaminan VIP cukup deposit rendah anda bisa memainkan langsung game pencetak uang asli ini. Kami sudah menambahkan game-game baru yang bisa anda mainkan dengan mudah untuk mempercepat penambahan dana. Mainkan setiap hari dan dapatkan keuntungan lebih dari situs pencari uang kami link alternatif ratucapsa 2019. Slot anda sudah kami persiapkan, selamat bermain dan menjadi kaya.
Situs poker online dan agen judi terpercaya, disini sobatpoker kami memberi kenyamanan dan keamanan dalam bermain supaya anda dapat menghasilkan banyak uang. Permainan di website ini link alternatif ubcpoker 2019 terbilang cukup mudah seperti poker,domino dan bandar. Dilayani oleh admin-admin profesional karena kepuasan adalah target kami. Situs ini wargakartu terbukti sudah masuk 5 besar situs penghasil uang cepat terbaik serta banyak penawaran spesial untuk anda karena disini pokerclub 88 anda bisa bermain dengan jaminan VIP cukup deposit rendah anda bisa memainkan langsung game pencetak uang asli ini link alternatif rajaqq 2019. Kami sudah menambahkan game-game baru yang bisa anda mainkan dengan mudah untuk mempercepat penambahan dana. Mainkan setiap hari dan dapatkan keuntungan lebih dari situs pencari uang kami. Slot anda sudah kami persiapkan, selamat bermain dan menjadi kaya.
Postar um comentário