Perguntas e Respostas para Entrevista de Kubernetes

Introdução

Bem-vindo a este guia abrangente, projetado para equipá-lo com o conhecimento e a confiança necessários para se destacar em entrevistas de Kubernetes. Quer você esteja apenas começando sua jornada com orquestração de contêineres ou seja um profissional experiente procurando aprofundar sua expertise, este documento fornece uma abordagem estruturada para dominar os conceitos de Kubernetes. Curamos meticulosamente uma ampla variedade de perguntas, abrangendo desde princípios fundamentais e considerações arquitetônicas avançadas até solução de problemas prática, desafios baseados em cenários e questionamentos específicos para desenvolvedores, administradores e engenheiros de DevOps. Prepare-se para aprimorar sua compreensão, refinar suas habilidades de resolução de problemas e navegar com confiança em qualquer entrevista de Kubernetes.

Fundamentos e Conceitos Essenciais do Kubernetes

O que é Kubernetes e para que é utilizado?

Resposta:

Kubernetes é uma plataforma de orquestração de contêineres de código aberto que automatiza a implantação, o escalonamento e o gerenciamento de aplicações conteinerizadas. É utilizado para lidar com as complexidades de execução de aplicações em produção, garantindo alta disponibilidade, escalabilidade e utilização eficiente de recursos.

Explique a diferença entre um Pod e um Container no Kubernetes.

Resposta:

Um container é um pacote de software leve e executável que inclui tudo o que é necessário para executar uma aplicação. Um Pod é a menor unidade implantável no Kubernetes, encapsulando um ou mais contêineres, recursos de armazenamento, um IP de rede único e opções que regem como os contêineres devem ser executados. Todos os contêineres dentro de um Pod compartilham o mesmo namespace de rede e podem se comunicar via localhost.

O que é um Node no Kubernetes?

Resposta:

Um Node é uma máquina de trabalho no Kubernetes, que pode ser uma VM ou uma máquina física. Cada Node contém os componentes necessários para executar Pods, incluindo o Kubelet (agente do master), Kube-proxy (proxy de rede) e um runtime de contêiner (por exemplo, Docker, containerd).

Descreva os principais componentes do Plano de Controle do Kubernetes (Master Node).

Resposta:

O Plano de Controle consiste no Kube-API Server (expõe a API do Kubernetes), etcd (um armazenamento chave-valor consistente e altamente disponível para dados do cluster), Kube-Scheduler (monitora novos Pods e os atribui a Nodes) e Kube-Controller-Manager (executa processos de controller como os controllers de Node, Replication, Endpoint e Service Account).

O que é um Deployment no Kubernetes e para que é utilizado?

Resposta:

Um Deployment é uma abstração de alto nível que gerencia o estado desejado de seus Pods e ReplicaSets. Ele fornece atualizações declarativas para Pods e ReplicaSets, permitindo que você defina quantas réplicas de uma aplicação devem estar em execução e como realizar atualizações (rollouts) ou reverter para versões anteriores.

Como o Kubernetes lida com a rede para os Pods?

Resposta:

O Kubernetes atribui um endereço IP único a cada Pod. Todos os contêineres dentro de um Pod compartilham este IP e podem se comunicar via localhost. Pods em diferentes Nodes podem se comunicar usando um plugin CNI (Container Network Interface), que implementa a sobreposição de rede (network overlay). O Kube-proxy gerencia as regras de rede nos nodes para permitir a descoberta de serviços e o balanceamento de carga.

O que é um Service no Kubernetes e quais são seus tipos?

Resposta:

Um Service é uma forma abstrata de expor uma aplicação em execução em um conjunto de Pods como um serviço de rede. Ele fornece um endereço IP e um nome DNS estáveis para um grupo de Pods. Os tipos comuns incluem ClusterIP (interno ao cluster), NodePort (expõe o serviço em uma porta estática no IP de cada Node) e LoadBalancer (expõe o serviço externamente usando um balanceador de carga do provedor de nuvem).

Explique o propósito de um ReplicaSet.

Resposta:

