Tag: kubernetes

Topology of IBM Sterling B2B Integration inside RedHat OpenShift Cluster

I usually leave the technical parts for my wiki, but this time I had to add this topology here on the blog. Running Sterling B2B Integrator in a container involves a series of pods, services, and network configurations, which can make management a bit tricky. To organize my understanding of the whole structure, I decided to create a diagram to help visualize the interactions.

Below the diagram:

The diagram I created includes all the components, as well as the critical connections that make everything work in harmony. This proved essential for understanding the topology in a clear and intuitive way.

Leia também:

Distribuições Kubernetes Simples e Pequenas

Tradução e Resumo:

Distribuições Kubernetes Simples e Pequenas para o Edge

Neste artigo descrevo três distribuições Kubernetes compactas para operação em dispositivos de borda (edge) ou em pequenos escritórios. Clusters Kubernetes de produção utilizam vários servidores físicos, mas configurações de nó único também são viáveis, especialmente para desenvolvedores. Há um aumento no uso de dispositivos de borda com ambientes Kubernetes simples.

Essas distribuições permitem gerenciamento centralizado e simplificam o desenvolvimento e testes de aplicações em uma única plataforma: Kubernetes. Exemplos práticos incluem sistemas locais, escritórios isolados, etc.

Distribuições Kubernetes mais potentes como Rancher e OpenShift são difíceis de configurar em um único nó. Assim, fabricantes oferecem distribuições leves para operação em edge, como K3s (SUSE), MicroShift (Red Hat) e MicroK8s (Canonical).

K3s (SUSE):

  • K3s é a versão menor do Rancher Kubernetes Engine, operando com recursos mínimos (1 núcleo de CPU e 512MB de RAM).
  • Dispensa a base de dados etcd, usando SQLite, ideal para operação de nó único.
  • Suporta operação multinó.
  • Usa Traefik para roteamento IP e Flannel para redes virtuais de pods.
  • Armazenamento padrão é o Hostpath, mas pode usar outros provedores.
  • Fácil de instalar em várias distribuições Linux e CPUs ARM64 e x86_64.

MicroShift (Red Hat):

  • Versão leve do OpenShift, requer 1GB de RAM e um núcleo de CPU.
  • Utiliza etcd e outros componentes como OVN e TopoLVM.
  • Instalação depende de pacotes RPM e o gerenciador de pacotes DNF.
  • Integra com o image builder do OSTree, mas depende de produtos comerciais da Red Hat.
  • Ainda em fase de desenvolvimento e documentação desatualizada.

MicroK8s (Canonical):

  • Versão leve do Kubernetes da Canonical, requer 500MB de RAM.
  • Funções agrupadas como add-ons, sem incluir roteador de entrada ou driver de armazenamento por padrão.
  • Usa Dqlite em vez de etcd e containerd em vez de CRI-O.
  • Instalação via Snap, o que complica a depuração.
  • Não suporta SELinux, apenas AppArmor.
  • Ferramentas self-built da Canonical podem ser desvantajosas.

Conclusão:
Todas as três distribuições oferecem Kubernetes compacto para borda ou pequenos escritórios. MicroShift é bem integrado com OSTree mas ainda está ligado a produtos Red Hat. MicroK8s é fácil de começar mas carece de suporte SELinux e utiliza ferramentas internas da Canonical. K3s é flexível, fácil de configurar, suporta SELinux, e utiliza projetos padrão bem mantidos.

Leia também:

Deploy de produtos IBM Sterling simplificado

Implantar múltiplas aplicações em Kubernetes/OpenShift pode ser um desafio. Gerenciar configurações, dependências e ambientes diversos pode transformar o processo em um labirinto de complexidades. No entanto, eu firmemente acredito que o processo de instalação deve ser rápido e simples. Com essa crença em mente, gostaria de apresentar a você o repositório https://github.com/ibm-sterling-devops/ansible-ibm-sterling, uma ferramenta que não só simplifica o deployment na plataforma Linux, mas também oferece suporte para Kubernetes e OpenShift, tornando-se uma solução abrangente para implantações modernas de aplicações.

Apresentando o repositório ansible-ibm-sterling

O ansible-ibm-sterling é um conjunto de playbooks e roles do Ansible projetados para automatizar o deployment de aplicações IBM Sterling. Com suporte para implantações em Kubernetes e OpenShift, ele oferece uma maneira simplificada e eficiente de gerenciar e implantar stacks de aplicações complexas em diversos ambientes.

Benefícios do uso do ansible-ibm-sterling

  1. Instalação Rápida e Simples: O processo de instalação é projetado para ser rápido e direto, alinhando-se com minha crença de que implantar aplicações deve ser livre de complicações.
  2. Automação: Esta ferramenta de deployment via CLI automatiza o processo de implantação, reduzindo a intervenção manual e minimizando erros humanos. Isso acelera o deployment e garante consistência entre os ambientes.
  3. Consistência: Garante deployments consistentes em vários ambientes, incluindo clusters Kubernetes e OpenShift, mantendo a integridade e o comportamento da aplicação.
  4. Escalabilidade: Facilmente escalável para implantar grandes aplicações em múltiplos servidores, ambientes de nuvem ou clusters Kubernetes/OpenShift, graças à arquitetura sem agente do Ansible e ao suporte a Kubernetes/OpenShift.
  5. Flexibilidade: Altamente customizável para adaptar o processo de implantação às suas necessidades específicas. A flexibilidade do Ansible e o suporte a Kubernetes/OpenShift permitem que você ajuste o processo de implantação de acordo com seus requisitos.

Como Começar

Se você está interessado em experimentar o ansible-ibm-sterling com suporte para Kubernetes/OpenShift, você pode encontrar o repositório no GitHub. O repositório contém documentação detalhada, exemplos e scripts para ajudá-lo a começar.

Para começar, siga as instruções em:

https://ibm-sterling-devops.github.io/ansible-ibm-sterling

Leia também:

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: