Containers
Kubernetes: o orquestrador, argumentado honestamente
Kubernetes é o orquestrador de contêineres que se tornou o substrato padrão de grande sistema da infraestrutura: implantações, serviços, entrada, PersistentVolumes e uma API que descreve o estado desejado. Também é enorme. O artigo honesto sobre Kubernetes começa com quando não usá-lo e, em seguida, cobre a arquitetura real, as opções de hospedagem (gerenciada versus k3s) e a disciplina de operações que ela exige.
Pontos principais
- O modelo de objeto principal é genuinamente bom: as implantações descrevem o estado de réplica desejado, os serviços fornecem rede estável, configuração separada de ConfigMaps/Secrets e o Ingress atinge o exterior; a reconciliação declarativa (controladores corrigindo desvios) é a arquitetura sobre a qual todo o resto se baseia.
- O peso operacional é real: cada componente do plano de controle (servidor API, etcd, agendador, gerenciador de controlador) precisa de HA e monitoramento; os backups do etcd são a única tarefa nada glamorosa que decide se um cluster é recuperável; e a disciplina de atualização (uma versão secundária por etapa, primeiro os nós canário) é uma obrigação permanente.
- A bifurcação gerenciada versus autogerenciada: controle comercial GKE/EKS/AKS para redução de operações, k3s/microk8s são minidistribuições legítimas para pequenas frotas e mestres de HA autogerenciados continuam sendo um projeto de equipe grande; para uma empresa de hospedagem, k3s em alguns nós geralmente é o limite correto.
- O armazenamento é onde a maioria dos primeiros clusters prejudica: PV/PVC entre as classes de armazenamento em diferentes nuvens diferem, hostPath é uma arma de fogo e classes apoiadas por armazenamento em bloco têm semântica real de IOPS/taxa; planeje classes de armazenamento e estratégia de backup (classe velero) antes da primeira carga de trabalho com estado.
- A rede é sua própria disciplina: opções de CNI (flanela, chita, cílio) sobreposição de controle versus roteamento nativo e política de saída; Ingress (nginx/traefik) mais gerenciador de certificados lida com TLS; as ferramentas de mercado diferem na maturidade da API Gateway; meça antes de escolher.
- O veredicto honesto em nossa categoria de contêineres: adote o Kubernetes quando o agendamento de vários nós, o escalonamento automático e a automação de implantação orientada por API carregam a carga de trabalho; não crie um único servidor WordPress; As distribuições da classe k3s estendem a zona de utilidade, mas os menores clusters honestos ainda custam mais operações do que o compose.
Nota de campo
O cliente que 'precisava do Kubernetes' acabou precisando de exatamente quatro serviços em dois hosts, e k3s trouxe a eles um plano de controle para cuidar do privilégio. Nós os migramos para pilhas de composição simples e seu pager de plantão ficou silencioso. A melhor decisão do Kubernetes geralmente é aquela que você não toma.
Perguntas frequentes
Nossa pequena pilha de hospedagem deve migrar para o Kubernetes?
Provavelmente não: se suas cargas de trabalho são um punhado de serviços em um punhado de hosts, as pilhas compostas ou gerenciadas pelo Podman são mais simples de proteger e monitorar; a recompensa do k8s começa com necessidades de agendamento genuinamente dinâmicas ou automação orientada por API em escala.
GKE, EKS, AKS ou k3s autogerenciados?
Aviões de controle gerenciados trocam controle para atualizações descarregadas; classe k3s para tetos locais e de custo; Kubernetes completo autogerenciado é um projeto especializado e raramente a resposta certa para um perfil de empresa de hospedagem.
Qual é a falha operacional mais comum?
etcd fica sem backup: a expiração do certificado no plano de controle aparece a seguir; trate o backup do cluster (instantâneos do etcd ou velero) como a primeira coisa implantada após o próprio cluster.
Como podemos proteger um cluster de maneira saudável?
Privilégio mínimo de RBAC com funções reais por equipe, políticas de rede que realmente segmentam o tráfego de namespace, varredura de imagens na admissão (ganchos de política de classe trivial) e segredos no cluster tratados por meio de seu gerenciador de segredos externo em vez de YAML bruto.
Como a Kinetikatech ajuda com containers
Para ser honesto, a maioria das equipes chega até nós depois de tentar sozinha primeiro: Management, orchestration and security of containers in production environments. Nosso serviço Gestão de servidores e Segurança de servidores Linux existe para você não precisar aprender containers da forma difícil: cuidamos da configuração, do monitoramento e das surpresas às 3h da manhã.