Um ReplicaSet garante que um número especificado de réplicas de Pods esteja em execução a qualquer momento. Seu propósito principal é manter a estabilidade e a disponibilidade de um conjunto de Pods. Embora você possa usar ReplicaSets diretamente, eles são tipicamente gerenciados por Deployments para recursos mais avançados, como atualizações contínuas (rolling updates).

O que é kubectl e qual sua função principal?

Resposta:

kubectl é a ferramenta de linha de comando para interagir com um cluster Kubernetes. Ela permite que os usuários executem comandos contra clusters Kubernetes, implantem aplicações, inspecionem e gerenciem recursos do cluster e visualizem logs. Ela se comunica com o servidor de API do Kubernetes.

Qual o papel do etcd no Kubernetes?

Resposta:

etcd é um armazenamento chave-valor distribuído, consistente e altamente disponível, usado pelo Kubernetes para armazenar todos os dados do cluster. Isso inclui dados de configuração, informações de estado, metadados e o estado desejado do cluster. Ele atua como a única fonte de verdade para o cluster Kubernetes.

Tópicos Avançados e Arquitetura do Kubernetes

Explique o conceito de um Operator do Kubernetes e dê um exemplo de quando usá-lo.

Resposta:

Um Operator do Kubernetes é um método de empacotar, implantar e gerenciar uma aplicação nativa do Kubernetes. Ele estende a API do Kubernetes para criar, configurar e gerenciar instâncias de aplicações complexas. Você usaria um Operator para aplicações stateful como bancos de dados (por exemplo, Cassandra, MySQL) para automatizar tarefas como backups, atualizações e escalonamento.

Descreva o propósito de uma Custom Resource Definition (CRD) no Kubernetes.

Resposta:

Uma Custom Resource Definition (CRD) permite que você defina seus próprios recursos customizados no Kubernetes, estendendo a API do Kubernetes. Isso permite que você armazene e recupere dados estruturados que o Kubernetes pode gerenciar. CRDs são fundamentais para a construção de Operators e para a definição de objetos específicos de aplicações.

Como o Kubernetes API Server lida com autenticação e autorização para requisições?

Resposta:

O API Server lida com a autenticação através de vários métodos como certificados de cliente, tokens bearer ou tokens de service account. Após a autenticação, a autorização é realizada usando módulos como RBAC (Role-Based Access Control), Node authorization ou ABAC (Attribute-Based Access Control). RBAC é o mais comum, definindo roles com permissões e vinculando-as a usuários ou service accounts.

Qual a diferença entre um DaemonSet e um Deployment no Kubernetes?

Resposta:

Um Deployment gerencia um conjunto de pods idênticos, garantindo que um número desejado de réplicas esteja em execução no cluster, tipicamente para aplicações stateless. Um DaemonSet garante que todos (ou alguns) nodes executem uma cópia de um pod, sendo útil para serviços em nível de cluster como coletores de logs (por exemplo, Fluentd) ou agentes de monitoramento (por exemplo, Node Exporter) que precisam ser executados em cada node.

Explique o conceito de Pod Security Policies (PSPs) e por que elas estão sendo depreciadas.

Resposta:

Pod Security Policies (PSPs) eram um admission controller que aplicava padrões de segurança a pods e contêineres. Elas permitiam que administradores de cluster controlassem aspectos sensíveis à segurança, como modo privilegiado, acesso à rede do host e tipos de volume. PSPs estão sendo depreciadas em favor do Pod Security Admission (PSA) e de engines de política como OPA Gatekeeper, que oferecem controle mais flexível e granular.

Como você alcança alta disponibilidade para o plano de controle do Kubernetes?

Resposta:

Alta disponibilidade para o plano de controle é alcançada executando múltiplas instâncias do API Server, etcd, Controller Manager e Scheduler. O etcd tipicamente é executado como um cluster baseado em quorum (por exemplo, 3 ou 5 nodes). Um balanceador de carga é posicionado na frente dos API Servers para distribuir o tráfego e fornecer failover.

O que é um mutating admission webhook e como ele pode ser usado?

Resposta:

