Aula 03 – Kubernates – Arquitetura de Alto Nível
Aula 03 – Kubernates – Arquitetura de Alto Nível
Voltar para página principal do blog
Todas as aulas desse curso
Aula 02 Aula 04
Redes Sociais:
Site das bibliotecas
Tensorflow
Keras
Cursos Gratuitos
Digital Innovation
Quer aprender python3 de graça e com certificado? Acesse então:
workover
Empresas de Cloud:
Hostinger
Digital Ocean
One.com
Canais do Youtube
Toti
Lofi Music Zone Beats
Backing Track / Play-Along
Código Fluente
Putz!
Vocal Techniques and Exercises
Fiquem a vontade para me adicionar ao linkedin.
PIX para doações
Aula 03 – Kubernates – Arquitetura de Alto Nível
Componentes de Baixo Nível (responsáveis pela infraestrutura e execução de contêineres)
Esses são os componentes que lidam com a execução e o gerenciamento eficaz dos contêineres no sistema operacional hospedeiro.
- Container Engine (por exemplo, Docker, Podman, rkt (Rocket), LXC (Linux Containers))
- Container Runtime (por exemplo, containerd, CRI-O, runc, crun)
Componentes de Alto Nível (responsáveis pelo gerenciamento e orquestração de aplicativos)
Esses são os componentes que gerenciam diretamente a implantação, escalabilidade e disponibilidade de aplicativos em contêineres no Kubernetes.
- Kubelet
- Pod
- ReplicaSet
- Deployment
- StatefulSet
- DaemonSet
- Job e CronJob
- Service
- Ingress
- ConfigMap e Secret
- Namespace
Kubelet: é o agente que é executado em cada nó do cluster. Ele gerencia e mantém os contêineres em um pod. Ele garante que os contêineres estejam em execução em um pod e saudáveis, falando diretamente com o containerd, ou CRI-O, que fala com o runc, ou crun, que fala com o kernel do sistema.
Porta 10250.
Pod: Um pod é a menor unidade no Kubernetes e contém um ou mais contêineres. Eles compartilham o mesmo espaço de rede e armazenamento, o que permite que eles se comuniquem facilmente entre si.
Obs: Pod ≠ Container
ReplicaSet: Um ReplicaSet garante que um número especificado de réplicas de um pod esteja em execução em todos os momentos. Se um pod falhar ou for excluído, o ReplicaSet garante que um novo pod seja iniciado para substituí-lo.
Deployment: Um Deployment gerencia a criação e atualização de ReplicaSets e, consequentemente, a criação e atualização dos pods. Ele fornece um mecanismo para implantar e escalar aplicativos de maneira declarativa.
StatefulSet: Semelhante a um Deployment, um StatefulSet gerencia a implantação e atualização de pods. No entanto, ele é usado para aplicativos que possuem estados persistentes, como bancos de dados.
DaemonSet: Um DaemonSet garante que um pod esteja em execução em todos os nós do cluster. Isso é útil para tarefas que precisam ser executadas em todos os nós, como coleta de logs.
Job e CronJob: Jobs são usados para executar trabalhos de curta duração, como processamento em lote. Os CronJobs são usados para agendar tarefas para serem executadas em intervalos regulares.
Service: Um Service define um conjunto de pods e uma política para acessá-los. Ele fornece um endereço IP e um nome DNS para os pods, permitindo a comunicação com os pods independentemente de sua localização ou reinicializações. Tipos mais usados são: NodePort, ClusterIP e LoadBalancer.
Ingress: Um Ingress permite a exposição de serviços HTTP e HTTPS fora do cluster. Ele gerencia as regras de roteamento e os certificados SSL para roteamento baseado em nome de host. Porta 80 (HTTP) e 443 (HTTPS) para expor serviços fora do cluster.
ConfigMap e Secret: ConfigMaps são usados para armazenar configurações não confidenciais, enquanto Secrets são usados para armazenar informações sensíveis, como senhas e chaves de API.
Namespace: Um Namespace é um espaço virtual usado para isolar e organizar os recursos do Kubernetes. Ele ajuda a separar diferentes ambientes, projetos ou equipes dentro do mesmo cluster.
Cluster
Um cluster é um conjunto de máquinas chamadas de nós, onde os contêineres são implantados e executados.
No entanto, o coração do cluster Kubernetes é o Control Plane, um conjunto de componentes cruciais que supervisionam, coordenam e garantem o funcionamento do cluster como um todo.
Então, um cluster Kubernetes é formado por dois tipos principais de nós: nós de trabalho(workers) e o Control Plane(Nó Mestre).
Cada nó de trabalho hospeda os contêineres que executam as aplicações e serviços, enquanto o Control Plane é responsável pela administração centralizada e pelo controle de todo o cluster.
O Control Plane do Kubernetes:
O Control Plane consiste em vários componentes essenciais que desempenham funções específicas para garantir que o cluster funcione conforme o esperado. Aqui estão os principais componentes do Control Plane:
- API Server: Atua como a interface para os usuários e outras partes do sistema. Ele aceita solicitações, valida e processa comandos, e serve como ponto de entrada para interações com o cluster. Porta 6443 (principal interface de comunicação com o cluster Kubernetes).
- etcd: É um armazenamento de chave-valor altamente consistente e altamente disponível que mantém o estado do cluster, incluindo configurações, metadados e outros dados importantes. Portas 2379 e 2380 (para comunicação entre os membros do cluster Etcd).
- Scheduler: É responsável por distribuir os contêineres em execução pelos nós disponíveis no cluster. Ele leva em consideração requisitos de recursos, políticas e outros fatores para tomar decisões de agendamento inteligentes. Porta 10251 (por padrão, mas pode ser configurada)
- Controller Manager: Mantém o estado desejado do sistema, observando continuamente o estado real e tomando medidas para garantir que ele corresponda ao estado esperado. Isso inclui a gestão de replicação, escalonamento e outros aspectos operacionais. Porta 10252 (por padrão, mas pode ser configurada)
- Cloud Controller Manager: Se estiver usando um provedor de nuvem específico, como AWS ou GCP, o Cloud Controller Manager gerencia os recursos da nuvem, como balanceadores de carga e discos persistentes.
Como Funciona o Control Plane?
O Control Plane trabalha em conjunto para garantir a integridade, disponibilidade e escalabilidade do cluster. Ele recebe as solicitações do API Server, mantém o estado atualizado no etcd e age de acordo com as decisões tomadas pelo Scheduler e pelo Controller Manager.
Por exemplo, quando um usuário faz uma solicitação para implantar um novo aplicativo no cluster, o API Server recebe essa solicitação e a encaminha para o Scheduler.
O Scheduler, por sua vez, decide qual nó deve hospedar o novo contêiner com base em vários fatores, como recursos disponíveis e políticas de agendamento.
Uma vez tomada a decisão, o Controller Manager garante que o estado atual do cluster corresponda ao estado desejado, garantindo que o número correto de réplicas seja mantido e que o aplicativo permaneça em execução.
AWS, AZURE… (Kubernates)
Se você usar um serviço de cloud como: Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), etc. Você não precisa se preocupar com o control plane, porque eles gerenciam e se responsabilizam pelo seu cluster, de forma que é uma preocupação a menos que você precisa ter.
Sempre que puder, priorize terceirizar essa preocupação!
Workers
Tem Kubelet, Kube Proxy, Pod e Node Port
O Kube Proxy é, na verdade, um dos componentes de nível mais baixo do Kubernetes, fazendo parte do plano de controle (Control Plane). A faixa de portas 10256-10258 (para várias operações de comunicação).
Ele é executado em cada nó do cluster e desempenha um papel fundamental na camada de rede, facilitando a comunicação entre os pods e serviços.
NodePort
Portas no serviço NodePort são usadas para expor um serviço para o mundo exterior do cluster Kubernetes.
Cada serviço NodePort é mapeado para uma porta específica em todos os nós do cluster, permitindo que o serviço seja acessado por meio do endereço IP de qualquer nó e da porta NodePort especificada.
Porta Padrão do NodePort
Geralmente, as portas NodePort são atribuídas automaticamente dentro da faixa de portas padrão, que é 30000-32767. No entanto, você também pode especificar uma porta NodePort específica ao criar o serviço.
ClusterIP
O serviço ClusterIP expõe o aplicativo apenas internamente dentro do cluster Kubernetes. Ele atribui um IP interno estático ao serviço, que é usado para acessar os pods selecionados pelo serviço. Isso é útil para a comunicação interna entre componentes do aplicativo dentro do cluster.
LoadBalancer
O serviço LoadBalancer expõe um aplicativo para o mundo exterior usando um balanceador de carga externo, como um serviço de nuvem (AWS ELB, Google Cloud Load Balancer, etc.). Ele atribui um IP externo ao serviço e, em seguida, distribui o tráfego de entrada entre os pods selecionados pelo serviço. Isso é especialmente útil quando você precisa distribuir o tráfego de entrada de maneira equilibrada para garantir alta disponibilidade e escalabilidade.
Por essa aula é só, nos vemos na próxima, valeu \o/.
Voltar para página principal do blog
Todas as aulas desse curso
Aula 02 Aula 04
Meu github:
https://github.com/toticavalcanti
Novamente deixo meus link de afiliados:
Hostinger
Digital Ocean
One.com
Obrigado, até a próxima e bons estudos. 😉