Questão de Sistemas Operacionais — Contêineres (Docker, Kubernetes, etc.) — CESPE / CEBRASPE 2024

Kubernetes: Service vs. Deployment

Gabarito: letra E (ERRADO). O arquivo YAML apresentado define um objeto do tipo Service (com apiVersion: v1 e kind: Service), não um Deployment. Portanto, ao executá-lo, não será criado um deployment com uma imagem do NGINX, mas sim um serviço do tipo LoadBalancer que seleciona pods com o label app: nginx. A criação de um deployment exigiria um manifesto com apiVersion: apps/v1 e kind: Deployment, contendo a especificação da imagem (por exemplo, nginx:latest) no campo spec.template.spec.containers.

No Kubernetes, os objetos são definidos por arquivos YAML que descrevem o estado desejado do cluster. Cada tipo de objeto tem sua própria estrutura e finalidade. O Service é um objeto que define uma política de acesso a um conjunto de pods, fornecendo um endereço IP estável e balanceamento de carga. Já o Deployment é um objeto que gerencia o ciclo de vida de réplicas de pods, garantindo que o número desejado de réplicas esteja sempre em execução. A confusão entre esses dois tipos é comum, mas a distinção é fundamental para a administração correta do cluster.

O manifesto do enunciado especifica apiVersion: v1 e kind: Service. Isso é suficiente para identificar que se trata de um Service, não de um Deployment. O Service define um selector que direciona o tráfego para os pods que possuem o label app: nginx. O tipo LoadBalancer expõe o serviço externamente, criando um balanceador de carga em provedores de nuvem. Nenhuma imagem de contêiner é especificada no Service, pois essa é uma responsabilidade do controlador de pods (Deployment, ReplicaSet, etc.).

Para criar um deployment com NGINX, o manifesto deveria ser semelhante a:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Observe que o apiVersion é apps/v1 e o kind é Deployment. A imagem do contêiner é definida em spec.template.spec.containers. O selector usa matchLabels para selecionar os pods gerenciados pelo deployment.

A banca explora a confusão entre os objetos Service e Deployment. O candidato pode ler o YAML e, ao ver selector e port, associar erroneamente a um deployment. No entanto, a presença de kind: Service e apiVersion: v1 é determinante. Além disso, a ausência de spec.template e spec.replicas no manifesto indica claramente que não se trata de um deployment.

Alternativa E — ❌ Errada (Gabarito)

A afirmação está errada porque o arquivo YAML descreve um Service, não um Deployment. O kind: Service e apiVersion: v1 são os campos que definem o tipo de objeto. Um Service não cria pods nem contêineres; ele apenas define uma política de acesso a pods existentes. Para criar um deployment, seria necessário um manifesto com kind: Deployment e apiVersion: apps/v1, além da especificação da imagem do contêiner. Portanto, a execução desse YAML não resultará na criação de um deployment com uma imagem do NGINX.

Gabarito: letra E (ERRADO).