Um mutating admission webhook é um callback HTTP que pode modificar requisições ao servidor de API do Kubernetes antes que elas sejam persistidas. Ele pode injetar contêineres sidecar, adicionar labels/anotações ou definir valores padrão para campos. Por exemplo, ele pode injetar automaticamente um sidecar istio-proxy em pods para integração de service mesh.

Descreva o papel do etcd em um cluster Kubernetes.

Resposta:

O etcd serve como o armazenamento chave-valor consistente e altamente disponível do Kubernetes. Ele armazena todos os dados do cluster, incluindo configuração, estado e metadados para todos os objetos do Kubernetes (pods, deployments, services, etc.). É crítico para a operação do cluster, e sua disponibilidade impacta diretamente a saúde do cluster.

Como o Kubernetes lida com a aplicação de políticas de rede?

Resposta:

As Network Policies do Kubernetes são especificações que definem como grupos de pods podem se comunicar entre si e com endpoints externos. Elas são implementadas por um plugin de rede (CNI) que suporta NetworkPolicy, como Calico, Cilium ou Weave Net. O plugin CNI traduz essas políticas em regras de firewall.

O que são Taints e Tolerations, e como são usados para o agendamento de pods?

Resposta:

Taints são aplicados aos nodes, marcando-os como 'inadequados' para certos pods, a menos que esses pods tenham Tolerations correspondentes. Tolerations são aplicadas aos pods, permitindo que eles sejam agendados em nodes com taint. Este mecanismo é usado para reservar nodes para cargas de trabalho específicas (por exemplo, nodes com GPU) ou para remover pods de nodes não saudáveis.

Perguntas Baseadas em Cenários e Design

Os pods da sua aplicação estão reiniciando frequentemente. Como você diagnosticaria esse problema no Kubernetes?

Resposta:

Eu começaria verificando kubectl describe pod <nome-do-pod> para eventos e status. Em seguida, usaria kubectl logs <nome-do-pod> para revisar os logs da aplicação em busca de erros. Finalmente, inspecionaria kubectl logs <nome-do-pod> -p para os logs de instâncias de contêineres anteriores para entender a causa da falha.

Você precisa implantar uma nova versão da sua aplicação com zero downtime. Como você conseguiria isso no Kubernetes?

Resposta:

Eu usaria uma estratégia RollingUpdate para o Deployment. Isso permite que o Kubernetes substitua gradualmente os pods antigos por novos, garantindo que um número mínimo de pods esteja sempre disponível. Health checks (readiness probes) são cruciais para garantir que os novos pods estejam prontos antes que o tráfego seja roteado para eles.

Descreva um cenário onde você usaria um StatefulSet em vez de um Deployment.

Resposta:

Eu usaria um StatefulSet para aplicações que requerem identificadores de rede estáveis e únicos, armazenamento persistente estável e implantação/escalonamento/exclusão ordenada e graciosa. Exemplos incluem bancos de dados como PostgreSQL ou sistemas distribuídos como Apache Kafka, onde cada réplica precisa de seu próprio volume persistente e hostname previsível.

Seu cluster Kubernetes está ficando sem recursos (CPU/Memória). Que passos você tomaria para diagnosticar e mitigar isso?

Resposta:

Primeiro, eu usaria kubectl top nodes e kubectl top pods para identificar os consumidores de recursos. Em seguida, verificaria as requisições e limites de recursos nos pods para garantir que estejam configurados adequadamente. As etapas de mitigação incluem otimizar o uso de recursos da aplicação, escalar o cluster horizontalmente ou ajustar as requisições/limites de recursos.

Como você exporia uma aplicação web rodando no Kubernetes para a internet de forma segura?

Resposta:

Eu usaria um Service do Kubernetes do tipo LoadBalancer ou NodePort para expor a aplicação dentro do cluster ou para tráfego externo. Para acesso seguro HTTP/HTTPS, eu implantaria um Ingress controller (por exemplo, Nginx Ingress) e definiria recursos Ingress com terminação TLS, frequentemente integrando com Cert-Manager para provisionamento automatizado de certificados.

