Tag: kubernetes

Cluster Kubernetes no VirtualBox usando Vagrant e CentOS

Montei um cluster Kubernetes com 3 nós no VirtualBox, sendo 1 master e 2 workers, usando o Vagrant e rodando o CentOS Linux 7.

Pra melhorar o entendimento do meu ambiente, montei um esquema da rede pra facilitar, veja abaixo:

Na virtual machine temos 2 interfaces de rede:

  • eth0 configurado como NAT e que tem acesso à internet
  • eth1 configurado com host only

O acesso ao cluster através da máquina host é através de uma interface vboxnetN, criado pelo VirtualBox:

  • Master node master.k8s.com com o ip 172.42.42.100 na interface eth1
  • Worker node 1 node1.k8s.com com o ip 172.42.42.101 na interface eth1
  • Worker node 2 node2.k8s.com com o ip 172.42.42.102 na interface eth1

Após você instalar a sua aplicação e expor o serviço, você pode acessar através de um browser, usando as urls https://172.42.42.100:<porta_servico>, https://172.42.42.101:<porta_servico>, https://172.42.42.102:<porta_servico> .

Se você quiser testar ou ver o código fonte, postei no meu GitHub https://github.com/ebasso/kubernetes-vagrant, também mostro como configurar o kubectl para acessar o ambiente. bye.

Leia também:

  • Sem textos relacionados

Expondo a sua aplicação no Kubernetes

Não vou explicar conceitos do Kubernetes, pois não é o meu foco aqui, a idéia é comparar com o modelo tradicional afim de entender melhor o Kubernetes.

Se você precisa expor qualquer serviço executando dentro de um cluster Kubernetes, você deve utilizar o Ingress.

Para explicar de forma rápida o Ingress, montei o seguinte diagrama:

Você deve pensar no Ingress, como um típico Proxy Reverso que colocamos na DMZ, para permitir acesso à sua aplicações que ficam na Intranet. No modelo tradicional usariamos um Apache HTTP server ou um Nginx, pra controlar o tráfego e proteger contra ataques da Internet.

Em um ambiente Java tradicional, teríamos um Load Balancer ou um HTTP Server na frente dos Servidores de Aplicação, mas no Kubernetes temos as figuras do Service e dos PODs, respectivamente.

Adicionei a personagem do Operado de Proxy, que seria do Admin que faz alteração no arquivo .conf. Já no K8s, essa tarefa é executada através do comando kubectl. Podendo usar o linha de comando ou através de um arquivo yaml.

Acredito que tenho deixado mais claro o funcionamento do Ingress. Bye.

Leia também:

  • Sem textos relacionados

Prós e Contras de ter um ou vários Clusters de Kubernetes

Montei uma lista de prós e contras que podem ajudar você e a sua empresa a decidir, sobre a necessidade de ter apenas um ou vários clusters de Kubernetes.

Razões para ter um único cluster:

  1. Reduzir a sobrecarga de configuração, manutenção e administração
  2. Melhor utilização de recursos
  3. Reduzir a latência entre aplicativos em vários clusters
  4. Redução de custos

Neste caso você utiliza Namespaces para poder separar os ambientes, como por exemplo Desenvolvimento, Homologação e Produção.

Razões para ter vários clusters:

  1. Limites de escalabilidade, por exemplo, um cluster Kubernetes tem um limite de nodes, pods, services.
  2. Separação de Desenvolvimento, Homologação e Produção.
  3. Separação para testar uma nova versão do Kubernetes.
  4. Segurança e Conformidade: de acordo com alguns regulamentos, alguns aplicativos devem ser executados em clusters/VPNs separados e diferentes políticas de segurança.
  5. Multi-fornecedor: para se proteger de práticas de Lock-in. Usando de clusters de vários fornecedores.
  6. Nuvem Pública/On Premise: para dividir a carga e o custo.
  7. Regionalidade para latência: executar clusters em diferentes regiões geográficas para reduzir a latência nessas regiões.
  8. Regionalidade para disponibilidade: executar em clusters em diferentes regiões/zonas de disponibilidade para reduzir os danos de um datacenter/região com falha.
  9. Facilitar a cobrança: Isolamento de cluster para facilitar a cobrança.

Leia também: