Qual é a diferença entre um pod e uma implantação?

Tenho criado pods com type:deploymentmas vejo que alguma documentação utiliza type:pod, mais especificamente a documentação para pods com vários contêineres :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

Mas, para criar pods, posso apenas usar um tipo de implantação :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

Notei que a documentação do pod diz:

O comando create pode ser usado para criar um pod diretamente, ou pode criar um pod ou pods por meio de uma implantação. É altamente recomendável que você use uma implantação para criar seus pods. Ele observa os pods com falha e inicia novos pods conforme necessário para manter o número especificado. Se você não deseja que uma implantação monitore seu pod (por exemplo, seu pod está gravando dados não persistentes que não sobreviverão a uma reinicialização ou seu pod deve durar muito pouco), você pode criar um pod diretamente com o comando create.

Nota: Recomendamos o uso de uma implantação para criar pods. Você deve usar as instruções abaixo apenas se não desejar criar uma implantação.

Mas isso levanta a questão do que kind:podé bom? De alguma forma, você pode referenciar pods em uma implantação? Eu não vi um caminho. Parece que o que você obtém com os pods é alguns metadados extras, mas nenhuma das opções de implantação, como replicauma política de reinicialização. De que serve um pod que não persiste em dados e sobrevive a uma reinicialização? Eu acho que seria capaz de criar um pod de vários contêineres com uma implantação também.

O Pod e a implantação são objetos completos na API do Kubernetes. A implantação gerencia a criação de Pods por meio do ReplicaSets. O que se resume é que o Deployment criará Pods com as especificações retiradas do modelo. É bastante improvável que você precise criar Pods diretamente para um caso de uso de produção.

A resposta de Radek é muito boa, mas eu gostaria de falar com a minha experiência: você quase nunca usa um objeto com o pod de tipo , porque isso não faz sentido na prática.

Como você precisa de um objeto de implantação - ou de outros objetos da API do Kubernetes, como um controlador de replicação ou um conjunto de réplicas - que precisa manter as réplicas (pods) ativas (esse é o ponto de usar o kubernetes).

O que você usará na prática para um aplicativo típico é:

1. Objeto de implantação (onde você especificará o contêiner / contêineres do seu aplicativo) que hospedará o contêiner do seu aplicativo com algumas outras especificações.

2. Objeto de serviço (que é como um objeto de agrupamento e fornece o chamado IP virtual (IP de cluster) para os podsque têm um determinado rótulo - e esses podssão basicamente os contêineres de aplicativos que você implantou com o antigo objeto de implantação ).

Você precisa do objeto de serviço, pois o podsobjeto de implantação pode ser eliminado, redimensionado para cima e para baixo e não pode confiar nos endereços IP deles, porque eles não serão persistentes.

Então, você precisa de um objeto como um serviço , que ofereça podsum IP estável.

Só queria dar um pouco de contexto pods, para que você saiba como as coisas funcionam juntas.

Espero que isso esclareça algumas coisas para você, não faz muito tempo que eu estava no seu lugar :)

O Kubernetes possui três tipos de objetos que você deve conhecer:

• Pods - executa um ou mais contêineres relacionados
• Serviços - configura a rede em um cluster Kubernetes
• Implantação - Mantém um conjunto de pods idênticos, garantindo que eles tenham a configuração correta e que o número certo deles exista.

Pods:

• Executa um único conjunto de contêineres
• Bom para fins de desenvolvimento pontuais
• Raramente usado diretamente na produção

Desdobramento, desenvolvimento:

• Executa um conjunto de pods idênticos
• Monitora o estado de cada pod, atualizando conforme necessário
• Good for dev
• Bom para produção

E eu concordo com outras respostas, esqueça os Pods e use o Deployment. Por quê? Observe o segundo marcador, que monitora o estado de cada pod, atualizando conforme necessário.

Então, em vez de lutar com mensagens de erro como esta:

Proibido: as atualizações do pod não podem alterar campos diferentes de spec.containers[*].image