Você precisa executar um job em lote único que processa dados e depois sai. Qual objeto Kubernetes você usaria?

Resposta:

Eu usaria um objeto Job do Kubernetes. Um Job garante que um número especificado de pods complete suas tarefas com sucesso. Para tarefas recorrentes, eu usaria um CronJob, que cria objetos Job em uma programação definida.

Projete uma estratégia de alta disponibilidade para um microserviço crítico no Kubernetes.

Resposta:

Eu implantaria o microserviço como um Deployment com múltiplas réplicas (por exemplo, 3 ou mais) distribuídas entre diferentes nodes usando regras de anti-afinidade. Eu implementaria probes de readiness e liveness robustas. Para persistência de dados, eu usaria um banco de dados distribuído ou um StatefulSet com volumes persistentes. Finalmente, eu garantiria requisições/limites de recursos adequados e autoscaling.

Como você lidaria com informações sensíveis como chaves de API ou credenciais de banco de dados para suas aplicações no Kubernetes?

Resposta:

Eu usaria Kubernetes Secrets para armazenar informações sensíveis. Esses secrets podem ser montados como arquivos nos pods ou expostos como variáveis de ambiente. Para segurança aprimorada, eu integraria com sistemas externos de gerenciamento de segredos como HashiCorp Vault ou serviços KMS de provedores de nuvem.

Sua aplicação precisa acessar um banco de dados rodando fora do cluster Kubernetes. Como você configuraria isso de forma segura?

Resposta:

Eu criaria um Service do Kubernetes do tipo ExternalName ou um Service headless com Endpoints para representar o banco de dados externo dentro do cluster. Isso permite que os pods resolvam o banco de dados por um nome de serviço do Kubernetes. Políticas de rede seriam usadas para restringir o tráfego de saída apenas ao IP e porta do banco de dados, e as credenciais seriam gerenciadas via Kubernetes Secrets.

Você observa que o tempo de resposta da sua aplicação está aumentando sob carga pesada. Como você escalaria sua aplicação no Kubernetes para lidar com isso?

Resposta:

Eu implementaria o Horizontal Pod Autoscaling (HPA) para o Deployment, configurado para escalar com base na utilização de CPU ou métricas customizadas como requisições por segundo. Isso adiciona automaticamente mais réplicas de pod quando a demanda aumenta. Eu também garantiria que o cluster subjacente tenha capacidade de node suficiente ou implementaria o Cluster Autoscaler.

Perguntas Específicas por Função (Desenvolvedor, Administrador, DevOps)

Desenvolvedor: Como você diagnosticaria um Pod que está preso no estado 'Pending'?

Resposta:

Eu primeiro verificaria kubectl describe pod <nome-do-pod> para eventos que indiquem problemas como recursos insuficientes (CPU/memória), problemas de afinidade/taint de node, ou PersistentVolumeClaims não vinculados. Em seguida, inspecionaria as condições do node e a disponibilidade de recursos usando kubectl describe node <nome-do-node>.

Desenvolvedor: Você precisa implantar uma nova versão da sua aplicação. Qual é a maneira mais segura de fazer isso no Kubernetes para minimizar o downtime?

Resposta:

Eu usaria uma estratégia RollingUpdate para o Deployment. Isso substitui gradualmente os Pods antigos por novos, garantindo disponibilidade contínua. Eu também definiria probes de readiness para garantir que os novos Pods estejam saudáveis antes que o tráfego seja roteado para eles.

Administrador: Um usuário relata que não consegue acessar um serviço rodando no cluster. Que passos você tomaria para diagnosticar o problema?

Resposta:

Eu começaria verificando o kubectl describe service <nome-do-serviço> do Serviço para verificar sua configuração e a prontidão dos endpoints. Em seguida, inspecionaria os Pods que suportam o serviço para verificar sua saúde (kubectl get pods -o wide) e verificaria seus logs em busca de erros na aplicação. Políticas de rede ou regras de firewall também poderiam ser um fator.

Administrador: Como você garante que apenas usuários autorizados possam acessar recursos específicos dentro de um cluster Kubernetes?

