Se você for como a maioria das pessoas, provavelmente está usando recursos executados fora do seu cluster. Talvez você use a API Taleo para enviar mensagens de texto ou analisar imagens usando a API Google Cloud Vision.
Se você usa o mesmo endpoint de solicitação do lado do servidor em todos os seus ambientes e não planeja migrar seus servidores para o Kubernetes, é perfeitamente normal ter um endpoint de serviço diretamente no seu código. No entanto, existem muitos outros cenários para o desenvolvimento de eventos. Nesta série de práticas recomendadas do Kubernetes, você aprenderá como usar os mecanismos integrados do Kubernetes para descobrir serviços dentro e fora do cluster.
Um exemplo de serviço externo comum é um banco de dados executado fora de um cluster Kubernetes. Ao contrário dos bancos de dados em nuvem, como Google Cloud Data Store ou Google Cloud Spanner, que usam um único endpoint para todos os acessos, a maioria dos bancos de dados tem endpoints separados para diferentes circunstâncias.
As melhores práticas para usar bancos de dados tradicionais, como MySQL e MongoDB, geralmente significam que você se conecta a diferentes componentes para diferentes ambientes. Você pode ter uma máquina grande para dados de produção e uma máquina menor para o ambiente de teste. Cada um deles terá seu próprio endereço IP ou nome de domínio, mas você provavelmente não desejará alterar seu código ao passar de um ambiente para outro. Portanto, em vez de codificar esses endereços, você pode usar a descoberta de serviço externo baseada em DNS integrada do Kubernetes da mesma forma que os serviços nativos do Kubernetes.
Digamos que você esteja executando um banco de dados MongoDB no Google Compute Engine. Você ficará preso neste mundo híbrido até conseguir transferi-lo para o cluster.
Felizmente, você pode usar serviços estáticos do Kubernetes para tornar sua vida um pouco mais fácil. Neste exemplo, criei um servidor MongoDB usando o Google Cloud Launcher. Por ser criado na mesma rede (ou VPC do cluster Kubernetes), ele é acessado usando um endereço IP interno de alto desempenho.
Esta é a configuração padrão no Google Cloud, então você não precisa configurar nada. Agora que você tem um endereço IP, o primeiro passo é criar um serviço. Você pode perceber que não há seletores de pod para este serviço. Ou seja, criamos um serviço que não saberá para onde enviar o tráfego. Isso permitirá que você crie manualmente um objeto de endpoint que receberá tráfego deste serviço.
O exemplo de código a seguir mostra que os terminais determinam o endereço IP do banco de dados usando o mesmo nome mongo do serviço.
O Kubernetes usará todos os endereços IP para encontrar endpoints como se fossem pods regulares do Kubernetes, então agora você pode acessar o banco de dados com uma string de conexão simples com o nome acima mongodb://mongo. Não há necessidade de usar endereços IP em seu código.
Se os endereços IP mudarem no futuro, você poderá simplesmente atualizar seus endpoints com o novo endereço IP e seus aplicativos não precisarão ser modificados de nenhuma forma adicional.
Se você estiver usando um banco de dados hospedado em um host de terceiros, é provável que os proprietários do host tenham fornecido um URI de identificador uniforme de recursos para conexão. Portanto, se você recebeu um endereço IP, pode simplesmente usar o método anterior. Este exemplo mostra que tenho dois bancos de dados MongoDB hospedados em um host mLab.
Um é o banco de dados do desenvolvedor e o outro é o banco de dados de produção. As strings de conexão para esses bancos de dados são assim - o mLab fornece um URI dinâmico e uma porta dinâmica. Como você pode ver, eles são diferentes.
Para abstrair isso, vamos usar o Kubernetes e conectar-nos ao banco de dados do desenvolvedor. Você pode criar um nome de serviço externo do Kubernetes, que fornecerá um serviço estático que encaminhará o tráfego para o serviço externo.
Este serviço executará encaminhamento CNAME simples no nível do kernel com impacto mínimo no desempenho. Graças a isso você pode usar uma string de conexão mais simples.
Mas como o nome externo usa o encaminhamento CNAME, ele não pode realizar o encaminhamento de porta. Portanto, esta solução só é aplicável a portas estáticas e não pode ser usada com portas dinâmicas. Mas o mLab Free Tier fornece ao usuário um número de porta dinâmico por padrão e você não pode alterá-lo. Isso significa que você precisa de linhas de comando de conexão diferentes para dev e prod. O ruim é que isso exigirá que você codifique o número da porta. Então, como você faz o encaminhamento de porta funcionar?
A primeira etapa é obter o endereço IP do URI. Se você executar nslookup, hostname ou executar ping no URI, poderá obter o endereço IP do banco de dados. Se o serviço retornar vários endereços IP para você, todos esses endereços poderão ser usados nos pontos finais do objeto.
Uma coisa a ter em mente é que os URIs de IP podem mudar sem aviso prévio, tornando seu uso bastante arriscado na produção. Usando esse endereço IP, você pode conectar-se a um banco de dados remoto sem especificar uma porta. Assim, o serviço Kubernetes realiza o encaminhamento de porta de forma bastante transparente.
Mapear ou mapear recursos externos para internos oferece flexibilidade para usar esses serviços dentro do cluster no futuro, ao mesmo tempo que minimiza os esforços de refatoração. Também torna mais fácil gerenciar e fornecer informações sobre quais serviços externos sua empresa usa.
Continuará muito em breve...
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com