Category: 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:

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