Resposta:

Eu implementaria o Controle de Acesso Baseado em Função (RBAC). Isso envolve definir Roles (permissões dentro de um namespace) ou ClusterRoles (permissões em todo o cluster) e, em seguida, vinculá-los a usuários ou service accounts usando RoleBindings ou ClusterRoleBindings.

Administrador: Descreva um cenário onde você usaria uma NetworkPolicy.

Resposta:

Eu usaria uma NetworkPolicy para controlar o fluxo de tráfego entre Pods ou entre Pods e endpoints externos. Por exemplo, para isolar um Pod de banco de dados para que apenas Pods de aplicação específicos possam se conectar a ele, ou para restringir o tráfego de saída de um namespace de desenvolvimento.

DevOps: Como você gerencia secrets (por exemplo, chaves de API, credenciais de banco de dados) de forma segura no Kubernetes?

Resposta:

Embora os Kubernetes Secrets forneçam codificação básica, para segurança real, eu integraria com soluções externas de gerenciamento de segredos como HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault. Essas soluções podem injetar segredos diretamente nos Pods ou usar drivers CSI para montagem dinâmica, evitando armazenar dados sensíveis diretamente no Git.

DevOps: Explique o propósito de um Helm chart e como ele beneficia pipelines de CI/CD.

Resposta:

Um Helm chart é um gerenciador de pacotes para Kubernetes, agrupando todos os recursos necessários do Kubernetes (Deployments, Services, ConfigMaps, etc.) em uma única unidade versionável. Em CI/CD, ele permite implantações consistentes e repetíveis em diferentes ambientes, atualizações/reversões de versão fáceis e parametrização de configurações.

DevOps: Como você implementaria a implantação contínua para uma aplicação de microsserviços no Kubernetes?

Resposta:

Eu usaria uma abordagem GitOps com uma ferramenta como Argo CD ou Flux. Após o código ser mesclado e testado, um pipeline de CI constrói a imagem Docker e atualiza a tag da imagem no manifesto do Kubernetes (por exemplo, em um repositório Git). O operador GitOps então detecta a mudança no Git e a aplica automaticamente ao cluster, garantindo a sincronização do estado desejado.

DevOps: Quais são algumas métricas chave que você monitoraria para um cluster Kubernetes e suas aplicações?

Resposta:

Para o cluster, eu monitoraria a utilização de recursos dos nodes (CPU, memória, disco), a latência do API server e a saúde do etcd. Para as aplicações, as métricas chave incluem uso de CPU/memória dos Pods, taxas de requisição, taxas de erro, latência e métricas de negócios específicas da aplicação. Prometheus e Grafana são ferramentas comuns para isso.

DevOps: Descreva como você lidaria com armazenamento persistente para aplicações stateful no Kubernetes.

Resposta:

Eu usaria PersistentVolumes (PVs) e PersistentVolumeClaims (PVCs). Um PVC solicita armazenamento de um PV, que é provisionado por uma StorageClass. Isso abstrai a infraestrutura de armazenamento subjacente, permitindo que as aplicações solicitem armazenamento sem conhecer seus detalhes, e garante a persistência dos dados mesmo que os Pods sejam reagendados.

Solução de Problemas e Depuração no Kubernetes

Seu pod está preso no estado 'Pending'. Quais são as razões comuns e como você faria a solução de problemas?

Resposta:

Razões comuns incluem recursos insuficientes (CPU/memória), taints/tolerations de node, ou problemas de volume persistente. Eu usaria kubectl describe pod <nome-do-pod> para verificar eventos de falhas de agendamento, requisições de recursos e status de vinculação de volume.

Um pod está no estado 'CrashLoopBackOff'. O que isso indica e como você o depura?

Resposta:

Isso indica que o contêiner dentro do pod está iniciando e falhando repetidamente. Eu primeiro verificaria kubectl logs <nome-do-pod> para erros na aplicação. Se os logs não forem úteis, eu usaria kubectl describe pod <nome-do-pod> para procurar por eventos OOMKilled ou falhas de readiness/liveness probe.