Portanto, basta refatorar ou recriar completamente seu Pod em uma implantação que crie um pod para fazer o que você precisa. Com a implantação, você pode alterar qualquer parte da configuração desejada e não precisa se preocupar em ver essa mensagem de erro.

Pod é instância de contêiner.

Essa é a saída de replicas: 3

Pense em um deploymentpode ter muitas instâncias em execução (réplica).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Pod é uma coleção de contêineres e objetos básicos do Kuberntes. Todos os contêineres do pod estão no mesmo nó.

• Não é adequado para produção
• Nenhuma atualização contínua

A implantação é um tipo de controlador no Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

A implantação cria um ReplicaSet que, por sua vez, assegura que, CurrentReplicas seja sempre o mesmo que desejarReplicas.

Vantagens:

• Você pode implementar e reverter suas alterações usando a implantação
• Monitora o estado de cada pod
• Melhor adequado para produção
• Suporta atualizações contínuas

Quero adicionar algumas informações do livro Kubernetes In Action , para que você possa ver toda a imagem e conectar a relação entre os recursos do Kubernetes, como Pod, Deployment e ReplicationController (ReplicaSet)

Pods

são a unidade implementável básica no Kubernetes. Mas, nos casos de uso do mundo real, você deseja que suas implantações permaneçam em funcionamento automaticamente e permaneçam saudáveis ​​sem nenhuma intervenção manual. Para isso, a abordagem recomendada é usar uma implantação , que, sob o capô, cria um ReplicaSet .

Um ReplicaSet , como o nome indica, é um conjunto de réplicas (Pods) mantidas com seu histórico de revisões .

(ReplicaSet estende um objeto mais antigo chamado ReplicationController - que é exatamente o mesmo, mas sem o histórico de revisões.)

Um ReplicaSet monitora constantemente a lista de pods em execução e garante que o número de pods correspondentes a uma determinada especificação sempre corresponda ao número desejado.

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

Uma implantação

é um recurso de nível superior destinado a implantar aplicativos e atualizá-los declarativamente.

Quando você cria uma implantação , um recurso ReplicaSet é criado abaixo (eventualmente mais deles). Os ReplicaSets também replicam e gerenciam pods. Ao usar uma implantação, as vagens reais são criados e gerenciados pela implantação ‘s ReplicaSets , não pela implantação diretamente

Vamos pensar no que aconteceu. Ao alterar o modelo de pod em seu recurso de Implantação, você atualizou seu aplicativo para uma versão mais recente - alterando um único campo!

Por fim, reverta uma implantação para a revisão anterior ou para qualquer revisão anterior tão fácil com o recurso Deployment.

Essas imagens também são do livro Kubernetes In Action .

Tente evitar Pods e implemente Implantações em vez de gerenciar contêineres, pois os objetos do tipo Pod não serão reagendados (ou corrigidos automaticamente) no caso de uma falha no nó ou no encerramento do pod.

Geralmente, uma implantação é preferível porque define um ReplicaSet para garantir que o número desejado de pods esteja sempre disponível e especifica uma estratégia para substituir os pods, como o RollingUpdate.

No kubernetes, os Pods são as menores unidades implementáveis. Sempre que criamos um objeto kubernetes como Implantações, conjuntos de réplicas, conjuntos de estados e daemonsets, ele cria um pod.

Conforme mencionado acima, as implantações criam pods com base no estado desejado mencionado no seu objeto de implantação. Por exemplo, você deseja 5 réplicas de um aplicativo, mencionadas replicas: 5no manifesto de implantação. Agora, o controlador de implantação é responsável por criar 5 réplicas idênticas (nem menos, nem mais) de determinado aplicativo com todos os metadados, como política RBAC, política de redes, rótulos, anotações, verificação de integridade, cotas de recursos, manchas / tolerâncias e outros e associar a cada pods ele cria.

Existem alguns casos em que você deseja criar um pod, por exemplo, se você estiver executando um sidecar de teste no qual não precisará executar o aplicativo para sempre, não precisará de várias réplicas e o executará quando desejar executar nesse caso pod é adequado. Por exemplo helm test, que é uma definição de pod que especifica um contêiner com um determinado comando para executar.