instruction: Explain Como um ReplicaSet funciona
output: Este documento pode estar desatualizado
  Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada:
  ReplicaSet
  ReplicaSet
  O propósito de um ReplicaSet é gerenciar um conjunto de réplicas de Pods em execução a qualquer momento. Por isso, é geralmente utilizado para garantir a disponibilidade de um certo número de Pods idênticos.
  Como um ReplicaSet funciona
  Um ReplicaSet é definido por campos, incluindo um seletor que identifica quais Pods podem ser adquiridos, um número de réplicas indicando quantos Pods devem ser mantidos, e um pod template especificando as definições para novos Pods que devem ser criados para atender ao número de réplicas estipuladas. Um ReplicaSet cumpre seu propósito criando e deletando Pods conforme for preciso para atingir o número desejado. Quando um ReplicaSet precisa criar novos Pods, ele usa o seu podTemplate.
  Um ReplicaSet é conectado ao seus Pods pelo campo do Pod
  metadata.ownerReferences
  , que especifíca qual recurso é dono do objeto atual. Todos os Pods adquiridos por um ReplicaSet possuem as informações de identificação do ReplicaSet vinculado no campo ownerReferences. É por esse elo que o ReplicaSet tem conhecimento do estado dos Pods que está mantendo e assim faz seu planejamento.
  Um ReplicaSet identifica novos Pods a serem adquiridos utilizando o seu seletor. Caso exista um Pod que não tenha OwnerReference ou se o OwnerReference não for um
  Controlador
  e o seu seletor corresponde com o do ReplicaSet, o Pod é adquirido imediatamente por esse ReplicaSet.
  Quando usar um ReplicaSet
  Um ReplicaSet garante que um número de réplicas de um Pod estão executando em qualquer momento. Entretanto, um Deployment é um conceito de nível superior que gerencia ReplicaSets e fornece atualizações declarativas aos Pods assim como várias outras funções úteis. Portanto, nós recomendamos a utilização de Deployments ao invés do uso direto de ReplicaSets, exceto se for preciso uma orquestração de atualização customizada ou que nenhuma atualização seja necessária.
  Isso na realidade significa que você pode nunca precisar manipular objetos ReplicaSet:
  prefira usar um Deployment, e defina sua aplicação na seção spec.
  Exemplo
  controllers/frontend.yaml
  apiVersion
  apps/v1
  kind
  ReplicaSet
  metadata
  name
  frontend
  labels
  guestbook
  tier
  frontend
  spec
  # modifique o número de replicas de acordo com o seu caso
  replicas
  selector
  matchLabels
  tier
  frontend
  template
  metadata
  labels
  tier
  frontend
  spec
  containers
  name
  php-redis
  image
  gcr.io/google_samples/gb-frontend:v3
  Salvando esse manifesto como
  frontend.yaml
  e submetendo no cluster Kubernetes irá criar o ReplicaSet definido e os Pods mantidos pelo mesmo.
  kubectl apply -f https://kubernetes.io/pt-br/examples/controllers/frontend.yaml
  Você pode então retornar os ReplicaSets atualmente existentes atualmente no cluster:
  kubectl get rs
  E observar o ReplicaSet com o nome de frontend que você criou:
  NAME DESIRED CURRENT READY AGE
  frontend
  Você também pode checar o estado do ReplicaSet:
  kubectl describe rs/frontend
  E você deve ver uma saída similar a esta:
  Name: frontend
  Namespace: default
  Selector:
  tier
  frontend
  Labels:
  guestbook
  tier
  frontend
  Annotations: kubectl.kubernetes.io/last-applied-configuration:
  "apiVersion"
  "apps/v1"
  "kind"
  "ReplicaSet"
  "metadata"
  "annotations"
  "labels"
  "app"
  "guestbook"
  "tier"
  "frontend"
  "name"
  "frontend"
  ,...
  Replicas:
  current /
  desired
  Pods Status:
  Running /
  Waiting /
  Succeeded /
  Failed
  Pod Template:
  Labels:
  tier
  frontend
  Containers:
  php-redis:
  Image: gcr.io/google_samples/gb-frontend:v3
  Port: <none>
  Host Port: <none>
  Environment: <none>
  Mounts: <none>
  Volumes: <none>
  Events:
  Type Reason Age From Message
  ---- ------ ---- ---- -------
  Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm
  Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv
  Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts
  E por fim você consegue verificar os Pods que foram criados:
  kubectl get pods
  Você deve ver uma informação do Pod similar à esta:
  NAME READY STATUS RESTARTS AGE
  frontend-b2zdv 1/1 Running
  6m36s
  frontend-vcmts 1/1 Running
  6m36s
  frontend-wtsmm 1/1 Running
  6m36s
  Você consegue também validar que a referência de dono desses pods está definida para o ReplicaSet frontend.
  Para fazer isso, retorne o yaml de um dos Pods que estão executando:
  kubectl get pods frontend-b2zdv -o yaml
  O output será semelhante ao exibido abaixo, com as informações do ReplicaSet frontend definidas no campo ownerReferences dentro da metadata do Pod:
  apiVersion: v1
  kind: Pod
  metadata:
  creationTimestamp:
  "2020-02-12T07:06:16Z"
  generateName: frontend-
  labels:
  tier: frontend
  name: frontend-b2zdv
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
  blockOwnerDeletion:
  true
  controller:
  true
  kind: ReplicaSet
  name: frontend
  uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
  Aquisições de Pod sem Template
  Enquanto você pode criar Pods diretamente sem problemas, é fortemente recomendado que você se certifique que esses Pods não tenham labels que combinem com o seletor de um dos seus ReplicaSets. O motivo para isso é que um ReplicaSet não é limitado a possuir apenas Pods estipulados por seu template -- ele pode adquirir outros Pods na maneira descrita nas seções anteriores.
  Observe o exemplo anterior do ReplicaSet frontend, e seus Pods especificados no seguinte manifesto:
  pods/pod-rs.yaml
  apiVersion
  kind
  metadata
  name
  pod1
  labels
  tier
  frontend
  spec
  containers
  name
  hello1
  image
  gcr.io/google-samples/hello-app:2.0
  apiVersion
  kind
  metadata
  name
  pod2
  labels
  tier
  frontend
  spec
  containers
  name
  hello2
  image
  gcr.io/google-samples/hello-app:1.0
  Como esses Pods não possuem um Controller (ou qualquer objeto) referenciados como seu dono e possuem labels que combinam com o seletor do ReplicaSet frontend, eles serão imediatamente adquiridos pelo ReplicaSet.
  Imagine que você crie os Pods depois que o ReplicaSet frontend foi instalado e criou as réplicas de Pod inicial definida para cumprir o número de réplicas requiridas:
  kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
  Os novos Pods serão adquiridos pelo ReplicaSet, e logo depois terminados já que o ReplicaSet estará acima do número desejado.
  Buscando os Pods:
  kubectl get pods
  O output mostra que os novos Pods ou já estão terminados, ou estão no processo de ser terminados.
  NAME READY STATUS RESTARTS AGE
  frontend-b2zdv 1/1 Running
  frontend-vcmts 1/1 Running
  frontend-wtsmm 1/1 Running
  pod1 0/1 Terminating
  pod2 0/1 Terminating
  Se você criar os Pods primeiro:
  kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
  mas em seguida criar o ReplicaSet:
  kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
  Você vai perceber que o ReplicaSet adquiriu os Pods e criou apenas novos de acordo com o seu spec até que o número de novo Pods e os Pods iniciais seja igual a ao número desejado. Listando os Pods:
  kubectl get pods
  Irá retornar a seguinte saída:
  NAME READY STATUS RESTARTS AGE
  frontend-hmmj2 1/1 Running
  pod1 1/1 Running
  pod2 1/1 Running
  Nesse sentido, um ReplicaSet pode possuir um grupo não-homogêneo de Pods
  Escrevendo um manifesto ReplicaSet
  Como todos os outros objetos de Kubernetes API, um ReplicaSet necessita dos campos
  apiVersion
  kind
  metadata
  Para ReplicaSets, o
  kind
  sempre será um ReplicaSet.
  O nome de um objeto ReplicaSet precisa ser
  nome de subdomínio de DNS
  válido.
  Um ReplicaSet também precisa de uma
  seção
  .spec
  Template de Pod
  .spec.template
  é um
  template de pod
  que também necessita de labels configurados. No nosso exemplo
  frontend.yaml
  nós temos uma label:
  tier: frontend
  Fique atento para não sobrepor com seletores de outros controllers, para que eles não tentem adquirir esse Pod.
  Para o campo de
  restart policy
  do template,
  .spec.template.spec.restartPolicy
  , o único valor permitido é
  Always
  , que é o padrão.
  Seletor de Pod
  O campo
  .spec.selector
  é um
  seletor de labels
  . Como discutido
  anteriormente
  esses são os labels usados para identificar Pods em potencial para aquisição. No nosso exemplo
  frontend.yaml
  , o seletor era:
  matchLabels
  tier
  frontend
  No ReplicaSet,
  .spec.template.metadata.labels
  precisa combinar com
  spec.selector
  , ou será rejeitado pela API.
  Nota:
  Para 2 ReplicaSets definindo o mesmo
  .spec.selector
  mas diferentes campos de
  .spec.template.metadata.labels
  .spec.template.spec
  , cada ReplicaSet ignorará os Pods criados pelo outro ReplicaSet.
  Replicas
  Você pode definir quantos Pods devem executar simultaneamente determinando
  .spec.replicas
  . O ReplicaSet irá criar/deletar os Pods para igualar à esse número.
  Se você não especificar o
  .spec.replicas
  , seu padrão é 1.
  Trabalhando com ReplicaSets
  Deletando um ReplicaSet e seus Pods
  Para deletar um ReplicaSet e todos os seus Pods, use
  kubectl delete
  Garbage collector
  automaticamente deleta todos os Pods dependentes por padrão.
  Quando usar a API REST ou a biblioteca
  client-go
  , você precisa definir
  propagationPolicy
  para
  Background
  Foreground
  na opção -d.
  Por exemplo:
  kubectl proxy --port
  curl -X DELETE
  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend'
  > -d
  '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}'
  > -H
  "Content-Type: application/json"
  Deletando apenas o ReplicaSet
  Você consegue deletar um ReplicaSet sem afetar qualquer um dos Pods usando
  kubectl delete
  com a opção
  --cascade=orphan
  Quando usar a API REST ou a biblioteca
  client-go
  , você precisa definir
  propagationPolicy
  para
  Orphan
  Por exemplo:
  kubectl proxy --port
  curl -X DELETE
  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend'
  > -d
  '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}'
  > -H
  "Content-Type: application/json"
  Quando o ReplicaSet original for deletado, você pode criar um novo ReplicaSet para substituí-lo. Contanto que o
  .spec.selector
  do antigo e do atual sejam o mesmo, o novo irá adquirir os Pods antigos. Porém, o ReplicaSet não atualizará as definições dos Pods existentes caso surja um novo e diferente template de pod.
  Para atualizar esses Pods para um novo spec de um modo controlado, use um
  Deployment
  , já que ReplicaSets não suportam um atualização gradual diretamente.
  Isolando Pods de um ReplicaSet
  Você pode remover Pods de um Replicaset trocando suas labels. Essa técnica pode ser usada para remover Pods de um serviço para depuração, recuperação de dados, etc. Pods que forem removidos por esse método serão substituídos imediatamente (assumindo que o número de replicas não tenha sido alterado).
  Escalonando um ReplicaSet
  Um ReplicaSet pode ser facilmente escalonado para cima ou para baixo simplesmente atualizando o campo de
  .spec.replicas
  . O Replicaset controller garante que o número desejado de Pods com um seletor de label correspondente estejam disponíveis e operando.
  Ao escalonar para baixo, o Replicaset controller escolhe quais pods irá deletar ordenando os pods disponíveis para priorizar quais pods seram escalonados para baixo seguindo o seguinte algoritmo geral:
  Pods pendentes (e não agendáveis) são decaídos primeiro
  Se a anotação
  controller.kubernetes.io/pod-deletion-cost
  estiver definida, então o pod com o menor valor será priorizado primeiro.
  Pods em nós com mais réplicas são decaídos primeiro que pods em nodes com menos réplicas.
  Se a data de criação dos pods for diferente, o pod que foi criado mais recentemente vem antes que o pod mais antigo (as datas de criação são guardados em uma escala logarítmica caso o
  feature gate
  LogarithmicScaleDown
  esteja habilitado)
  Se o Pod obedecer todos os items acima simultaneamente, a seleção é aleatória.
  Custo de deleção de Pods
  ESTADO DA FUNCIONALIDADE:
  Kubernetes v1.22 [beta]
  Utilizando a anotação
  controller.kubernetes.io/pod-deletion-cost
  usuários podem definir uma preferência em relação à quais pods serão removidos primeiro caso o ReplicaSet precise escalonar para baixo.
  A anotação deve ser definida no pod, com uma variação de [-2147483648, 2147483647]. Isso representa o custo de deletar um pod comparado com outros pods que pertencem à esse mesmo ReplicaSet. Pods com um custo de deleção menor são eleitos para deleção antes de pods com um custo maior.
  O valor implícito para essa anotação para pods que não a tem definida é 0; valores negativos são permitidos.
  Valores inválidos serão rejeitados pelo servidor API.
  Esse recurso está em beta e é habilitado por padrão. Você consegue desabilita-lo usando o
  feature gate
  PodDeletionCost
  ambos no kube-apiserver e no kube-controller-manager.
  Nota:
  Esse recurso é honrado baseado no melhor esforço, portanto não oferece qualquer garantia na ordem de deleção dos pods.
  Usuários são recomendados à evitar atualizações frequentes em anotações, como gerar atualizações baseando-se em alguma métrica, porque fazendo isso irá criar um número significante de atualizações de pod para o apiserver.
  Exemplo de caso de uso
  Os diferentes Pods de uma aplicação podem ter níveis de utilização divergentes. Ao escalonar para baixo, a aplicação pode preferir remover os pods com a menor utilização. Para evitar atualizações frequentes nos pods, a aplicação deve atualizar
  controller.kubernetes.io/pod-deletion-cost
  uma vez antes de expedir o escalonamento para baixo das réplicas (configurando a anotação para um valor proporcional ao nível de utilização do Pod). Isso funciona se a própria aplicação controlar o escalonamento; por exemplo, o pod condutor de um Deployment de Spark.
  ReplicaSet como um Horizontal Pod Autoscaler Target
  Um ReplicaSet pode também ser controlado por um
  Horizontal Pod Autoscalers (HPA)
  . Isto é,
  um ReplicaSet pode ser automaticamente escalonado por um HPA. Aqui está um exemplo de um HPA controlando o ReplicaSet que nós criamos no exemplo anterior.
  controllers/hpa-rs.yaml
  apiVersion
  autoscaling/v1
  kind
  HorizontalPodAutoscaler
  metadata
  name
  frontend-scaler
  spec
  scaleTargetRef
  kind
  ReplicaSet
  name
  frontend
  minReplicas
  maxReplicas
  targetCPUUtilizationPercentage
  Salvando esse manifesto como
  hpa-rs.yaml
  e enviando para o cluster Kubernetes deve
  criar um HPA definido que autoescalona o ReplicaSet controlado dependendo do uso de CPU
  dos Pods replicados.
  kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
  Alternativamente, você pode usar o comando
  kubectl autoscale
  para realizar a mesma coisa
  (e é bem mais simples!)
  kubectl autoscale rs frontend --max
  --min
  --cpu-percent
  Alternativas ao ReplicaSet
  Deployment (recomendado)
  Deployment
  é um objeto o qual pode possuir ReplicaSets, atualizá-los e por consequência seus Pods via atualizações declarativas, gradativas do lado do servidor.
  Enquanto ReplicaSets conseguem ser usados independentemente, hoje eles são principalmente usados por Deployments como um mecanismo para orquestrar a criação, deleção e atualização de um Pod. Quando você usa Deployments você não precisa se preocupar com o gerenciamento de ReplicaSets que são criados por ele. Deployments controlam e gerenciam seus ReplicaSets.
  Por isso, é recomendado o uso de Deployments quando você deseja ReplicaSets.
  Bare Pods
  Diferente do caso onde um usuário cria Pods diretamente, um ReplicaSet substitui Pods que forem deletados ou terminados por qualquer motivo, como em caso de falha de nó ou manutenção disruptiva de nó, como uma atualização de kernel. Por esse motivo, nós recomendamos que você use um ReplicaSet mesmo que sua aplicação necessite apenas de um único Pod. Pense na semelhança com um supervisor de processos, apenas que ele supervisione vários Pods em múltiplos nós ao invés de apenas um Pod. Um ReplicaSet delega reinicializações de um container local para algum agente do nó (Kubelet ou Docker, por exemplo).
  Use um
  no lugar de um ReplicaSet para Pods que tem por objetivo sua terminação no final da execução (como batch jobs).
  DaemonSet
  Use um
  DaemonSet
  no lugar de um ReplicaSet para Pods que precisam prover funções no nível de sistema, como monitoramento do sistema ou logs do sistema. Esses Pods tem um tempo de vida ligado à vida útil do sistema:
  os Pods precisam estar executando na máquina antes de outros Pods inicializarem, e são seguros de terminarem quando a máquina esta preparada para reiniciar/desligar.
  ReplicationController
  ReplicaSets são sucessores ao
  ReplicationControllers
  Os dois servem para o mesmo propósito, e tem comportamentos semelhantes, exceto que um ReplicationController não suporta os requerimentos de um seletor baseado em definição como descrito no
  guia de usuário de label
  Portanto, ReplicaSets são preferíveis à ReplicationControllers
  Próximos passos
  Aprenda sobre
  Pods
  Aprenda sobre
  Deployments
  Executar uma aplicação Stateless usando um Deployment
  o qual necessita de ReplicaSets para funcionar.
  ReplicaSet
  é um recurso alto nível na API REST do Kubernetes.
  Leia a
  ReplicaSet
  definição de objeto para entender a API para replica sets.
  Leia sobre
  PodDisruptionBudget
  e como
  você consegue usá-lo para gerenciar disponibilidade de aplicação durante interrupções.
  Comentários
  Esta página foi útil?
  Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em
  Stack Overflow
  Abra um bug no repositório do GitHub se você deseja
  relatar um problema
  sugerir uma melhoria
  Última modificação October 07, 2023 at 1:27 AM PST:
  [pt] update the range of pod-deletion-cost (c9cd9a2693)