Como você verifica os logs de um contêiner específico dentro de um pod com múltiplos contêineres?

Resposta:

Você pode especificar o nome do contêiner usando o flag -c com kubectl logs. Por exemplo: kubectl logs <nome-do-pod> -c <nome-do-contêiner>. Isso permite isolar os logs de um serviço específico.

Um serviço não é alcançável de fora do cluster. Que passos você tomaria para diagnosticar isso?

Resposta:

Eu verificaria o tipo de serviço (por exemplo, NodePort, LoadBalancer) e seu IP/porta externa. Em seguida, verificaria as regras de firewall, grupos de segurança e políticas de rede. Finalmente, eu verificaria se os seletores do serviço correspondem corretamente aos labels dos pods e se os pods estão rodando e saudáveis.

Você suspeita que uma política de rede está bloqueando o tráfego para sua aplicação. Como você confirmaria isso?

Resposta:

Eu usaria kubectl describe networkpolicy <nome-da-politica> para entender suas regras. Em seguida, verificaria os labels e namespaces do pod para ver se eles são alvo de alguma política. Ferramentas como kube-no-trouble ou netshoot dentro de um pod de depuração também podem ajudar a testar a conectividade.

Como você obtém um shell em um contêiner em execução para fins de depuração?

Resposta:

Você pode usar kubectl exec -it <nome-do-pod> -- /bin/bash (ou /bin/sh se bash não estiver disponível). Isso permite inspecionar o sistema de arquivos do contêiner, executar comandos e diagnosticar problemas diretamente em seu ambiente.

Quais são as causas comuns para 'ImagePullBackOff' e como você as soluciona?

Resposta:

Causas comuns incluem nome/tag de imagem incorretos, problemas de autenticação de registro privado ou problemas de conectividade de rede com o registro. Eu verificaria kubectl describe pod <nome-do-pod> para erros de pull de imagem e verificaria nomes de imagem, credenciais de registro (secrets) e acesso à rede.

Sua aplicação está experimentando alta latência, mas os pods parecem saudáveis. Qual poderia ser o problema?

Resposta:

Isso pode indicar contenção de recursos (CPU throttling), código de aplicação ineficiente ou problemas com dependências externas. Eu verificaria as métricas de utilização de recursos (CPU/memória) para os pods, revisaria os logs da aplicação em busca de consultas lentas e inspecionaria a latência da rede para serviços externos.

Como você depuraria uma falha de liveness ou readiness probe?

Resposta:

Eu verificaria kubectl describe pod <nome-do-pod> para eventos de falha de probe e o comando/caminho específico que está sendo usado. Em seguida, eu usaria kubectl logs <nome-do-pod> para ver se a aplicação está travando ou não respondendo ao endpoint da probe. Executar o comando da probe manualmente dentro do contêiner também pode ajudar.

Um node está no estado 'NotReady'. Quais são as razões típicas e como você investiga?

Resposta:

Razões típicas incluem o kubelet não estar em execução, problemas de rede impedindo a comunicação com o plano de controle, ou recursos insuficientes do node. Eu faria SSH no node, verificaria systemctl status kubelet, revisaria os logs do kubelet (journalctl -u kubelet) e verificaria a conectividade de rede com o API server.

Melhores Práticas e Segurança no Kubernetes

Quais são algumas melhores práticas essenciais para proteger clusters Kubernetes?

Resposta:

Práticas essenciais incluem implementar Controle de Acesso Baseado em Função (RBAC) com privilégio mínimo, atualizar regularmente o Kubernetes e seus componentes, escanear imagens de contêineres em busca de vulnerabilidades, segmentação de rede usando Network Policies e proteção do acesso ao API server.

Explique o princípio de 'privilégio mínimo' no RBAC do Kubernetes.

Resposta:

Privilégio mínimo significa conceder aos usuários e service accounts apenas as permissões mínimas necessárias para realizar suas tarefas. Isso minimiza o impacto potencial caso uma conta seja comprometida, reduzindo a superfície de ataque dentro do cluster.

Como as Network Policies aprimoram a segurança em um cluster Kubernetes?

Resposta:

As Network Policies definem como os pods podem se comunicar entre si e com endpoints externos. Elas atuam como firewalls no nível do pod, permitindo a segmentação de rede e o isolamento de cargas de trabalho sensíveis para prevenir comunicação não autorizada.

Qual é a importância da varredura de imagens em um pipeline de CI/CD para implantações Kubernetes?

Resposta:

A varredura de imagens identifica vulnerabilidades conhecidas (CVEs) e configurações incorretas dentro das imagens de contêineres antes da implantação. Integrá-la ao CI/CD garante que apenas imagens seguras e compatíveis sejam enviadas para registros e implantadas no cluster, prevenindo a execução de software vulnerável.

Descreva um método comum para gerenciar secrets de forma segura no Kubernetes.

Resposta:

Embora os Kubernetes Secrets forneçam armazenamento básico, eles são codificados em base64, não criptografados em repouso por padrão. As melhores práticas envolvem o uso de soluções externas de gerenciamento de segredos como HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault, frequentemente integradas via drivers CSI ou operadores de secrets externos, para criptografar e gerenciar dados sensíveis.

O que são Pod Security Standards (PSS) e por que são importantes?

Resposta:

Pod Security Standards são controles de segurança integrados que definem diferentes níveis de isolamento para pods (Privileged, Baseline, Restricted). Eles ajudam a impor melhores práticas de segurança, impedindo que pods sejam executados com configurações excessivamente permissivas, como acesso root ou montagens de host path.

Como você pode prevenir ataques de escalonamento de privilégios dentro de um cluster Kubernetes?

Resposta:

Prevenir o escalonamento de privilégios envolve várias medidas: impor Pod Security Standards, usar contêineres imutáveis, limitar o acesso ao host, implementar RBAC rigoroso e auditar regularmente as configurações do cluster e as atividades dos usuários. Limitar capabilities e proibir contêineres privilegiados são cruciais.

Qual é o papel de uma Service Mesh (por exemplo, Istio, Linkerd) na segurança do Kubernetes?

Resposta:

Uma Service Mesh aprimora a segurança fornecendo recursos como mTLS (mutual TLS) para comunicação criptografada entre serviços, políticas de controle de acesso granulares e criptografia de tráfego. Ela centraliza configurações de segurança e observabilidade para a comunicação de microsserviços.

Explique o conceito de 'infraestrutura imutável' no Kubernetes.

Resposta:

Infraestrutura imutável significa que, uma vez que um componente (como uma imagem de contêiner ou uma aplicação implantada) é construído e implantado, ele nunca é modificado. Quaisquer alterações exigem a construção de uma nova imagem e a substituição da instância antiga, o que melhora a consistência, confiabilidade e segurança ao reduzir o desvio de configuração.

Como quotas de recursos e limit ranges contribuem para a estabilidade e segurança do cluster?

Resposta:

Quotas de recursos limitam a quantidade total de CPU, memória e outros recursos que podem ser consumidos por um namespace, prevenindo a exaustão de recursos. Limit ranges definem requisições/limites de recursos padrão e máximos para pods dentro de um namespace, garantindo que as aplicações não consumam recursos excessivos e melhorando a estabilidade e a justiça do cluster.

Desafios Práticos e Hands-on com Kubernetes

Você tem um Pod que continua travando. Como você solucionaria esse problema?

Resposta:

Eu começaria verificando kubectl describe pod <nome-do-pod> para eventos e status. Em seguida, usaria kubectl logs <nome-do-pod> para revisar os logs da aplicação. Se for um loop de travamento, eu verificaria kubectl logs --previous <nome-do-pod> para os logs do último contêiner encerrado.

Um Deployment está preso em um estado pendente. Quais são as razões comuns e como você as diagnostica?

Resposta:

Razões comuns incluem recursos insuficientes (CPU/memória), taints/tolerations de node, ou problemas de node selectors/affinity. Eu usaria kubectl describe pod <nome-do-pod> para ver os eventos de agendamento e kubectl get events --field-selector involvedObject.kind=Node para verificar as condições do node.

Como você exporia um aplicativo stateless rodando em um Deployment para tráfego externo?

Resposta:

Eu criaria um Service do tipo LoadBalancer ou NodePort para expor o Deployment. Para roteamento mais avançado e terminação SSL, eu usaria um recurso Ingress, que requer um Ingress Controller.

Você precisa realizar uma atualização rolling em um Deployment sem downtime. Como o Kubernetes lida com isso e quais são as considerações chave?

Resposta:

Os Deployments do Kubernetes lidam com atualizações rolling por padrão, criando novos Pods antes de terminar os antigos com base nas configurações de maxUnavailable e maxSurge. Considerações chave incluem readiness probes adequadas, alocação de recursos suficiente e teste da nova versão antes do rollout completo.

Descreva um cenário onde você usaria um ConfigMap versus um Secret.

Resposta:

Eu usaria um ConfigMap para dados de configuração não sensíveis, como variáveis de ambiente da aplicação ou arquivos de configuração. Eu usaria um Secret para dados sensíveis, como chaves de API, credenciais de banco de dados ou certificados TLS, que são armazenados criptografados por padrão.

Como você garante que um Pod rode apenas em nodes com hardware específico (por exemplo, GPUs)?

Resposta:

Eu usaria Node Selectors ou Node Affinity. Node Selectors são mais simples para correspondências exatas (nodeSelector: {gpu: 'true'}). Node Affinity oferece mais flexibilidade com regras requiredDuringSchedulingIgnoredDuringExecution ou preferredDuringSchedulingIgnoredDuringExecution.

Um Service não está roteando tráfego para seus Pods. Que passos você tomaria para depurar isso?

Resposta:

Primeiro, verifique kubectl describe service <nome-do-servico> para confirmar se seu seletor corresponde aos labels dos Pods. Em seguida, verifique kubectl get endpoints <nome-do-servico> para ver se algum IP de Pod está listado. Finalmente, certifique-se de que os Pods estão saudáveis e que suas readiness probes estão passando.

Você precisa executar uma tarefa única, como uma migração de banco de dados, dentro do seu cluster. Que recurso Kubernetes você usaria?

Resposta:

Eu usaria um recurso Job do Kubernetes. Um Job cria um ou mais Pods e garante que um número especificado deles termine com sucesso. Para tarefas agendadas, eu usaria um CronJob.

Explique o propósito de um PersistentVolume (PV) e PersistentVolumeClaim (PVC).

Resposta:

Um PersistentVolume (PV) é uma unidade de armazenamento no cluster provisionada por um administrador. Um PersistentVolumeClaim (PVC) é uma solicitação de armazenamento por um usuário. O PVC se vincula a um PV adequado, permitindo que os Pods consumam armazenamento durável independentemente de seu ciclo de vida.

Como você escalaria um Deployment manualmente e automaticamente?

Resposta:

Manualmente, eu usaria kubectl scale deployment <nome-do-deployment> --replicas=<numero>. Automaticamente, eu usaria um Horizontal Pod Autoscaler (HPA), que escala o número de Pods em um Deployment ou ReplicaSet com base na utilização de CPU observada ou outras métricas personalizadas.

Resumo

Navegar por uma entrevista de Kubernetes pode ser uma experiência desafiadora, mas gratificante. Este documento forneceu uma visão geral abrangente de perguntas comuns e respostas perspicazes, projetadas para equipá-lo com o conhecimento e a confiança necessários para se destacar. Lembre-se, a preparação completa é fundamental; entender os conceitos centrais, as aplicações práticas e os cenários de solução de problemas melhorará significativamente seu desempenho.

Além da entrevista, a jornada com o Kubernetes é de aprendizado e adaptação contínuos. O cenário evolui rapidamente, e manter a curiosidade, experimentar novos recursos e engajar-se com a comunidade garantirá que suas habilidades permaneçam afiadas e relevantes. Abrace os desafios, celebre seus sucessos e continue construindo sua expertise nesta tecnologia dinâmica e essencial.