80/TCP 2m30s
-```
-
-Como é possível observar, há dois *services* no nosso *cluster*: o primeiro é para uso do próprio k8s, enquanto o segundo foi o quê acabamos de criar. Utilizando o ``curl`` contra o endereço IP mostrado na coluna *CLUSTER-IP*, deve nos ser apresentada a tela principal do Nginx.
-
-```
-curl 10.105.41.192
-
-
-
-
-Welcome to nginx!
-
-
-
-Welcome to nginx!
-If you see this page, the nginx web server is successfully installed and
-working. Further configuration is required.
-
-For online documentation and support please refer to
-nginx.org.
-Commercial support is available at
-nginx.com.
-
-Thank you for using nginx.
-
-
-```
-
-Este *pod* está disponível para acesso a partir de qualquer nó do *cluster*.
-
-
-#### Limpando tudo e indo para casa
-
-Para mostrar todos os recursos recém criados, pode-se utilizar uma das seguintes opções a seguir.
-
-```
-kubectl get all
-
-kubectl get pod,service
-
-kubectl get pod,svc
-```
-
-Note que o k8s nos disponibiliza algumas abreviações de seus recursos. Com o tempo você irá se familiar com elas. Para apagar os recursos criados, você pode executar os seguintes comandos.
-
-```
-kubectl delete -f meu-primeiro.yaml
-
-kubectl delete service nginx
-```
-
-Liste novamente os recursos para ver se os mesmos ainda estão presentes.
diff --git a/pt/old/day_one/extras-day1.md b/pt/old/day_one/extras-day1.md
deleted file mode 100644
index c49bf3eb..00000000
--- a/pt/old/day_one/extras-day1.md
+++ /dev/null
@@ -1,42 +0,0 @@
-### Múltiplas Interfaces
-
-Caso algum dos nós que será utilizado tenha mais de uma interface de rede, verifique se ele consegue alcançar o `service` do `Kubernetes` através da rota padrão.
-
-Para verificar, será necessário pegar o IP interno do `service` Kubernetes através do comando ``kubectl get services kubernetes``. Após obter o IP, basta ir no nó que será ingressado no cluster e rodar o comando ``curl -k https://SERVICE`` alterando o `SERVICE` para o IP do `service`. Exemplo: ``curl -k https://10.96.0.1``.
-
-Caso a saída seja algo parecido com o exemplo a seguir, a conexão está acontecendo normalmente.
-
-```json
-{
- "kind": "Status",
- "apiVersion": "v1",
- "metadata": {
-
- },
- "status": "Failure",
- "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
- "reason": "Forbidden",
- "details": {
-
- },
- "code": 403
-}
-```
-
-Caso a saída não seja parecido com o exemplo, será necessário adicionar uma rota com o seguinte comando.
-
-```shell
-ip route add REDE_DO_SERVICE/16 dev INTERFACE
-```
-
-Substitua a `REDE_DO SERVICE` com a rede do `service` (geralmente é um IP finalizando com 0).
-
-Exemplo: Se o IP for `10.96.0.1` a rede é `10.96.0.0`) e a `INTERFACE` com a interface do nó que tem acesso ao `control-plane` do cluster.
-
-Exemplo de comando para adicionar uma rota:
-
-```
-sudo ip route add 10.96.0.0/16 dev eth1
-```
-
-Adicione a rota nas configurações de rede para que seja criada durante o boot.
\ No newline at end of file
diff --git a/pt/old/day_six/descomplicando_kubernetes.md b/pt/old/day_six/descomplicando_kubernetes.md
deleted file mode 100644
index 2c589bec..00000000
--- a/pt/old/day_six/descomplicando_kubernetes.md
+++ /dev/null
@@ -1,566 +0,0 @@
-
-# Descomplicando Kubernetes Day 6
-
-## Sumário
-
-- [Security Context](#security-context)
- - [Utilizando o security Context](#utilizando-o-security-context)
- - [Capabilities](#capabilities)
-- [Manutenção do Cluster ETCD](#manutenção-do-cluster-etcd)
- - [O que preciso saber antes de começar?](#o-que-preciso-saber-antes-de-começar)
- - [O que é o ETCD?](#o-que-é-o-etcd)
- - [ETCD no Kubernetes](#etcd-no-kubernetes)
- - [Certificados ETCD](#certificados-etcd)
- - [Interagindo com o ETCD](#interagindo-com-o-etcd)
- - [Backup do ETCD no Kubernetes](#backup-do-etcd-no-kubernetes)
-- [Dicas para os exames](#dicas-para-os-exames)
-
-# Security Context
-
-**Security Context** são um conjunto de configurações onde definimos privilégios e acessos a um pod. Essas configurações incluem:
-
-* Definir o usuário e grupo do contêiner;
-* Se o contêiner será um contêiner privilegiado;
-* Linux Capabilities;
-* Se o contêiner pode escalar privilégios;
-* Utilizar SELinux/APPArmor.
-
-## Utilizando o security Context
-
-Para utilizar essa configuração precisamos incluir o bloco ``securityCotext`` no manifesto do pod.
-
-Primeiro vamos definir um usuário e grupo para nosso contêiner através das *flags* ``runAsUser`` e ``runAsGroup``. O usuário e grupo devem ser informados por ``UID``. Exemplo: ``1000``.
-
-Crie um arquivo ```busy-security-user.yaml```:
-
-```
-vim busy-security-user.yaml
-```
-
-Informe o seguinte conteúdo:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: busy-security-user
-spec:
- securityContext:
- runAsUser: 1000
- runAsGroup: 1000
- containers:
- - name: sec-busy
- image: busybox
- command: [ "sh", "-c", "sleep 1h" ]
-```
-
-No exemplo anterior utilizamos o user/group ID ``1000`` para o contêiner.
-
-Crie o pod:
-
-```
-kubectl create -f busy-security-user.yaml
-
-pod/busy-security-user created
-```
-
-Vamos executar o comando a seguir para verificar com o ``id`` nosso usuário e grupo.
-
-```
-kubectl exec busy-security-user -- id
-
-uid=1000 gid=1000
-```
-
-As configurações de ``securityContext`` definidas no contêiner são aplicadas somente a ele, já se são definidas no bloco ``securityContext`` fora de ``containers`` será aplicada para todos contêineres no manifesto.
-
-Crie um arquivo ```busy-security-uid.yaml```:
-
-```
-vim busy-security-uid.yaml
-```
-
-Informe o seguinte conteúdo:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: busy-security-uid
-spec:
- securityContext:
- runAsUser: 1000
- runAsGroup: 1000
- containers:
- - name: sec-busy
- image: busybox
- securityContext:
- runAsUser: 2000
- runAsGroup: 2000
- command: [ "sh", "-c", "sleep 1h" ]
-```
-
-Crie o pod:
-
-```
-kubectl create -f busy-security-uid.yaml
-
-pod/busy-security-uid created
-```
-
-Verifique novamente o ``id`` nosso usuário e grupo.
-
-```
-kubectl exec busy-security-uid -- id
-
-uid=2000 gid=1000
-```
-
-As configurações declaradas em contêineres sempre serão prioritárias e irão sobrescrever as demais.
-
-## Capabilities
-
-Nos sistemas UNIX existem basicamente duas categorias de processos: **processos privilegiados** que são executados como o ``UID 0`` (``root`` ou superusuario) e os **não privilegiados** que possuem o ``UID`` **diferente** de ``0``.
-
-Os processos privilegiados dão *bypass* em todas as verificações do kernel. Já os processos não-privilegiados passam por algumas checagens como ``UID``, ``GID`` e ``ACLS``.
-
-Começando no kernel 2.2, o GNU/Linux dividiu as formas tradicionais de privilégios associados ao superusuários em unidades diferentes, agora conhecidas como ``capabilities``, que podem ser habilitadas e desabilitadas independentemente umas das outras. Essas capacidades são atribuídas por thread.
-
-Um pouco mais sobre capabilities está disponível na página: http://man7.org/linux/man-pages/man7/capabilities.7.html
-
-Para demonstrar, vamos fazer um teste tentando alterar a hora de um contêiner.
-
-Crie um arquivo ```busy-security-cap.yaml```:
-
-```
-vim busy-security-cap.yaml
-```
-
-Informe o seguinte conteúdo:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: busy-security-cap
-spec:
- containers:
- - name: sec-busy
- image: busybox
- command: [ "sh", "-c", "sleep 1h" ]
-```
-
-Crie o pod:
-
-```
-kubectl create -f busy-security-cap.yaml
-
-pod/busy-security-cap created
-```
-
-Verifique a hora do contêiner:
-
-```
-kubectl exec busy-security-cap -- date -s "18:00:00"
-
-date: can't set date: Operation not permitted
-```
-
-Adicionando a capabilitie ``SYS_TIME`` no contêiner:
-
-```
-vim busy-security-cap.yaml
-```
-
-Altere o arquivo com o conteúdo a seguir:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: busy-security-cap
-spec:
- containers:
- - name: sec-busy
- image: busybox
- securityContext:
- capabilities:
- add: ["SYS_TIME"]
- command: [ "sh", "-c", "sleep 1h" ]
-```
-
-Delete o pod e recrie novamente:
-
-```
-kubectl delete -f busy-security-cap.yaml
-
-pod "busy-security-cap" deleted
-
-kubectl create -f busy-security-cap.yaml
-
-pod/busy-security-cap created
-```
-
-Verifique novamente a hora do contêiner:
-
-```
-kubectl exec busy-security-cap -- date -s "18:00:00"
-
-Sat May 16 18:00:00 UTC 2020
-```
-
-
-# Manutenção do Cluster ETCD
-
-## O que preciso saber antes de começar?
-
-ETCD é um dos componentes fundamentais que fazem o Kubernetes funcionar.
-
-## O que é o ETCD?
-
-Basicamente, o ETCD é um database de armazenamento de chave-valor de alta disponibilidade.
-
-Em um banco de dados relacional, nós temos colunas e dentro das colunas nós temos o tipo de informação que está sendo armazenada;
-
-|  |
-|:---------------------------------------------------------------------------------------------:|
-| *Banco de dados relacional [Ref: hswstatic.com](https://cdn.hswstatic.com/gif/relational-database-chart.jpg)* |
-
-Em um banco de dados de chave-valor, quando consultamos e obtemos a chave, é retornado o valor atribuido à aquela chave.
-
-|  |
-|:---------------------------------------------------------------------------------------------:|
-| *Banco de dados chave-valor [Ref: Wikimedia.org](https://upload.wikimedia.org/wikipedia/commons/5/5b/KeyValue.PNG)* |
-
-Quando consultamos a chave ``k1``, o resultado retornado é o valor: ``AAA,BBB,CCC``
-
-Quando consultamos a chave ``k5``, o resultado retornado é o valor: ``3,ZZZ,5623``
-
-## ETCD no Kubernetes
-
-No kubernetes, o ETCD é responsável por registrar todo tipo de informação do cluster, tais como: ``nodes``, ``roles``, ``pods``, ``configs``, ``accounts``, ``secrets``, etc.
-
-Quando o cluster é iniciado pelo ***kubeadm***, um pod do ``etcd`` é criado no node ``master``.
-
-Toda informação que é apresentada ao usuário quando executado o comando ``kubect get`` são informações armazenadas no ETCD.
-
-Vejamos se o *pod etcd* foi criado com sucesso com o seguinte comando.
-
-```
-kubectl get pods -n kube-system
-
-NAME READY STATUS RESTARTS AGE
-coredns-66bff467f8-pfm2c 1/1 Running 0 8d
-coredns-66bff467f8-s8pk4 1/1 Running 0 8d
-etcd-docker-01 1/1 Running 0 8d
-kube-apiserver-docker-01 1/1 Running 0 8d
-kube-controller-manager-docker-01 1/1 Running 0 8d
-kube-proxy-mdcgf 1/1 Running 0 8d
-kube-proxy-q9cvf 1/1 Running 0 8d
-kube-proxy-vf8mq 1/1 Running 0 8d
-kube-scheduler-docker-01 1/1 Running 0 8d
-weave-net-7dhpf 2/2 Running 0 8d
-weave-net-fvttp 2/2 Running 0 8d
-weave-net-xl7km 2/2 Running 0 8d
-```
-
-## Certificados ETCD
-
-O ETCD, como os demais serviços do Kubernetes, utilizam certificados PKI para autenticação sobre TLS, essas chaves são declaradas no manifesto de configuração em:
-
-```
-kubectl describe pod etcd-docker-01 -n kube-system
-```
-
-Parâmetros:
-
-```
---cert-file
---key-file
---trusted-ca-file
-```
-
-Essas chaves vão ser utilizadas pelos demais componentes do cluster como, por exemplo, o **API Server** possam conectar e fazerem alterações.
-
-```
-kubectl describe pod kube-apiserver -n kube-system
-```
-
-Parâmetros:
-
-```
---etcd-cafile
---etcd-certfile
---etcd-keyfile
-```
-
-Então, para toda e qualquer interação com o ETCD vamos precisar utilizar esses certificados para nos autenticar.
-
-## Interagindo com o ETCD
-
-Para interagir com o ETCD vamos precisar o ``etcdctl`` ou utilizar o próprio contêiner do etcd com o comando ```kubectl exec```
-
-Referência: https://github.com/etcd-io/etcd/tree/master/etcdctl
-
-Baixando a ultima versão do etcd:
-
-GNU/Linux:
-
-```
-ETCD_VER=v3.4.7
-
-GOOGLE_URL=https://storage.googleapis.com/etcd
-
-GITHUB_URL=https://github.com/etcd-io/etcd/releases/download
-
-DOWNLOAD_URL=${GOOGLE_URL}
-
-rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
-
-rm -rf /tmp/etcd-download-test && mkdir -p /tmp/etcd-download-test
-
-curl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
-
-tar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz -C /tmp/etcd-download-test --strip-components=1
-
-rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
-
-/tmp/etcd-download-test/etcd --version
-
-/tmp/etcd-download-test/etcdctl version
-```
-
-Referência: https://github.com/etcd-io/etcd/releases
-
-Como vimos anteriormente, vamos precisar utilizar os certificados para nos autenticar. Vamos fornecer os dados nos seguintes parâmetros no comando:
-
-```
---cacert
---key
---cert
-```
-
-Além disso vamos precisar do endpoint, caso esteja no contêiner do ETCD seu endpoint será ``127.0.0.1:2379``.
-
-A sua URL para o endpoint vai estar na flag ```--advertise-client-urls``` nas configurações do ETCD.
-
-ETCDCTL:
-
-```
-ETCDCTL_API=3 etcdctl \
---cacert /var/lib/minikube/certs/etcd/ca.crt \
---key /var/lib/minikube/certs/etcd/server.key \
---cert /var/lib/minikube/certs/etcd/server.crt \
---endpoints $ADVERTISE_URL \
-get / --prefix --keys-only
-```
-
-O comando ``kubectl exec`` ficará similar ao mostrado a seguir.
-
-```
-kubectl exec -it etcd-minikube -n kube-system \
--- etcdctl --endpoints=https://127.0.0.1:2379 \
---cacert=/var/lib/minikube/certs/etcd/ca.crt \
---key=/var/lib/minikube/certs/etcd/server.key \
---cert=/var/lib/minikube/certs/etcd/server.crt get / --prefix --keys-only
-```
-
-Output:
-
-```
-/registry/apiregistration.k8s.io/apiservices/v1.
-
-/registry/apiregistration.k8s.io/apiservices/v1.admissionregistration.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.apiextensions.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.apps
-
-/registry/apiregistration.k8s.io/apiservices/v1.authentication.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.authorization.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.autoscaling
-
-/registry/apiregistration.k8s.io/apiservices/v1.batch
-
-/registry/apiregistration.k8s.io/apiservices/v1.coordination.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.networking.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.rbac.authorization.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.scheduling.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1.storage.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1beta1.admissionregistration.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1beta1.apiextensions.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1beta1.authentication.k8s.io
-
-/registry/apiregistration.k8s.io/apiservices/v1beta1.authorization.k8s.io
-```
-
-Aqui temos uma parte do conteúdo da resposta do get no ``/`` do ETCD, onde listamos todas as chaves do etcd.
-
-Em um exemplo um pouco mais prático, vamos listar apenas as chaves dos pods no namespace ``default``. O parâmetro para que o output contenha apenas as chaves é ```--keys-only```.
-
-```
-kubectl exec -it etcd-minikube -n kube-system \
--- etcdctl --endpoints=https://127.0.0.1:2379 \
---cacert=/var/lib/minikube/certs/etcd/ca.crt \
---key=/var/lib/minikube/certs/etcd/server.key \
---cert=/var/lib/minikube/certs/etcd/server.crt get /registry/pods/default \
---prefix=true --keys-only
-```
-
-Output:
-
-```
-/registry/pods/default/nginx
-```
-
-Agora vamos ver os valores contidos na chave ``/registry/pods/default/nginx``, onde estão as configurações do pod. Vamos remover o parâmetro ```--keys-only``` para que possamos ver os valores da chave.
-
-```
-kubectl exec -it etcd-minikube -n kube-system \
--- etcdctl --endpoints=https://127.0.0.1:2379 \
---cacert=/var/lib/minikube/certs/etcd/ca.crt \
---key=/var/lib/minikube/certs/etcd/server.key \
---cert=/var/lib/minikube/certs/etcd/server.crt get /registry/pods/default/nginx \
---prefix=true
-```
-
-Output:
-
-```
-k8s
-
-v1Pod
-
-nginxdefault"*$a748750e-7582-4db5-ab63-0fab1d0c91542Z
-
-runnginxz
-kubectlUpdatev����FieldsV1:�
-�{"f:metadata":{"f:labels":{".":{},"f:run":{}}},"f:spec":{"f:containers":{"k:{\"name\":\"nginx\"}":{".":{},"f:image":{},"f:imagePullPolicy":{},"f:name":{},"f:resources":{},"f:terminationMessagePath":{},"f:terminationMessagePolicy":{}}},"f:dnsPolicy":{},"f:enableServiceLinks":{},"f:restartPolicy":{},"f:schedulerName":{},"f:securityContext":{},"f:terminationGracePeriodSeconds":{}}}��
-kubeletUpdatev����FieldsV1:�
-�{"f:status":{"f:conditions":{"k:{\"type\":\"ContainersReady\"}":{".":{},"f:lastProbeTime":{},"f:lastTransitionTime":{},"f:status":{},"f:type":{}},"k:{\"type\":\"Initialized\"}":{".":{},"f:lastProbeTime":{},"f:lastTransitionTime":{},"f:status":{},"f:type":{}},"k:{\"type\":\"Ready\"}":{".":{},"f:lastProbeTime":{},"f:lastTransitionTime":{},"f:status":{},"f:type":{}}},"f:containerStatuses":{},"f:hostIP":{},"f:phase":{},"f:podIP":{},"f:podIPs":{".":{},"k:{\"ip\":\"172.17.0.5\"}":{".":{},"f:ip":{}}},"f:startTime":{}}}�
-1
-default-token-657qb2
-default-token-657qb��
-nginxnginx*BJJ
-default-token-657qb-/var/run/secrets/kubernetes.io/serviceaccount"2j/dev/termination-logrAlways����FileAlways 2
-
-ClusterFirstBdefaultJdefaultminikubeX`hr���default-scheduler�6
-node.kubernetes.io/not-readyExists" NoExecute(��8
-node.kubernetes.io/unreachableExists" NoExecute(�����
-Running#
-
-InitializedTru����*2
-ReadyTru����*2'
-ContainersReadyTru����*2$
-
-PodScheduledTru����*2"*
- 192.168.64.22
-172.17.0.����B�
-nginx
-
-
-���� (2
- nginx:latest:_docker-pullable://nginx@sha256:86ae264c3f4acb99b2dee4d0098c40cb8c46dcf9e1148f05d3a51c4df6758c12BIdocker://4f42eaab397e862432c01d66d44b6e2d395ffae5e5dd16cfb83d906b3fc5022bHJ
-BestEffortZb
-
-
-172.17.0.5"
-```
-
-Isso foi um pouco de como podemos interagir diretamente com o ETCD.
-
-## Backup do ETCD no Kubernetes
-
-Como sabemos, o ETCD é responsável por armazenar todo tipo de informação sobre o estado do nosso cluster.
-
-Para realizarmos o backup (snapshot) do ETCD, precisamos utilizar alguns comandos *built-in* que já vem com o próprio ETCD.
-
-Esse snapshot, contém todos os dados do estado do cluster.
-
-Para realizar o snapshot do ETCD sem a autenticação **TLS habilitado**, precisamos executar o seguinte comando.
-
-```
-ETCDCTL_API=3 etcdctl \
---endpoints $ENDPOINT \
-snapshot save snapshot.db
-```
-
-Visualizando o status.
-
-```
-ETCDCTL_API=3 etcdctl \
---write-out=table \
-snapshot status snapshot.db
-```
-
-Output:
-
-```
-+----------+----------+------------+------------+
-| HASH | REVISION | TOTAL KEYS | TOTAL SIZE |
-+----------+----------+------------+------------+
-| fe01cf57 | 10 | 7 | 2.1 MB |
-+----------+----------+------------+------------+
-```
-
-Existem algumas diferenças ao realizar o snapshot do ETCD com o **TLS habilitado** que são obrigatórias:
-
-Além do ``--endpoits``, precisamos adicionar as chaves e certificados referentes ao TLS que são:
-
-* ``--cacert`` - verifica os certificados dos servidores que estão com TLS habilitados;
-* ``--cert`` - identifica o cliente usando o certificado TLS;
-* ``--endpoints=[127.0.0.1:2379]`` - novamente, esse é o valor padrão de onde o ETCD está rodando no nó master com a porta padrão do ETCD, 2379 - TCP;
-* ``--key`` - identifica o cliente usando a chave TLS;
-
-Logo, o comando ficará assim:
-
-```
-ETCDCTL_API=3 etcdctl \
---cacert /var/lib/minikube/certs/etcd/ca.crt \
---key /var/lib/minikube/certs/etcd/server.key \
---cert /var/lib/minikube/certs/etcd/server.crt \
---endpoints [127.0.0.1:2379] \
-snapshot save snapshot.db
-```
-
-# Dicas para os exames
-
-Para a prova do CKA é bem relevante saber como o ETCD funciona.
-
-O assunto do ETCD está relacionado aos 11% do Cluster Maintenance.
-
-Porém, pode ser que você seja obrigado a salvar esse **snapshot** em um diretório específico. Exemplo: ``/tmp/``.
-
-Com isso, o comando ficaria assim:
-
-```
-ETCDCTL_API=3 etcdctl \
---cacert /var/lib/minikube/certs/etcd/ca.crt \
---key /var/lib/minikube/certs/etcd/server.key \
---cert /var/lib/minikube/certs/etcd/server.crt \
---endpoints [127.0.0.1:2379] \
-snapshot save /tmp/snapshot.db
-```
-
-Para fazer o restore usando o arquivo de backup /tmp/snapshot.db podemos executar os seguintes comandos:
-
-```
-ETCDCTL_API=3 etcdctl \
---cacert /var/lib/minikube/certs/etcd/ca.crt \
---key /var/lib/minikube/certs/etcd/server.key \
---cert /var/lib/minikube/certs/etcd/server.crt \
---endpoints 127.0.0.1:2379 \
-snapshot restore /tmp/snapshot.db
-
-sudo mv /var/lib/etcd/member /var/lib/etcd/member.old
-sudo mv /var/lib/etcd/default.etcd/member /var/lib/etcd/
-```
diff --git a/pt/old/day_three/descomplicando_kubernetes.md b/pt/old/day_three/descomplicando_kubernetes.md
deleted file mode 100644
index cea0150a..00000000
--- a/pt/old/day_three/descomplicando_kubernetes.md
+++ /dev/null
@@ -1,1540 +0,0 @@
-# Descomplicando Kubernetes dia 3
-
-## Sumário
-
-- [Descomplicando Kubernetes dia 3](#descomplicando-kubernetes-dia-3)
- - [Sumário](#sumário)
-- [Deployments](#deployments)
- - [Filtrando por Labels](#filtrando-por-labels)
- - [Node Selector](#node-selector)
- - [Kubectl Edit](#kubectl-edit)
-- [ReplicaSet](#replicaset)
-- [DaemonSet](#daemonset)
-- [Rollouts e Rollbacks](#rollouts-e-rollbacks)
-
-# Deployments
-
-O **Deployment** é um recurso com a responsabilidade de instruir o Kubernetes a criar, atualizar e monitorar a saúde das instâncias de suas aplicações.
-
-Um Deployment é o responsável por gerenciar o seu **ReplicaSet** (que iremos falar logo menos), ou seja, o Deployment é quem vai determinar a configuração de sua aplicação e como ela será implementada. O Deployment é o **controller** que irá cuidar, por exemplo, uma instância de sua aplicação por algum motivo for interrompida. O **Deployment controller** irá identificar o problema com a instância e irá criar uma nova em seu lugar.
-
-Quando você utiliza o ``kubectl create deployment``, você está realizando o deploy de um objeto chamado **Deployment**. Como outros objetos, o Deployment também pode ser criado através de um arquivo [YAML](https://en.wikipedia.org/wiki/YAML) ou de um [JSON](https://www.json.org/json-en.html), conhecidos por **manifestos**.
-
-Se você deseja alterar alguma configuração de seus objetos, como o pod, você pode utilizar o ``kubectl apply``, através de um manifesto, ou ainda através do ``kubectl edit``. Normalmente, quando você faz uma alteração em seu Deployment, é criado uma nova versão do ReplicaSet, esse se tornando o ativo e fazendo com que seu antecessor seja desativado. As versões anteriores dos ReplicaSets são mantidas, possibilitando o _rollback_ em caso de falhas.
-
-As **labels** são importantes para o gerenciamento do cluster, pois com elas é possível buscar ou selecionar recursos em seu cluster, fazendo com que você consiga organizar em pequenas categorias, facilitando assim a sua busca e organizando seus pods e seus recursos do cluster. As labels não são recursos do API server, elas são armazenadas no metadata em formato chave-valor.
-
-Antes nos tínhamos somente o RC, _Replication Controller_, que era um controle sobre o número de réplicas que determinado pod estava executando, o problema é que todo esse gerenciamento era feito do lado do *client*. Para solucionar esse problema, foi adicionado o objeto Deployment, que permite a atualização pelo lado do *server*. **Deployments** geram **ReplicaSets**, que oferecerem melhores opções do que o **ReplicationController**, e por esse motivo está sendo substituído.
-
-Podemos criar nossos deployments a partir do template:
-
-```
-kubectl create deployment --dry-run=client -o yaml --image=nginx nginx-template > primeiro-deployment-template.yaml
-kubectl create -f primeiro-deployment-template.yaml
-```
-
-Vamos criar os nossos primeiros Deployments:
-```
-vim primeiro-deployment.yaml
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- labels:
- run: nginx
- app: giropops
- name: primeiro-deployment
- namespace: default
-spec:
- replicas: 1
- selector:
- matchLabels:
- run: nginx
- template:
- metadata:
- labels:
- run: nginx
- dc: UK
- spec:
- containers:
- - image: nginx
- imagePullPolicy: Always
- name: nginx2
- ports:
- - containerPort: 80
- protocol: TCP
- resources: {}
- terminationMessagePath: /dev/termination-log
- terminationMessagePolicy: File
- dnsPolicy: ClusterFirst
- restartPolicy: Always
- schedulerName: default-scheduler
- securityContext: {}
- terminationGracePeriodSeconds: 30
-```
-
-Vamos criar o deployment a partir do manifesto:
-
-```
-kubectl create -f primeiro-deployment.yaml
-
-deployment.extensions/primeiro-deployment created
-```
-
-Crie um segundo deployment:
-
-```
-vim segundo-deployment.yaml
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- labels:
- run: nginx
- name: segundo-deployment
- namespace: default
-spec:
- replicas: 1
- selector:
- matchLabels:
- run: nginx
- template:
- metadata:
- labels:
- run: nginx
- dc: Netherlands
- spec:
- containers:
- - image: nginx
- imagePullPolicy: Always
- name: nginx2
- ports:
- - containerPort: 80
- protocol: TCP
- resources: {}
- terminationMessagePath: /dev/termination-log
- terminationMessagePolicy: File
- dnsPolicy: ClusterFirst
- restartPolicy: Always
- schedulerName: default-scheduler
- securityContext: {}
- terminationGracePeriodSeconds: 30
-```
-
-Vamos criar o deployment a partir do manifesto:
-
-```
-kubectl create -f segundo-deployment.yaml
-
-deployment.extensions/segundo-deployment created
-```
-
-Visualizando os deployments:
-
-```
-kubectl get deployment
-
-NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
-primeiro-deployment 1 1 1 1 6m
-segundo-deployment 1 1 1 1 1m
-```
-
-Visualizando os pods:
-
-```
-kubectl get pods
-
-NAME READY STATUS RESTARTS AGE
-primeiro-deployment-68c9dbf8b8-kjqpt 1/1 Running 0 19s
-segundo-deployment-59db86c584-cf9pp 1/1 Running 0 15s
-```
-
-Visualizando os detalhes do ``pod`` criado a partir do **primeiro deployment**:
-
-```
-kubectl describe pod primeiro-deployment-68c9dbf8b8-kjqpt
-
-Name: primeiro-deployment-68c9dbf8b8-kjqpt
-Namespace: default
-Priority: 0
-PriorityClassName:
-Node: elliot-02/10.138.0.3
-Start Time: Sat, 04 Aug 2018 00:45:29 +0000
-Labels: dc=UK
- pod-template-hash=2475869464
- run=nginx
-Annotations:
-Status: Running
-IP: 10.46.0.1
-Controlled By: ReplicaSet/primeiro-deployment-68c9dbf8b8
-Containers:
- nginx2:
- Container ID: docker://963ec997a0aa4aa3cecabdb3c59f67d80e7010c51eac23735524899f7f2dd4f9
- Image: nginx
- Image ID: docker-pullable://nginx@sha256:d85914d547a6c92faa39ce7058bd7529baacab7e0cd4255442b04577c4d1f424
- Port: 80/TCP
- Host Port: 0/TCP
- State: Running
- Started: Sat, 04 Aug 2018 00:45:36 +0000
- Ready: True
- Restart Count: 0
- Environment:
- Mounts:
- /var/run/secrets/kubernetes.io/serviceaccount from default-token-np77m (ro)
-Conditions:
- Type Status
- Initialized True
- Ready True
- ContainersReady True
- PodScheduled True
-Volumes:
- default-token-np77m:
- Type: Secret (a volume populated by a Secret)
- SecretName: default-token-np77m
- Optional: false
-QoS Class: BestEffort
-Node-Selectors:
-Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
- node.kubernetes.io/unreachable:NoExecute for 300s
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal Scheduled 51s default-scheduler Successfully assigned default/primeiro-deployment-68c9dbf8b8-kjqpt to elliot-02
- Normal Pulling 50s kubelet, elliot-02 pulling image "nginx"
- Normal Pulled 44s kubelet, elliot-02 Successfully pulled image "nginx"
- Normal Created 44s kubelet, elliot-02 Created container
- Normal Started 44s kubelet, elliot-02 Started container
-```
-
-Visualizando os detalhes do ``pod`` criado a partir do **segundo deployment**:
-
-```
-kubectl describe pod segundo-deployment-59db86c584-cf9pp
-
-Name: segundo-deployment-59db86c584-cf9pp
-Namespace: default
-Priority: 0
-PriorityClassName:
-Node: elliot-02/10.138.0.3
-Start Time: Sat, 04 Aug 2018 00:45:49 +0000
-Labels: dc=Netherlands
- pod-template-hash=1586427140
- run=nginx
-Annotations:
-Status: Running
-IP: 10.46.0.2
-Controlled By: ReplicaSet/segundo-deployment-59db86c584
-Containers:
- nginx2:
- Container ID: docker://a9e6b5463341e62eff9e45c8c0aace14195f35e41be088ca386949500a1f2bb0
- Image: nginx
- Image ID: docker-pullable://nginx@sha256:d85914d547a6c92faa39ce7058bd7529baacab7e0cd4255442b04577c4d1f424
- Port: 80/TCP
- Host Port: 0/TCP
- State: Running
- Started: Sat, 04 Aug 2018 00:45:51 +0000
- Ready: True
- Restart Count: 0
- Environment:
- Mounts:
- /var/run/secrets/kubernetes.io/serviceaccount from default-token-np77m (ro)
-Conditions:
- Type Status
- Initialized True
- Ready True
- ContainersReady True
- PodScheduled True
-Volumes:
- default-token-np77m:
- Type: Secret (a volume populated by a Secret)
- SecretName: default-token-np77m
- Optional: false
-QoS Class: BestEffort
-Node-Selectors:
-Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
- node.kubernetes.io/unreachable:NoExecute for 300s
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal Scheduled 2m default-scheduler Successfully assigned default/segundo-deployment-59db86c584-cf9pp to elliot-02
- Normal Pulling 2m kubelet, elliot-02 pulling image "nginx"
- Normal Pulled 2m kubelet, elliot-02 Successfully pulled image "nginx"
- Normal Created 2m kubelet, elliot-02 Created container
- Normal Started 2m kubelet, elliot-02 Started container
-```
-
-Visualizando os detalhes do **primeiro deployment**:
-
-```
-kubectl describe deployment primeiro-deployment
-
-Name: primeiro-deployment
-Namespace: default
-CreationTimestamp: Sat, 04 Aug 2018 00:45:29 +0000
-Labels: app=giropops
- run=nginx
-Annotations: deployment.kubernetes.io/revision=1
-Selector: run=nginx
-Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
-StrategyType: RollingUpdate
-MinReadySeconds: 0
-RollingUpdateStrategy: 1 max unavailable, 1 max surge
-Pod Template:
- Labels: dc=UK
- run=nginx
- Containers:
- nginx2:
- Image: nginx
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-Conditions:
- Type Status Reason
- ---- ------ ------
- Available True MinimumReplicasAvailable
- Progressing True NewReplicaSetAvailable
-OldReplicaSets:
-NewReplicaSet: primeiro-deployment-68c9dbf8b8 (1/1 replicas created)
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ScalingReplicaSet 3m deployment-controller Scaled up replica set primeiro-deployment-68c9dbf8b8 to 1
-```
-
-Visualizando os detalhes do **segundo deployment**:
-
-```
-kubectl describe deployment segundo-deployment
-
-Name: segundo-deployment
-Namespace: default
-CreationTimestamp: Sat, 04 Aug 2018 00:45:49 +0000
-Labels: run=nginx
-Annotations: deployment.kubernetes.io/revision=1
-Selector: run=nginx
-Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
-StrategyType: RollingUpdate
-MinReadySeconds: 0
-RollingUpdateStrategy: 1 max unavailable, 1 max surge
-Pod Template:
- Labels: dc=Netherlands
- run=nginx
- Containers:
- nginx2:
- Image: nginx
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-Conditions:
- Type Status Reason
- ---- ------ ------
- Available True MinimumReplicasAvailable
- Progressing True NewReplicaSetAvailable
-OldReplicaSets:
-NewReplicaSet: segundo-deployment-59db86c584 (1/1 replicas created)
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal ScalingReplicaSet 3m deployment-controller Scaled up replica set segundo-deployment-59db86c584 to 1
-```
-
-## Filtrando por Labels
-
-Quando criamos nossos Deployments adicionamos as seguintes labels:
-
-```yaml
- labels:
- run: nginx
- dc: UK
----
- labels:
- run: nginx
- dc: Netherlands
-```
-
-As Labels são utilizadas para a organização do cluster, vamos listar nossos pods procurando pelas Labels.
-
-Primeiro vamos realizar uma pesquisa utilizando as labels ``dc=UK`` e ``dc=Netherlands``:
-
-Pesquisando pela label ``UK``:
-
-```
-kubectl get pods -l dc=UK
-
-NAME READY STATUS RESTARTS AGE
-primeiro-deployment-68c9dbf8b8-kjqpt 1/1 Running 0 3m
-```
-
-Pesquisando pela label ``Netherlands``:
-
-```
-kubectl get pods -l dc=Netherlands
-
-NAME READY STATUS RESTARTS AGE
-segundo-deployment-59db86c584-cf9pp 1/1 Running 0 4m
-```
-
-Caso queira uma saída mais personalizada podemos listar da seguinte forma, veja:
-
-```
-kubectl get pod -L dc
-
-NAME READY STATUS RESTARTS AGE DC
-primeiro-deployment-68c9... 1/1 Running 0 5m UK
-segundo-deployment-59db ... 1/1 Running 0 5m Netherlands
-```
-
-## Node Selector
-
-O **Node Selector** é uma forma de classificar nossos nodes como por exemplo nosso node ``elliot-02`` que possui disco **SSD** e está localizado no DataCenter ``UK``, e o node ``elliot-03`` que possui disco **HDD** e está localizado no DataCenter ``Netherlands``.
-
-Agora que temos essas informações vamos criar essas labels em nossos nodes, para utilizar o ``nodeSelector``.
-
-Criando a label ``disk`` com o valor ``SSD`` no worker 1:
-
-```
-kubectl label node elliot-02 disk=SSD
-
-node/elliot-02 labeled
-```
-
-Criando a label ``dc`` com o valor ``UK`` no worker 1:
-
-```
-kubectl label node elliot-02 dc=UK
-
-node/elliot-02 labeled
-```
-
-Criando a label ``dc`` com o valor ``Netherlands`` no worker 2:
-
-```
-kubectl label node elliot-03 dc=Netherlands
-
-node/elliot-03 labeled
-```
-
-Criando a label ``disk`` com o valor ``hdd`` no worker 2:
-
-```
-kubectl label nodes elliot-03 disk=hdd
-
-node/elliot-03 labeled
-```
-
-Opa! Acabamos declarando o ``disk=hdd`` em letra minúscula, como arrumamos isso? Subscrevendo a label como no comando a seguir.
-
-```
-kubectl label nodes elliot-03 disk=HDD --overwrite
-
-node/elliot-03 labeled
-```
-
-Para saber as labels configuradas em cada node basta executar o seguinte comando:
-
-No worker 1:
-
-```
-kubectl label nodes elliot-02 --list
-
-dc=UK
-disk=SSD
-kubernetes.io/hostname=elliot-02
-beta.kubernetes.io/arch=amd64
-beta.kubernetes.io/os=linux
-```
-
-No worker 2:
-
-```
-kubectl label nodes elliot-03 --list
-
-beta.kubernetes.io/os=linux
-dc=Netherlands
-disk=HDD
-kubernetes.io/hostname=elliot-03
-beta.kubernetes.io/arch=amd64
-```
-
-Agora, basta realizar o deploy novamente, porém antes vamos adicionar duas novas opções ao YAML e vamos ver a mágica acontecer. O nosso pod irá ser criado no node ``elliot-02``, onde possui a label ``disk=SSD``.
-
-Crie o arquivo ``terceiro-deployment.yaml``:
-
-```
-vim terceiro-deployment.yaml
-```
-
-Informe o seguinte conteúdo:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- labels:
- run: nginx
- name: terceiro-deployment
- namespace: default
-spec:
- replicas: 1
- selector:
- matchLabels:
- run: nginx
- template:
- metadata:
- creationTimestamp: null
- labels:
- run: nginx
- dc: Netherlands
- spec:
- containers:
- - image: nginx
- imagePullPolicy: Always
- name: nginx2
- ports:
- - containerPort: 80
- protocol: TCP
- resources: {}
- terminationMessagePath: /dev/termination-log
- terminationMessagePolicy: File
- dnsPolicy: ClusterFirst
- restartPolicy: Always
- schedulerName: default-scheduler
- securityContext: {}
- terminationGracePeriodSeconds: 30
- nodeSelector:
- disk: SSD
-```
-
-Crie o deployment a partir do manifesto:
-
-```
-kubectl create -f terceiro-deployment.yaml
-
-deployment.extensions/terceiro-deployment created
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl get pods -o wide
-
-NAME READY STATUS RESTARTS AGE IP NODE
-primeiro-deployment-56d9... 1/1 Running 0 14m 172.17.0.4 elliot-03
-segundo-deployment-869f... 1/1 Running 0 14m 172.17.0.5 elliot-03
-terceiro-deployment-59cd... 1/1 Running 0 22s 172.17.0.6 elliot-02
-```
-
-Removendo a label ``dc`` de um node worker:
-
-```
-kubectl label nodes elliot-02 dc-
-```
-
-Removendo uma determinada label de todos os nodes:
-
-```
-kubectl label nodes --all dc-
-```
-
-Agora imagine as infinitas possibilidades que isso poderá lhe proporcionar… Já estou pensando em várias, como por exemplo se é produção ou não, se consome muita CPU ou muita RAM, se precisa estar em determinado rack e por aí vai. 😃
-
-Simples como voar, não?
-
-## Kubectl Edit
-
-Agora vamos fazer o seguinte, vamos utilizar o comando ``kubectl edit`` para editar nosso primeiro deployment, digamos que a "quente" com o pod ainda em execução.
-
-```
-kubectl edit deployment primeiro-deployment
-```
-
-Abriu um editor, correto? Vamos alterar a label ``DC``. Vamos imaginar que esse Deployment agora rodará no ``DC`` de ``Netherlands``. Precisamos adicionar a ``Label`` e o ``nodeSelector``.
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-spec:
- replicas: 1
- selector:
- matchLabels:
- run: nginx
- strategy:
- rollingUpdate:
- maxSurge: 1
- maxUnavailable: 1
- type: RollingUpdate
- template:
- metadata:
- creationTimestamp: null
- labels:
- dc: Netherlands
- app: giropops
- run: nginx
-spec:
- containers:
- - image: nginx
- imagePullPolicy: Always
- name: nginx2
- ports:
- - containerPort: 80
- protocol: TCP
- resources: {}
- terminationMessagePath: /dev/termination-log
- terminationMessagePolicy: File
- dnsPolicy: ClusterFirst
- nodeSelector:
- dc: Netherlands
-...
-
-deployment.extensions/primeiro-deployment edited
-```
-
-Como podemos ver mudamos o valor da label ``dc`` e também modificamos o ``nodeSelector``, onde ele agora subirá no node que tiver a label ``dc`` com o valor ``Netherlands``, fácil! 😀
-
-Veja se o resultado foi conforme esperado:
-
-```
-kubectl get pods -l dc=Netherlands -o wide
-
-NAME READY STATUS RESTARTS AGE ..NODE
-primeiro-deployment-7.. 1/1 Running 0 3m elliot-03
-segundo-deployment-5.. 1/1 Running 0 49m elliot-02
-terceiro-deployment-5.. 1/1 Running 0 14m elliot-02
-```
-
-Com certeza, esse pod foi criado no node ``elliot-03``, pois havíamos dito que ele possuía essa label anteriormente.
-
-# ReplicaSet
-
-O **ReplicaSet** garante a quantidade solicitada de pods e os recursos necessários para um Deployment. Uma vez que o Deployment é criado, é o ReplicaSet que controla a quantidade de pods em execução, caso algum pod seja finalizado, ele que irá detectar e solicitar que outro pod seja executado em seu lugar, garantindo assim a quantidade de réplicas solicitadas.
-
-Vamos criar nosso primeiro ReplicaSet:
-
-```
-vim primeiro-replicaset.yaml
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: apps/v1
-kind: ReplicaSet
-metadata:
- name: replica-set-primeiro
-spec:
- replicas: 3
- selector:
- matchLabels:
- system: Giropops
- template:
- metadata:
- labels:
- system: Giropops
- spec:
- containers:
- - name: nginx
- image: nginx:1.7.9
- ports:
- - containerPort: 80
-```
-
-Crie o ReplicaSet a partir do manifesto:
-
-```
-kubectl create -f primeiro-replicaset.yaml
-
-replicaset.extensions/replica-set-primeiro created
-```
-
-Visualizando o ReplicaSet:
-
-```
-kubectl get replicaset
-
-NAME DESIRED CURRENT READY AGE
-replica-set-primeiro 3 3 1 2s
-```
-
-Podemos observar os pods em execução:
-
-```
-kubectl get pods
-
-NAME READY STATUS RESTARTS AGE
-replica-set-primeiro-6drmt 1/1 Running 0 12s
-replica-set-primeiro-7j59w 1/1 Running 0 12s
-replica-set-primeiro-mg8q9 1/1 Running 0 12s
-```
-
-Temos exatamente 3 pods do ``nginx`` rodando simultaneamente.
-
-Podemos obter mais informações do nosso ReplicaSet utilizando o comando ``describe``.
-
-```
-kubectl describe rs replica-set-primeiro
-
-Name: replica-set-primeiro
-Namespace: default
-Selector: system=Giropops
-Labels: system=Giropops
-Annotations:
-Replicas: 3 current / 3 desired
-Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
-Pod Template:
- Labels: system=Giropops
- Containers:
- nginx:
- Image: nginx:1.7.9
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SuccessfulCreate 31s replicaset-controller Created pod: replica-set-primeiro-mg8q9
- Normal SuccessfulCreate 31s replicaset-controller Created pod: replica-set-primeiro-6drmt
- Normal SuccessfulCreate 31s replicaset-controller Created pod: replica-set-primeiro-7j59w
-```
-
-Assim podemos ver todos os pods associados ao ReplicaSet, e se excluirmos um desses Pods, o que será que acontece? Vamos testar:
-
-```
-kubectl delete pod replica-set-primeiro-6drmt
-
-pod "replica-set-primeiro-6drmt" deleted
-```
-
-Agora vamos verificar novamente os Pods em execução:
-
-```
-kubectl get pods -l system=Giropops
-
-NAME READY STATUS RESTARTS AGE
-replica-set-primeiro-7j59w 1/1 Running 0 1m
-replica-set-primeiro-mg8q9 1/1 Running 0 1m
-replica-set-primeiro-s5dz2 1/1 Running 0 15s
-```
-
-Percebeu que ele recriou outro Pod? O **ReplicaSet** faz com que sempre tenha 3 pods disponíveis.
-
-Vamos alterar para 4 réplicas e recriar o ReplicaSet, para isso vamos utilizar o ``kubectl edit`` visto anteriormente, assim podemos alterar o ReplicaSet já em execução.
-
-```
-kubectl edit rs replica-set-primeiro
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: apps/v1
-kind: ReplicaSet
-metadata:
- creationTimestamp: 2018-07-05T04:32:42Z
- generation: 2
- labels:
- system: Giropops
- name: replica-set-primeiro
- namespace: default
- resourceVersion: "471758"
- selfLink: /apis/extensions/v1beta1/namespaces/default/replicasets/replica-set-primeiro
- uid: 753290c1-800c-11e8-b889-42010a8a0002
-spec:
- replicas: 4
- selector:
- matchLabels:
- system: Giropops
- template:
- metadata:
- creationTimestamp: null
- labels:
- system: Giropops
-...
-
-replicaset.extensions/replica-set-primeiro edited
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl get pods -l system=Giropops
-
-NAME READY STATUS RESTARTS AGE
-replica-set-primeiro-7j59w 1/1 Running 0 2m
-replica-set-primeiro-96hj7 1/1 Running 0 10s
-replica-set-primeiro-mg8q9 1/1 Running 0 2m
-replica-set-primeiro-s5dz2 1/1 Running 0 1m
-```
-
-Veja que ele não cria um deployment para esse replicaset:
-
-```
-kubectl get deployment.apps
-```
-
-Perceba que não é listado um deployment relacionado ao ``replica-set-primeiro``.
-
-Agora vamos editar um dos pods e modificar a versão da imagem do Nginx que estamos utilizando no exemplo. Vamos alterar de ``image: nginx:1.7.9_`` para ``image: nginx:1.15.0`` utilizando o ``kubectl edit``. Editando o pod:
-
-```
-kubectl edit pod replica-set-primeiro-7j59w
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: replica-set-primeiro
-...
- spec:
- containers:
- - name: nginx
- image: nginx:1.15.0
- ports:
- - containerPort: 80
-...
-
-pod/replica-set-primeiro-7j59w edited
-```
-
-Agora vamos observar novamente os pods, como estão?
-
-```
-kubectl get pods -l system=Giropops
-
-NAME READY STATUS RESTARTS AGE
-replica-set-primeiro-7j59w 1/1 Running 1 8m
-replica-set-primeiro-96hj7 1/1 Running 0 6m
-replica-set-primeiro-mg8q9 1/1 Running 0 8m
-replica-set-primeiro-s5dz2 1/1 Running 0 7m
-```
-
-Aparentemente nada aconteceu concordam? Vamos detalhar melhor esse pod que acabamos de alterar:
-
-```
-kubectl describe pod replica-set-primeiro-7j59w
-
-Name: replica-set-primeiro-7j59w
-Namespace: default
-Priority: 0
-PriorityClassName:
-Node: elliot-02/10.138.0.3
-Start Time: Sat, 04 Aug 2018 01:47:56 +0000
-Labels: system=Giropops
-Annotations:
-Status: Running
-IP: 10.46.0.2
-Controlled By: ReplicaSet/replica-set-primeiro
-Containers:
- nginx:
- Container ID: docker://6991b627cf4d6daca039ab9d6336929c0de1fc279c55a451cf9c7304e1c46504
- Image: nginx:1.15.0
-...
-Successfully assigned default/replica-set-primeiro-7j59w to elliot-02
- Normal Pulled 9m kubelet, elliot-02 Container image "nginx:1.7.9" already present on machine
- Normal Killing 1m kubelet, elliot-02 Killing container with id docker://nginx:Container spec hash changed (3238050430 vs 811632170).. Container will be killed and recreated.
- Normal Pulling 1m kubelet, elliot-02 pulling image "nginx:1.15.0"
- Normal Created 1m (x2 over 9m) kubelet, elliot-02 Created container
- Normal Started 1m (x2 over 9m) kubelet, elliot-02 Started container
- Normal Pulled 1m kubelet, elliot-02 Successfully pulled image "nginx:1.15.0"
-```
-
-Como podemos observar ele alterou a imagem do nginx do **1.7.9** para **1.15.0**, como o replicaset não tem um deployment ele apenas destruiu o contêiner sem destruir o pod, então a configuração passada manualmente é uma configuração válida, mas caso o pod seja removido o ReplicaSet vai recriá-lo com as configurações originais.
-
-Vamos apagar o pod e ver se realmente acontece isso:
-
-```
-kubectl delete pod replica-set-primeiro-7j59w
-
-pod "replica-set-primeiro-7j59w" delete
-```
-
-Visualizando os pods:
-
-```
-kubectl get pods -l system=Giropops
-
-NAME READY STATUS RESTARTS AGE
-replica-set-primeiro-96hj7 1/1 Running 0 12m
-replica-set-primeiro-mg8q9 1/1 Running 0 14m
-replica-set-primeiro-s5dz2 1/1 Running 0 13m
-replica-set-primeiro-xzfvg 1/1 Running 0 5s
-```
-
-Visualizando os detalhes do pods:
-
-```
-kubectl describe pod replica-set-primeiro-xzfvg
-
-Name: replica-set-primeiro-xzfvg
-Namespace: default
-Priority: 0
-PriorityClassName:
-Node: elliot-02/10.138.0.3
-Start Time: Sat, 04 Aug 2018 02:02:35 +0000
-Labels: system=Giropops
-Annotations:
-Status: Running
-IP: 10.46.0.2
-Controlled By: ReplicaSet/replica-set-primeiro
-Containers:
- nginx:
- Container ID: docker://e8b88065640ba3ea346c93bb368ae6b7fb7b1d9507a948d891ca632df0dfc071
- Image: nginx:1.7.9
-...
-```
-
-Olha só, o novo pod foi criado com a imagem configurada no replicaset.
-
-Agora vamos apagar nosso ReplicaSet:
-
-```
-kubectl get rs
-
-NAME DESIRED CURRENT READY AGE
-replica-set-primeiro 4 4 4 25m
-```
-
-```
-kubectl delete rs replica-set-primeiro
-
-replicaset.apps "replica-set-primeiro" deleted
-```
-
-# DaemonSet
-
-**DaemonSet** é basicamente a mesma coisa do que o ReplicaSet, com a diferença que quando você utiliza o DaemonSet você não especifica o número de réplicas, ele subirá um pod por node em seu cluster.
-
-É sempre interessante quando criar usar e abusar das labels, assim você conseguirá ter melhor flexibilidade na distribuição mais adequada de sua aplicação.
-
-Ele é bem interessante para serviços que necessitem rodar em todos os nodes do cluster, como por exemplo, coletores de logs e agentes de monitoração.
-
-Vamos criar o nosso primeiro DaemonSet:
-
-```
-vim primeiro-daemonset.yaml
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
- name: daemon-set-primeiro
-spec:
- selector:
- matchLabels:
- system: Strigus
- template:
- metadata:
- labels:
- system: Strigus
- spec:
- tolerations:
- - key: node-role.kubernetes.io/master
- effect: NoSchedule
- containers:
- - name: nginx
- image: nginx:1.7.9
- ports:
- - containerPort: 80
-```
-
-Caso não queria utilizar a diretiva 'tolerations', podemos também utilizar a remoção do taint nas masters como a seguir:
-
-```
-kubectl taint nodes --all node-role.kubernetes.io/master-
-
-node/elliot-01 untainted
-taint "node-role.kubernetes.io/master:" not found
-taint "node-role.kubernetes.io/master:" not found
-```
-
-Agora podemos criar nosso DaemonSet:
-
-```
-kubectl create -f primeiro-daemonset.yaml
-
-daemonset.extensions/daemon-set-primeiro created
-```
-
-Vamos listar nossos DaemonSet:
-
-```
-kubectl get daemonset
-
-NAME DESIRED CURRENT READY UP-TO-DATE ... AGE
-daemon-set-primeiro 3 3 3 3 30s
-```
-
-Visualizando os detalhes do DaemonSet:
-
-```
-kubectl describe ds daemon-set-primeiro
-
-Name: daemon-set-primeiro
-Selector: system=Strigus
-Node-Selector:
-Labels: system=Strigus
-Annotations:
-Desired Number of Nodes Scheduled: 3
-Current Number of Nodes Scheduled: 3
-Number of Nodes Scheduled with Up-to-date Pods: 3
-Number of Nodes Scheduled with Available Pods: 3
-Number of Nodes Misscheduled: 0
-Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
-Pod Template:
- Labels: system=Strigus
- Containers:
- nginx:
- Image: nginx:1.7.9
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SuccessfulCreate 41s daemonset-controller Created pod: daemon-set-primeiro-jl6f5
- Normal SuccessfulCreate 412 daemonset-controller Created pod: daemon-set-primeiro-jh2sp
- Normal SuccessfulCreate 412 daemonset-controller Created pod: daemon-set-primeiro-t9rv9
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl get pods -o wide
-
-NAME READY STATUS RESTARTS AGE .. NODE
-daemon-set-primeiro.. 1/1 Running 0 1m elliot-01
-daemon-set-primeiro.. 1/1 Running 0 1m elliot-02
-daemon-set-primeiro.. 1/1 Running 0 1m elliot-03
-```
-
-Como podemos observar temos um pod por nó rodando nosso ``daemon-set-primeiro``.
-
-Vamos alterar a imagem desse pod diretamente no DaemonSet, usando o comando ``kubectl set``:
-
-```
-kubectl set image ds daemon-set-primeiro nginx=nginx:1.15.0
-
-daemonset.extensions/daemon-set-primeiro image updated
-```
-
-Vamos confirmar se a imagem foi realmente alterada:
-
-```
-kubectl describe ds daemon-set-primeiro
-
-Name: daemon-set-primeiro
-Selector: system=Strigus
-Node-Selector:
-Labels: system=Strigus
-Annotations:
-Desired Number of Nodes Scheduled: 3
-Current Number of Nodes Scheduled: 3
-Number of Nodes Scheduled with Up-to-date Pods: 0
-Number of Nodes Scheduled with Available Pods: 3
-Number of Nodes Misscheduled: 0
-Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
-Pod Template:
- Labels: system=Strigus
- Containers:
- nginx:
- Image: nginx:1.15.0
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SuccessfulCreate 2m daemonset-controller Created pod: daemon-set-primeiro-jl6f5
- Normal SuccessfulCreate 2m daemonset-controller Created pod: daemon-set-primeiro-jh2sp
- Normal SuccessfulCreate 2m daemonset-controller Created pod: daemon-set-primeiro-t9rv9
-```
-
-Agora vamos verificar se as imagens dos pods estão atualizadas:
-
-```
-kubectl get pods
-
-NAME READY STATUS RESTARTS AGE
-daemon-set-primeiro-jh2sp 1/1 Running 0 2m
-daemon-set-primeiro-jl6f5 1/1 Running 0 2m
-daemon-set-primeiro-t9rv9 1/1 Running 0 2m
-```
-
-Como podemos observar não tivemos nenhum restart nos pods.
-
-Vamos verificar a imagem executando em um dos pods:
-
-```
-kubectl describe pod daemon-set-primeiro-jh2sp | grep -i image:
-
-Image: nginx:1.7.9
-```
-
-Exatamente, Não conseguimos alterar informações do DaemonSet em execução.
-
-E se o pod for deletado?
-
-```
-kubectl delete pod daemon-set-primeiro-jh2sp
-
-pod "daemon-set-primeiro-jh2sp" deleted
-```
-
-Visualizando os pods:
-
-```
-kubectl get pods
-
-NAME READY STATUS RESTARTS AGE
-daemon-set-primeiro-hp4qc 1/1 Running 0 3s
-daemon-set-primeiro-jl6f5 1/1 Running 0 10m
-daemon-set-primeiro-t9rv9 1/1 Running 0 10m
-```
-
-Vamos listar o novo Pod que foi criado, após deletarmos o Pod antigo:
-
-```
-kubectl describe pod daemon-set-primeiro-hp4qc | grep -i image:
-
- Image: nginx:1.15.0
-```
-
-Agora um Pod que já estava em execução:
-
-```
-kubectl describe pod daemon-set-primeiro-jl6f5 | grep -i image:
-
- Image: nginx:1.7.9
-```
-
-Como podemos observar, para atualizar todos os pods do DaemonSet precisamos recriá-lo ou destruir todos os pods relacionado a ele, mas isso não é muito ruim? Sim, é bem ruim. Para melhorar nossas vidas temos a opção ``RollingUpdate`` que vamos ver no próximo capítulo.
-
-# Rollouts e Rollbacks
-
-Agora vamos imaginar que essa nossa última edição utilizando o comando ``kubectl set`` no DaemonSet não foi correta e precisamos voltar a configuração anterior, onde a versão da imagem era outra, como faremos?
-
-É muito simples, para isso existe o _Rollout_. Com ele você pode verificar quais foram as modificações que aconteceram em seu Deployment ou DaemonSet, como se fosse um versionamento. Vejaaaa! (Com a voz do Nelson Rubens)
-
-```
-kubectl rollout history ds daemon-set-primeiro
-
-daemonsets "daemon-set-primeiro"
-REVISION CHANGE-CAUSE
-1
-2
-```
-
-Ele irá mostrar duas linhas, a primeira que é a original, com a imagem do ``nginx:1.7.9`` e a segunda já com a imagem ``nginx:1.15.0``. As informações não estão muito detalhadas concordam?
-
-Veja como verificar os detalhes de cada uma dessas entradas, que são chamadas de **revision**.
-
-Visualizando a revision 1:
-
-```
-kubectl rollout history ds daemon-set-primeiro --revision=1
-
-daemonsets "daemon-set-primeiro" with revision #1
-Pod Template:
- Labels: system=DaemonOne
- Containers:
- nginx:
- Image: nginx:1.7.9
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-```
-
-Visualizando a revision 2:
-
-```
-kubectl rollout history ds daemon-set-primeiro --revision=2
-
-daemonsets "daemon-set-primeiro" with revision #2
-Pod Template:
- Labels: system=DaemonOne
- Containers:
- nginx:
- Image: nginx:1.15.0
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-```
-
-Para voltar para a ``revision`` desejada, basta fazer o seguinte:
-
-```
-kubectl rollout undo ds daemon-set-primeiro --to-revision=1
-
-daemonset.extensions/daemon-set-primeiro rolled back
-```
-
-Perceba que trocamos o ``history`` por ``undo`` e o ``revision`` por ``to-revision``, assim faremos o **rollback** em nosso DaemonSet, e voltamos a versão da imagem que desejamos. 😃
-
----
-
->**Atenção!!!** Por padrão, o DaemonSet guarda apenas as 10 últimas revisions. Para alterar a quantidade máxima de revisions no nosso Daemonset, execute o seguinte comando.
-Fonte: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#clean-up-policy
-
----
-
-```
-kubectl edit daemonsets.apps daemon-set-primeiro
-```
-
-Altere a quantidade no parâmetro ``revisionHistoryLimit``:
-
-```yaml
- revisionHistoryLimit: 10
-```
-
----
-
-Voltando à nossa linha de raciocínio, para acompanhar o rollout, execute o seguinte comando:
-
-```
-kubectl rollout status ds daemon-set-primeiro
-```
-
-Vamos confirmar se já estamos executando a nova imagem e um dos nosso pods:
-
-```
-kubectl describe pod daemon-set-primeiro-hp4qc | grep -i image:
-
-Image: nginx:1.15.0
-```
-
-Não funcionou, por quê? Porque teremos que matar o Pod para ele ser recriado com as novas configuração.
-
-Vamos afinar esse nosso DaemonSet, vamos adicionar o ``RollingUpdate`` e esse cara vai atualizar automaticamente os Pods quando houver alguma alteração.
-
-Vamos lá, primeiro vamos remover o ``DaemonSet``, adicionar duas novas informações em nosso manifesto yaml e, em seguida, criar outro DaemonSet em seu lugar:
-
-```
-kubectl delete -f primeiro-daemonset.yaml
-
-daemonset.extensions "daemon-set-primeiro" deleted
-```
-
-Edite o arquivo ``primeiro-daemonset.yaml``.
-
-```
-vim primeiro-daemonset.yaml
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
- name: daemon-set-primeiro
-spec:
- selector:
- matchLabels:
- system: Strigus
- template:
- metadata:
- labels:
- system: Strigus
- spec:
- containers:
- - name: nginx
- image: nginx:1.7.9
- ports:
- - containerPort: 80
- updateStrategy:
- type: RollingUpdate
-```
-
-Crie o DaemonSet:
-
-```
-kubectl create -f primeiro-daemonset.yaml
-
-daemonset.extensions/daemon-set-primeiro created
-```
-
-Sucesso, vamos verificar se nosso DaemonSet foi inicializado certinho.
-
-```
-kubectl get daemonset
-
-NAME DESIRED CURRENT READY ... AGE
-daemon-set-primeiro 3 3 3 ... 5m
-```
-
-Visualizando os detalhes do DaemonSet:
-
-```
-kubectl describe ds daemon-set-primeiro
-
-Name: daemon-set-primeiro
-Selector: system=DaemonOne
-Node-Selector:
-Labels: system=DaemonOne
-Annotations:
-Desired Number of Nodes Scheduled: 3
-Current Number of Nodes Scheduled: 3
-Number of Nodes Scheduled with Up-to-date Pods: 3
-Number of Nodes Scheduled with Available Pods: 3
-Number of Nodes Misscheduled: 0
-Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
-Pod Template:
- Labels: system=DaemonOne
- Containers:
- nginx:
- Image: nginx:1.7.9
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SuccessfulCreate 5m daemonset-controller Created pod: daemon-set-primeiro-52k8k
- Normal SuccessfulCreate 5m daemonset-controller Created pod: daemon-set-primeiro-6sln2
- Normal SuccessfulCreate 5m daemonset-controller Created pod: daemon-set-primeiro-9v2w9
- daemonset-controller Created pod: daemon-set-primeiro-9dktj
-```
-
-Vamos verificar nossa recém adicionada configuração de ``RollingUpdate``:
-
-```
-kubectl get ds daemon-set-primeiro -o yaml | grep -A 2 Strategy
-
- updateStrategy:
- rollingUpdate:
- maxUnavailable: 1
-```
-
-Agora com nosso DaemonSet já configurado, vamos alterar aquela mesma imagem do ``nginx`` e ver o que acontece de fato:
-
-```
-kubectl set image ds daemon-set-primeiro nginx=nginx:1.15.0
-
-daemonset.extensions/daemon-set-primeiro image updated
-```
-
-Vamos listar o DaemonSet e os Pods para ter certeza de que nada se quebrou:
-
-```
-kubectl get daemonset
-
-NAME DESIRED CURRENT READY ... AGE
-daemon-set-primeiro 3 3 3 ... 6m
-```
-
-Visualizando os pods:
-
-```
-kubectl get pods -o wide
-
-NAME READY STATUS RESTARTS AGE NODE
-daemon-set-primeiro-7m... 1/1 Running 0 10s elliot-02
-daemon-set-primeiro-j7... 1/1 Running 0 10s elliot-03
-daemon-set-primeiro-v5... 1/1 Running 0 10s elliot-01
-```
-
-Como podemos observar nosso DaemonSet se manteve o mesmo, porém os Pods foram recriados, vamos detalhar o DaemonSet para visualizar as alterações realizadas.
-
-```
-kubectl describe ds daemon-set-primeiro
-
-Name: daemon-set-primeiro
-Selector: system=DaemonOne
-Node-Selector:
-Labels: system=DaemonOne
-Annotations:
-Desired Number of Nodes Scheduled: 3
-Current Number of Nodes Scheduled: 3
-Number of Nodes Scheduled with Up-to-date Pods: 3
-Number of Nodes Scheduled with Available Pods: 3
-Number of Nodes Misscheduled: 0
-Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
-Pod Template:
- Labels: system=DaemonOne
- Containers:
- nginx:
- Image: nginx:1.15.0
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-Events:
- Type Reason Age From Message
- ---- ------ ---- ---- -------
- Normal SuccessfulCreate 8m daemonset-controller Created pod: daemon-set-primeiro-52k8k
- Normal SuccessfulCreate 8m daemonset-controller Created pod: daemon-set-primeiro-6sln2
- Normal SuccessfulCreate 8m daemonset-controller Created pod: daemon-set-primeiro-9v2w9
- Normal SuccessfulDelete 10m daemonset-controller Deleted pod: daemon-set-primeiro-6sln2
- Normal SuccessfulCreate 1m daemonset-controller Created pod: daemon-set-primeiro-j788v
- Normal SuccessfulDelete 10m daemonset-controller Deleted pod: daemon-set-primeiro-52k8k
- Normal SuccessfulCreate 1m daemonset-controller Created pod: daemon-set-primeiro-7mpwr
- Normal SuccessfulDelete 10m daemonset-controller Deleted pod: daemon-set-primeiro-9v2w9
- Normal SuccessfulCreate 1m daemonset-controller Created pod: daemon-set-primeiro-v5m47
-```
-
-Olha que Bacana! Se observamos o campo **Events** podemos ver que o ``RollingUpdate`` matou os pods antigos e recriou com a nova imagem que alteramos utilizando o ``kubectl set``.
-
-Podemos também verificar em um dos Pods se essa alteração realmente aconteceu.
-
-```
-kubectl describe pod daemon-set-primeiro-j788v | grep -i image:
-
-Image: nginx:1.15.0
-```
-
-Viram? Muito sensacional esse negócio de ``RollingUpdate``.
-
-Vamos verificar nosso histórico de modificações:
-
-```
-kubectl rollout history ds daemon-set-primeiro
-
-daemonsets "daemon-set-primeiro"
-REVISION CHANGE-CAUSE
-1
-2
-```
-
-Sim, temos duas alterações. Vamos detalhar para saber qual é qual.
-
-Visualizando a revision 1:
-
-```
-kubectl rollout history ds daemon-set-primeiro --revision=1
-
-daemonsets "daemon-set-primeiro" with revision #1
-Pod Template:
- Labels: system=DaemonOne
- Containers:
- nginx:
- Image: nginx:1.7.9
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-```
-
-Visualizando a revision 2:
-
-```
-kubectl rollout history ds daemon-set-primeiro --revision=2
-
-daemonsets "daemon-set-primeiro" with revision #2
-Pod Template:
- Labels: system=DaemonOne
- Containers:
- nginx:
- Image: nginx:1.15.0
- Port: 80/TCP
- Host Port: 0/TCP
- Environment:
- Mounts:
- Volumes:
-```
-
-Agora vamos realizar o rollback do nosso DaemonSet para a revision 1:
-
-```
-kubectl rollout undo ds daemon-set-primeiro --to-revision=1
-
-daemonset.extensions/daemon-set-primeiro rolled back
- kubectl rollout undo ds daem kubectl rollout undo ds daem
- ```
-
-Visualizando os pods:
-
-```
-kubectl get pods
-
-NAME READY STATUS RESTARTS AGE
-daemon-set-primeiro-c2jjk 1/1 Running 0 19s
-daemon-set-primeiro-hrn48 1/1 Running 0 19s
-daemon-set-primeiro-t6mr9 1/1 Running 0 19s
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl describe pod daemon-set-primeiro-c2jjk | grep -i image:
-
-Image: nginx:1.7.9
-```
-
-Sensacional não?
-
-Deu ruim?
-
-Basta retornar para a outra configuração:
-
-```
-kubectl rollout undo ds daemon-set-primeiro --to-revision=2
-
-daemonset.extensions/daemon-set-primeiro rolled back
-```
-
-Visualizando o status do rollout:
-
-```
-kubectl rollout status ds daemon-set-primeiro
-
-daemon set "daemon-set-primeiro" successfully rolled out
-```
-
-Visualizando os pods:
-
-```
-kubectl get pods
-
-NAME READY STATUS RESTARTS AGE
-daemon-set-primeiro-jzck9 1/1 Running 0 32s
-daemon-set-primeiro-td7h5 1/1 Running 0 29s
-daemon-set-primeiro-v5c86 1/1 Running 0 40s
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl describe pod daemon-set-primeiro-jzck9 | grep -i image:
-
-Image: nginx:1.15.0
-```
-
-Agora vamos deletar nosso DaemonSet:
-
-```
-kubectl delete ds daemon-set-primeiro
-
-daemonset.extensions "daemon-set-primeiro" deleted
-```
diff --git a/pt/old/day_two/descomplicando_kubernetes.md b/pt/old/day_two/descomplicando_kubernetes.md
deleted file mode 100644
index 235516d1..00000000
--- a/pt/old/day_two/descomplicando_kubernetes.md
+++ /dev/null
@@ -1,1484 +0,0 @@
-# Descomplicando Kubernetes dia 2
-
-## Sumário
-
-- [Descomplicando Kubernetes dia 2](#descomplicando-kubernetes-dia-2)
- - [Sumário](#sumário)
-- [Componentes do K8s](#componentes-do-k8s)
-- [Principais Comandos](#principais-comandos)
-- [Container Network Interface](#container-network-interface)
-- [Services](#services)
- - [Criando um service ClusterIP](#criando-um-service-clusterip)
- - [Criando um service NodePort](#criando-um-service-nodeport)
- - [Criando um service LoadBalancer](#criando-um-service-loadbalancer)
- - [EndPoint](#endpoint)
-- [Limitando Recursos](#limitando-recursos)
-- [Namespaces](#namespaces)
-- [Kubectl taint](#kubectl-taint)
-- [Colocando o nó em modo de manutenção](#colocando-o-nó-em-modo-de-manutenção)
-
-# Componentes do K8s
-
-**O k8s tem os seguintes componentes principais:**
-
-* Master node
-* Worker node
-* Services
-* Controllers
-* Pods
-* Namespaces e quotas
-* Network e policies
-* Storage
-
-**[kube-apiserver](https://kubernetes.io/docs/concepts/overview/components/#kube-apiserver)** é a central de operações do cluster k8s. Todas as chamadas, internas ou externas são tratadas por ele. Ele é o único que conecta no ETCD.
-
-**[kube-scheduller](https://kubernetes.io/docs/concepts/overview/components/#kube-apiserver)** usa um algoritmo para verificar em qual node o pod deverá ser hospedado. Ele verifica os recursos disponíveis do node para verificar qual o melhor node para receber aquele pod.
-
-No **[ETCD](https://kubernetes.io/docs/concepts/overview/components/#etcd)** são armazenados o estado do cluster, rede e outras informações persistentes.
-
-**[kube-controller-manager](https://kubernetes.io/docs/concepts/overview/components/#cloud-controller-manager)** é o controle principal que interage com o ``kube-apiserver`` para determinar o seu estado. Se o estado não bate, o manager irá contactar o controller necessário para checar seu estado desejado. Tem diversos controllers em uso como: os endpoints, namespace e replication.
-
-O **[kubelet](https://kubernetes.io/docs/concepts/overview/components/#kubelet)** interage com o Docker instalado no node e garante que os contêineres que precisavam estar em execução realmente estão.
-
-O **[kube-proxy](https://kubernetes.io/docs/concepts/overview/components/#kube-proxy)** é o responsável por gerenciar a rede para os contêineres, é o responsável por expor portas dos mesmos.
-
-**[Supervisord](http://supervisord.org/)** é o responsável por monitorar e restabelecer, se necessário, o ``kubelet`` e o Docker. Por esse motivo, quando existe algum problema em relação ao kubelet, como por exemplo o uso do driver ``cgroup`` diferente do que está rodando no Docker, você perceberá que ele ficará tentando subir o kubelet frequentemente.
-
-**[Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/)** é a menor unidade que você irá tratar no k8s. Você poderá ter mais de um contêiner por Pod, porém vale lembrar que eles dividirão os mesmos recursos, como por exemplo IP. Uma das boas razões para se ter mais de um contêiner em um Pod é o fato de você ter os logs consolidados.
-
-O Pod, por poder possuir diversos contêineres, muitas das vezes se assemelha a uma VM, onde você poderia ter diversos serviços rodando compartilhando o mesmo IP e demais recursos.
-
-**[Services](https://kubernetes.io/docs/concepts/services-networking/service/)** é uma forma de você expor a comunicação através de um **NodePort** ou **LoadBalancer** para distribuir as requisições entre diversos Pods daquele Deployment. Funciona como um balanceador de carga.
-
-# Principais Comandos
-
-A figura a seguir mostra a estrutura dos principais comandos do ``kubectl``.
-
-|  |
-|:---------------------------------------------------------------------------------------------:|
-| *Principais comandos [Ref: uploaddeimagens.com.br](https://uploaddeimagens.com.br/images/002/667/919/full/Kubernetes-Comandos.png)* |
-
-# Container Network Interface
-
-Para prover a rede para os contêineres, o k8s utiliza a especificação do **CNI**, Container Network Interface.
-
-CNI é uma especificação que reúne algumas bibliotecas para o desenvolvimento de plugins para configuração e gerenciamento de redes para os contêineres. Ele provê uma interface comum entre as diversas soluções de rede para o k8s. Você encontra diversos plugins para AWS, GCP, Cloud Foundry entre outros.
-
-Mais informações em: [https://github.com/containernetworking/cni](https://github.com/containernetworking/cni)
-
-Enquanto o CNI define a rede dos pods, ele não te ajuda na comunicação entre os pods de diferentes nodes.
-
-As características básicas da rede do k8s são:
-
-* Todos os pods conseguem se comunicar entre eles em diferentes nodes;
-* Todos os nodes podem se comunicar com todos os pods;
-* Não utilizar NAT.
-
-Todos os IPs dos pods e nodes são roteados sem a utilização de [NAT](https://en.wikipedia.org/wiki/Network_address_translation). Isso é solucionado com a utilização de algum software que te ajudará na criação de uma rede Overlay. Seguem alguns:
-
-* [Weave](https://www.weave.works/docs/net/latest/kube-addon/)
-* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)
-* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)
-* [Calico](https://docs.projectcalico.org/latest/introduction/)
-* [Romana](http://romana.io/)
-* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)
-* [Contiv](http://contiv.github.io/)
-
-Mais informações em: [https://kubernetes.io/docs/concepts/cluster-administration/addons/](https://kubernetes.io/docs/concepts/cluster-administration/addons/)
-
-# Services
-
-## Criando um service ClusterIP
-
-Vamos criar um pod a partir de um pod template utilizando os seguintes comandos:
-
-```
-kubectl run nginx --image nginx --dry-run=client -o yaml > pod-template.yaml
-kubectl create -f pod-template.yaml
-pod/nginx created
-```
-
-Expondo o pod do Nginx.
-
-```
-kubectl expose pod nginx --port=80
-
-service/nginx exposed
-```
-
-Obtendo informações do service.
-
-```
-kubectl get svc
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 25m
-nginx ClusterIP 10.104.209.243 80/TCP 7m15s
-```
-
-Execute o seguinte comando para visualizar mais detalhes do service ``nginx``.
-
-```
-kubectl describe service nginx
-
-Name: nginx
-Namespace: default
-Labels: run=nginx
-Annotations:
-Selector: run=nginx
-Type: ClusterIP
-IP: 10.104.209.243
-Port: 80/TCP
-TargetPort: 80/TCP
-Endpoints: 10.46.0.0:80
-Session Affinity: None
-Events:
-```
-
-Acessando o Ningx. Altere o IP do cluster no comando a seguir de acordo com o seu ambiente.
-
-```
-curl 10.104.209.243
-
-...
-Welcome to nginx!
-...
-```
-
-Acesse o log do Nginx.
-
-```
-kubectl logs -f nginx
-
-10.40.0.0 - - [10/May/2020:17:31:56 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.58.0" "-"
-```
-
-Remova o serviço criado anteriormente.
-
-```
-kubectl delete svc nginx
-
-service "nginx" deleted
-```
-
-Agora vamos criar nosso service ``ClusterIP``, porém vamos criar um arquivo yaml com suas definições:
-
-```
-vim primeiro-service-clusterip.yaml
-```
-
-Informe o seguinte conteúdo:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- run: nginx
- name: nginx-clusterip
- namespace: default
-spec:
- ports:
- - port: 80
- protocol: TCP
- targetPort: 80
- selector:
- run: nginx
- type: ClusterIP
-```
-
-Criando o service:
-
-```
-kubectl create -f primeiro-service-clusterip.yaml
-
-service/nginx-clusterip created
-```
-
-Obtendo informações do service:
-
-```
-kubectl get services
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 28m
-nginx-clusterip ClusterIP 10.109.70.243 80/TCP 71s
-```
-
-Visualizando os detalhes do service:
-
-```
-kubectl describe service nginx-clusterip
-
-Name: nginx-clusterip
-Namespace: default
-Labels: run=nginx
-Annotations:
-Selector: run=nginx
-Type: ClusterIP
-IP: 10.109.70.243
-Port: 80/TCP
-TargetPort: 80/TCP
-Endpoints: 10.46.0.1:80
-Session Affinity: None
-Events:
-```
-
-Removendo o service:
-
-```
-kubectl delete -f primeiro-service-clusterip.yaml
-
-service "nginx-clusterip" deleted
-```
-
-Agora vamos mudar um detalhe em nosso manifesto, vamos brincar com o nosso ``sessionAffinity``:
-
-> **Nota:** Se você quiser ter certeza de que as conexões de um cliente específico sejam passadas para o mesmo pod todas as vezes, você pode selecionar a afinidade da sessão (*session affinity*) com base nos endereços IP do cliente, definindo ``service.spec.sessionAffinity`` como ``ClientIP`` (o padrão é ``None``). Você também pode definir o tempo de permanência máximo da sessão definindo ``service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`` adequadamente (o valor padrão é 10800 segundos, o que resulta em 3 horas).
-
-```
-vim primeiro-service-clusterip.yaml
-```
-
-O conteúdo deve ser o seguinte:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- run: nginx
- name: nginx-clusterip
- namespace: default
-spec:
- ports:
- - port: 80
- protocol: TCP
- targetPort: 80
- selector:
- run: nginx
- sessionAffinity: ClientIP
- type: ClusterIP
-```
-
-Criando o service novamente:
-
-```
-kubectl create -f primeiro-service-clusterip.yaml
-
-service/nginx-clusterip created
-```
-
-Obtendo informações do service:
-
-```
-kubectl get services
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 29m
-nginx-clusterip ClusterIP 10.96.44.114 80/TCP 7s
-```
-
-Visualizando os detalhes do service:
-
-```
-kubectl describe service nginx
-
-Name: nginx-clusterip
-Namespace: default
-Labels: run=nginx
-Annotations:
-Selector: run=nginx
-Type: ClusterIP
-IP: 10.96.44.114
-Port: 80/TCP
-TargetPort: 80/TCP
-Endpoints: 10.46.0.1:80
-Session Affinity: ClientIP
-Events:
-```
-
-Com isso, agora temos como manter a sessão, ou seja, ele irá manter a conexão com o mesmo pod, respeitando o IP de origem do cliente.
-
-Caso precise, é possível alterar o valor do timeout para o ``sessionAffinity`` (O valor padrão é de 10800 segundos, ou seja 3 horas), apenas adicionando a configuração abaixo.
-
-```
- sessionAffinityConfig:
- clientIP:
- timeoutSeconds: 10
-```
-
-Agora podemos remover o service:
-
-```
-kubectl delete -f primeiro-service-clusterip.yaml
-
-service "nginx-clusterip" deleted
-```
-
-## Criando um service NodePort
-
-Execute o comando a seguir para exportar o pod usando o service NodePort. Lembrando que o range de portas internas é entre 30000/TCP a 32767/TCP.
-
-```
-kubectl expose pods nginx --type=NodePort --port=80
-
-service/nginx exposed
-```
-
-Obtendo informações do service:
-
-```
-kubectl get svc
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 29m
-nginx NodePort 10.101.42.230 80:31858/TCP 5s
-```
-
-Removendo o service:
-
-```
-kubectl delete svc nginx
-
-service "nginx" deleted
-```
-
-Agora vamos criar um service NodePort, porém vamos criar um manifesto yaml com suas definições.
-
-```
-vim primeiro-service-nodeport.yaml
-```
-
-O conteúdo deve ser o seguinte.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- run: nginx
- name: nginx-nodeport
- namespace: default
-spec:
- externalTrafficPolicy: Cluster
- ports:
- - nodePort: 31111
- port: 80
- protocol: TCP
- targetPort: 80
- selector:
- run: nginx
- sessionAffinity: None
- type: NodePort
-```
-
-Criando o service:
-
-```
-kubectl create -f primeiro-service-nodeport.yaml
-
-service/nginx-nodeport created
-```
-
-Obtendo informações do service:
-
-```
-kubectl get services
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 30m
-nginx-nodeport NodePort 10.102.91.81 80:31111/TCP 7s
-```
-
-Visualizando os detalhes do service:
-
-```
-kubectl describe service nginx
-
-Name: nginx-nodeport
-Namespace: default
-Labels: run=nginx
-Annotations:
-Selector: run=nginx
-Type: NodePort
-IP: 10.102.91.81
-Port: 80/TCP
-TargetPort: 80/TCP
-NodePort: 31111/TCP
-Endpoints: 10.46.0.1:80
-Session Affinity: None
-External Traffic Policy: Cluster
-Events:
-```
-
-Removendo o service:
-
-```
-kubectl delete -f primeiro-service-nodeport.yaml
-
-service "nginx-nodeport" deleted
-```
-
-## Criando um service LoadBalancer
-
-Execute o comando a seguir para exportar o pod usando o service LoadBalancer.
-
-```
-kubectl expose pod nginx --type=LoadBalancer --port=80
-
-service/nginx exposed
-```
-
-Obtendo informações do service:
-
-```
-kubectl get svc
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 32m
-nginx LoadBalancer 10.110.198.89 80:30728/TCP 4s
-```
-
-Removendo o service:
-
-```
-kubectl delete svc nginx
-
-service "nginx" deleted
-```
-
-Agora vamos criar service LoadBalancer, porém vamos criar um yaml com suas definições.
-
-```
-vim primeiro-service-loadbalancer.yaml
-```
-
-O conteúdo deve ser o seguinte.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- run: nginx
- name: nginx-loadbalancer
- namespace: default
-spec:
- externalTrafficPolicy: Cluster
- ports:
- - nodePort: 31222
- port: 80
- protocol: TCP
- targetPort: 80
- selector:
- run: nginx
- sessionAffinity: None
- type: LoadBalancer
-```
-
-Criando o service:
-
-```
-kubectl create -f primeiro-service-loadbalancer.yaml
-
-service/nginx-loadbalancer created
-```
-
-Obtendo informações do service:
-
-```
-kubectl get services
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 33m
-nginx-loadbalancer LoadBalancer 10.96.67.165 80:31222/TCP 4s
-```
-
-Visualizando informações do service:
-
-```
-kubectl describe service nginx
-
-Name: nginx-loadbalancer
-Namespace: default
-Labels: run=nginx
-Annotations:
-Selector: run=nginx
-Type: LoadBalancer
-IP: 10.96.67.165
-Port: 80/TCP
-TargetPort: 80/TCP
-NodePort: 31222/TCP
-Endpoints: 10.46.0.1:80
-Session Affinity: None
-External Traffic Policy: Cluster
-Events:
-```
-
-Removendo o service:
-
-```
-kubectl delete -f primeiro-service-loadbalancer.yaml
-
-service "nginx-loadbalancer" deleted
-```
-
-## EndPoint
-
-Sempre que criamos um service, automaticamente é criado um endpoint. O endpoint nada mais é do que o IP do pod que o service irá utilizar, por exemplo, quando criamos um service do tipo ClusterIP temos o seu IP, correto?
-
-Agora, quando batemos nesse IP ele redireciona a conexão para o **Pod** através desse IP, o **EndPoint**.
-
-Para listar os EndPoints criados, execute o comando:
-
-```
-kubectl get endpoints
-
-NAME ENDPOINTS AGE
-kubernetes 10.142.0.5:6443 4d
-```
-
-Vamos verificar esse endpoint com mais detalhes.
-
-```
-kubectl describe endpoints kubernetes
-
-Name: kubernetes
-Namespace: default
-Labels:
-Annotations:
-Subsets:
- Addresses: 172.31.17.67
- NotReadyAddresses:
- Ports:
- Name Port Protocol
- ---- ---- --------
- https 6443 TCP
-
-Events:
-```
-
-Vamos fazer um exemplo, para isso, vamos realizar a criação de um deployment, aumentar o número de réplicas para 3 e na sequência um service para que possamos ver com mais detalhes os endpoints que serão criados.
-
-```
-kubectl create deployment nginx --image=nginx
-
-deployment.apps/nginx created
-```
-
-Observando os deployments:
-
-```
-kubectl get deployments.apps
-
-NAME READY UP-TO-DATE AVAILABLE AGE
-nginx 1/1 1 1 5s
-```
-
-Escalando o deployment nginx para 3 réplicas:
-
-```
-kubectl scale deployment nginx --replicas=3
-
-deployment.apps/nginx scaled
-```
-
-Observando os deployments:
-
-```
-kubectl get deployments.apps
-
-NAME READY UP-TO-DATE AVAILABLE AGE
-nginx 3/3 3 3 1m5s
-```
-
-Expondo o deployment nginx:
-
-```
-kubectl expose deployment nginx --port=80
-
-service/nginx exposed
-```
-
-Visualizando o service:
-
-```
-kubectl get svc
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-kubernetes ClusterIP 10.96.0.1 443/TCP 40m
-nginx ClusterIP 10.98.153.22 80/TCP 6s
-```
-
-Acessando o ``nginx``:
-
-```
-curl 10.98.153.22
-
-...
-Welcome to nginx!
-...
-```
-
-Visualizando os endpoints:
-
-```
-kubectl get endpoints
-
-NAME ENDPOINTS AGE
-kubernetes 172.31.17.67:6443 44m
-nginx 10.32.0.2:80,10.32.0.3:80,10.46.0.2:80 3m31s
-```
-
-Visualizando os detalhes do endpoint ``nginx``:
-
-```
-kubectl describe endpoints nginx
-
-Name: nginx
-Namespace: default
-Labels: app=nginx
-Annotations: endpoints.kubernetes.io/last-change-trigger-time: 2020-05-10T17:47:05Z
-Subsets:
- Addresses: 10.32.0.2,10.32.0.3,10.46.0.2
- NotReadyAddresses:
- Ports:
- Name Port Protocol
- ---- ---- --------
- 80 TCP
-
-Events:
-```
-
-Visualizando o endpoint no formato YAML.
-
-```
-kubectl get endpoints -o yaml
-
-apiVersion: v1
-items:
-- apiVersion: v1
- kind: Endpoints
- metadata:
- creationTimestamp: "2020-05-10T17:06:12Z"
- managedFields:
- - apiVersion: v1
- fieldsType: FieldsV1
- fieldsV1:
- f:subsets: {}
- manager: kube-apiserver
- operation: Update
- time: "2020-05-10T17:06:12Z"
- name: kubernetes
- namespace: default
- resourceVersion: "163"
- selfLink: /api/v1/namespaces/default/endpoints/kubernetes
- uid: 39f1e237-f9cc-4553-a32d-95402ff52f6c
-...
- - ip: 10.46.0.2
- nodeName: elliot-03
- targetRef:
- kind: Pod
- name: nginx-f89759699-dmt4t
- namespace: default
- resourceVersion: "6805"
- uid: 6a9c4639-78ee-44c6-8eb1-4fd90d308189
- ports:
- - port: 80
- protocol: TCP
-kind: List
-metadata:
- resourceVersion: ""
- selfLink: ""
-```
-
-Removendo o deployment ``nginx``:
-
-```
-kubectl delete deployment nginx
-
-deployment.apps "nginx" deleted
-```
-
-Removendo o service:
-
-```
-kubectl delete service nginx
-
-service "nginx" deleted
-```
-
-# Limitando Recursos
-
-Quando criamos um Pod podemos especificar a quantidade de CPU e Memória (RAM) que pode ser consumida em cada contêiner. Quando algum contêiner contém a configuração de limite de recursos o Scheduler fica responsável por alocar esse contêiner no melhor nó possível de acordo com os recursos disponíveis.
-
-Podemos configurar dois tipos de recursos, CPU que é especificada em **unidades de núcleos** e Memória que é especificada em **unidades de bytes**.
-
-Vamos criar nosso primeiro Deployment com limite de recursos, para isso vamos subir a imagem de um ``nginx`` e copiar o ``yaml`` do deployment com o seguinte comando.
-
-```
-kubectl create deployment nginx --image=nginx
-
-deployment.apps/nginx created
-```
-
-Escalando o deployment para 3 réplicas:
-
-```
-kubectl scale deployment nginx --replicas=3
-
-deployment.apps/nginx scaled
-```
-
-Obtendo a lista de deployments:
-
-```
-kubectl get deployments
-
-NAME READY UP-TO-DATE AVAILABLE AGE
-nginx 3/3 3 3 24s
-```
-
-Crie o seguinte arquivo:
-
-```
-vim deployment-limitado.yaml
-```
-
-O conteúdo deve ser o seguinte.
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- labels:
- app: nginx
- name: nginx
- namespace: default
-spec:
- progressDeadlineSeconds: 600
- replicas: 3
- revisionHistoryLimit: 10
- selector:
- matchLabels:
- app: nginx
- strategy:
- rollingUpdate:
- maxSurge: 25%
- maxUnavailable: 25%
- type: RollingUpdate
- template:
- metadata:
- creationTimestamp: null
- labels:
- app: nginx
- spec:
- containers:
- - image: nginx
- imagePullPolicy: Always
- name: nginx
- # Adicione as seguintes linhas
- resources:
- limits:
- memory: "256Mi"
- cpu: "200m"
- requests:
- memory: "128Mi"
- cpu: "50m"
- terminationMessagePath: /dev/termination-log
- terminationMessagePolicy: File
- dnsPolicy: ClusterFirst
- restartPolicy: Always
- schedulerName: default-scheduler
- securityContext: {}
- terminationGracePeriodSeconds: 30
-```
-
-> **Atenção!!!** **1 core de CPU** corresponde a ``1000m`` (1000 milicore). Ao especificar ``200m``, estamos querendo reservar 20% de 1 core da CPU. Se fosse informado o valor ``0.2`` teria o mesmo efeito, ou seja, seria reservado 20% de 1 core da CPU.
-
-Vamos remover o deployment do ``nginx``:
-
-```
-kubectl delete deployments.apps nginx
-```
-
-Agora vamos criar nosso deployment e verificar os recursos.
-
-```
-kubectl create -f deployment-limitado.yaml
-
-deployment.apps/nginx created
-```
-
-Vamos acessar um contêiner e testar a configuração:
-
-```
-kubectl get pod
-
-NAME READY STATUS RESTARTS AGE
-nginx 1/1 Running 0 12m
-nginx-f89759699-77v8b 1/1 Running 0 117s
-nginx-f89759699-ffbgh 1/1 Running 0 117s
-nginx-f89759699-vzvlt 1/1 Running 0 2m2s
-```
-
-Acessando o shell de um pod:
-
-```
-kubectl exec -ti nginx-f89759699-77v8b -- /bin/bash
-```
-
-Agora no contêiner, instale e execute o ``stress`` para simular a carga em nossos recursos, no caso CPU e memória.
-
-Instalando o comando stress:
-
-```
-apt-get update && apt-get install -y stress
-```
-
-Executando o ``stress``:
-
-```
-stress --vm 1 --vm-bytes 128M --cpu 1
-
-stress: info: [221] dispatching hogs: 1 cpu, 0 io, 1 vm, 0 hdd
-```
-Aqui estamos _stressando_ o contêiner, utilizando 128M de RAM e um core de CPU. Brinque de acordo com os limites que você estabeleceu.
-
-Quando ultrapassar o limite configurado, você receberá um erro como mostrado ao executar o seguinte comando, pois ele não conseguirá alocar os recursos de memória:
-
-```
-stress --vm 1 --vm-bytes 512M --cpu 1
-
-stress: info: [230] dispatching hogs: 1 cpu, 0 io, 1 vm, 0 hdd
-stress: FAIL: [230] (415) <-- worker 232 got signal 9
-stress: WARN: [230] (417) now reaping child worker processes
-stress: FAIL: [230] (451) failed run completed in 0s
-```
-
-Para acompanhar a quantidade de recurso que o pod está utilizando, podemos utilizar o ``kubectl top``. Lembre-se de executar esse comando no node e não no contêiner. :)
-
-```
-kubectl top pod --namespace=default nginx-f89759699-77v8b
-
-NAME CPU(cores) MEMORY(bytes)
-nginx-85f7fb6b45-b6dsk 201m 226Mi
-```
-
-# Namespaces
-
-No kubernetes temos um cara chamado de Namespaces como já vimos anteriormente.
-
-Mas o que é um Namespace? Nada mais é do que um cluster virtual dentro do próprio cluster físico do Kubernetes. Namespaces são uma maneira de dividir recursos de um cluster entre vários ambientes, equipes ou projetos.
-
-Vamos criar nosso primeiro namespaces:
-
-```
-kubectl create namespace primeiro-namespace
-
-namespace/primeiro-namespace created
-```
-
-Vamos listar todos os namespaces do kubernetes:
-
-```
-kubectl get namespaces
-
-NAME STATUS AGE
-default Active 55m
-kube-node-lease Active 56m
-kube-public Active 56m
-kube-system Active 56m
-primeiro-namespace Active 5s
-```
-
-Pegando mais informações do nosso namespace:
-
-```
-kubectl describe namespace primeiro-namespace
-
-Name: primeiro-namespace
-Labels:
-Annotations:
-Status: Active
-
-No resource quota.
-
-No LimitRange resource.
-```
-
-Como podemos ver, nosso namespace ainda está sem configurações, então iremos utilizar o ``LimitRange`` para adicionar limites de recursos.
-
-Vamos criar o manifesto do ``LimitRange``:
-
-```
-vim limitando-recursos.yaml
-```
-
-O conteúdo deve ser o seguinte.
-
-```yaml
-apiVersion: v1
-kind: LimitRange
-metadata:
- name: limitando-recursos
-spec:
- limits:
- - default:
- cpu: 1
- memory: 100Mi
- defaultRequest:
- cpu: 0.5
- memory: 80Mi
- type: Container
-```
-
-Agora vamos adicionar esse ``LimitRange`` ao Namespace:
-
-```
-kubectl create -f limitando-recursos.yaml -n primeiro-namespace
-
-limitrange/limitando-recursos created
-```
-
-Listando o ``LimitRange``:
-
-```
-kubectl get limitranges
-
-No resources found in default namespace.
-```
-
-Opa! Não encontramos não é mesmo? Mas claro, esquecemos de passar nosso namespace na hora de listar:
-
-```
-kubectl get limitrange -n primeiro-namespace
-
-NAME CREATED AT
-limitando-recursos 2020-05-10T18:02:51Z
-```
-
-Ou:
-
-```
-kubectl get limitrange --all-namespaces
-
-NAMESPACE NAME CREATED AT
-primeiro-namespace limitando-recursos 2020-05-10T18:02:51Z
-```
-
-Vamos dar um describe no ``LimitRange``:
-
-```
-kubectl describe limitrange -n primeiro-namespace
-
-Name: limitando-recursos
-Namespace: primeiro-namespace
-Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
----- -------- --- --- --------------- ------------- -----------------------
-Container cpu - - 500m 1 -
-Container memory - - 80Mi 100Mi -
-```
-
-Como podemos observar, adicionamos limites de memória e cpu para cada contêiner que subir nesse ``Namespace``, se algum contêiner for criado dentro do ``Namespace`` sem as configurações de ``Limitrange``, o contêiner irá herdar as configurações de limites de recursos do Namespace.
-
-Vamos criar um pod para verificar se o limite se aplicará:
-
-```
-vim pod-limitrange.yaml
-```
-
-O conteúdo deve ser o seguinte.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: limit-pod
-spec:
- containers:
- - name: meu-container
- image: nginx
-```
-
-Agora vamos criar um pod fora do namespace default e outro dentro do namespace limitado (primeiro-namespace), e vamos observar os limites de recursos de cada contêiner e como foram aplicados:
-
-Criando o pod no namespace ``default``:
-
-```
-kubectl create -f pod-limitrange.yaml
-
-pod/limit-pod created
-```
-
-Criando o pod no namespace ``primeiro-namespace``:
-
-```
-kubectl create -f pod-limitrange.yaml -n primeiro-namespace
-
-pod/limit-pod created
-```
-
-Vamos listar esses pods e na sequência ver mais detalhes :
-
-```
-kubectl get pods --all-namespaces
-
-NAMESPACE NAME READY STATUS RESTARTS AGE
-default limit-pod 1/1 Running 0 10s
-primeiro-namespace limit-pod 1/1 Running 0 5s
-```
-
-Vamos ver mais detalhes do pod no namespace ``default``.
-
-```
-kubectl describe pod limit-pod
-
-Name: limit-pod
-Namespace: default
-Priority: 0
-Node: elliot-02/172.31.19.123
-Start Time: Sun, 10 May 2020 18:03:52 +0000
-Labels:
-Annotations:
-Status: Running
-IP: 10.32.0.4
-IPs:
- IP: 10.32.0.4
-Containers:
- meu-container:
- Container ID: docker://19850dc935ffa41b1754cb58ab60ec5bb3616bbbe6a958abe1b2575bd26ee73d
- Image: nginx
-...
-```
-
-Vamos ver mais detalhes do pod no namespace ``primeiro-namespace``.
-
-```
-kubectl describe pod limit-pod -n primeiro-namespace
-
-Name: limit-pod
-Namespace: primeiro-namespace
-Priority: 0
-Node: elliot-03/172.31.24.60
-Start Time: Sun, 10 May 2020 18:03:57 +0000
-Labels:
-Annotations: kubernetes.io/limit-ranger:
- LimitRanger plugin set: cpu, memory request for container meu-container; cpu, memory limit for container meu-container
-Status: Running
-IP: 10.46.0.3
-IPs:
- IP: 10.46.0.3
-Containers:
- meu-container:
- Container ID: docker://ad3760837d71955df47263a2031d4238da2e94002ce4a0631475d301faf1ddef
- Image: nginx
-...
- Limits:
- cpu: 1
- memory: 100Mi
- Requests:
- cpu: 500m
- memory: 80Mi
-```
-
-Como podemos ver o **Pod** no namespace ``primeiro-namespace`` está com limit de recursos configurados.
-
-# Kubectl taint
-
-O **Taint** nada mais é do que adicionar propriedades ao nó do cluster para impedir que os pods sejam alocados em nós inapropriados.
-
-Por exemplo, todo nó ``master`` do cluster é marcado para não receber pods que não sejam de gerenciamento do cluster.
-
-O nó ``master`` está marcado com o taint ``NoSchedule``, assim o scheduler do Kubernetes não aloca pods no nó master, e procura outros nós no cluster sem essa marca.
-
-Visualizando os nodes do cluster:
-
-```
-kubectl get nodes
-
-NAME STATUS ROLES AGE VERSION
-elliot-01 Ready master 7d14h v1.18.2
-elliot-02 Ready 7d14h v1.18.2
-elliot-03 Ready 7d14h v1.18.2
-```
-
-Visualizando as labels Taints do node ``master``:
-
-```
-kubectl describe node elliot-01 | grep -i taint
-
-Taints: node-role.kubernetes.io/master:NoSchedule
-```
-
-**Vamos testar algumas coisas e permitir que o nó master rode outros pods.**
-
-Primeiro vamos rodar 3 réplicas de ``nginx``:
-
-```
-kubectl create deployment nginx --image=nginx
-
-deployment.apps/nginx created
-```
-
-Visualizando os deployments:
-
-```
-kubectl get deployments.apps
-
-NAME READY UP-TO-DATE AVAILABLE AGE
-nginx 1/1 1 1 5s
-```
-
-Escalando o deployment do nginx para 3 réplicas:
-
-```
-kubectl scale deployment nginx --replicas=3
-
-deployment.apps/nginx scaled
-```
-
-Visualizando novamente os deployments:
-
-```
-kubectl get deployments.apps
-
-NAME READY UP-TO-DATE AVAILABLE AGE
-nginx 3/3 3 3 1m5s
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl get pods -o wide
-
-NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
-limit-pod 1/1 Running 0 3m44s 10.32.0.4 elliot-02
-nginx 1/1 Running 0 25m 10.46.0.1 elliot-03
-nginx-85f7fb6b45-9bzwc 1/1 Running 0 6m7s 10.32.0.3 elliot-02
-nginx-85f7fb6b45-cbmtr 1/1 Running 0 6m7s 10.46.0.2 elliot-03
-nginx-85f7fb6b45-rprz5 1/1 Running 0 6m7s 10.32.0.2 elliot-02
-```
-
-Vamos adicionar a marca ``NoSchedule`` aos nós worker também para ver como eles se comportam.
-
-Node worker 1:
-
-```
-kubectl taint node elliot-02 key1=value1:NoSchedule
-
-node/elliot-02 tainted
-```
-
-Node worker 2:
-
-```
-kubectl taint node elliot-03 key1=value1:NoSchedule
-
-node/elliot-03 tainted
-```
-
-Visualizando a label Taint no node worker 1:
-
-```
-kubectl describe node elliot-02 | grep -i taint
-
-Taints: key1=value1:NoSchedule
-```
-
-Visualizando a label Taint no node worker 2:
-
-```
-kubectl describe node elliot-03 | grep -i taint
-
-Taints: key1=value1:NoSchedule
-```
-
-Agora vamos aumentar a quantidade de réplicas:
-
-```
-kubectl scale deployment nginx --replicas=5
-
-deployment.apps/nginx scaled
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl get pods -o wide
-
-NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
-limit-pod 1/1 Running 0 5m23s 10.32.0.4 elliot-02
-nginx 1/1 Running 0 27m 10.46.0.1 elliot-03
-nginx-85f7fb6b45-9bzwc 1/1 Running 0 7m46s 10.32.0.3 elliot-02
-nginx-85f7fb6b45-cbmtr 1/1 Running 0 7m46s 10.46.0.2 elliot-03
-nginx-85f7fb6b45-qnhtl 0/1 Pending 0 18s
-nginx-85f7fb6b45-qsvpp 0/1 Pending 0 18s
-nginx-85f7fb6b45-rprz5 1/1 Running 0 7m46s 10.32.0.2 elliot-02
-```
-
-Como podemos ver, as nova réplicas ficaram órfãs esperando aparecer um nó com as prioridades adequadas para o Scheduler.
-
-Vamos remover esse Taint dos nossos nós worker:
-
-Removendo o taint do worker 1:
-
-```
-kubectl taint node elliot-02 key1:NoSchedule-
-
-node/elliot-02 untainted
-```
-
-Removendo o taint do worker 2:
-
-```
-kubectl taint node elliot-03 key1:NoSchedule-
-
-node/elliot-03 untainted
-```
-
-Visualizando os detalhes dos pods:
-
-```
-kubectl get pods -o wide
-
-NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
-limit-pod 1/1 Running 0 6m17s 10.32.0.4 elliot-02
-nginx 1/1 Running 0 27m 10.46.0.1 elliot-03
-nginx-85f7fb6b45-9bzwc 1/1 Running 0 8m40s 10.32.0.3 elliot-02
-nginx-85f7fb6b45-cbmtr 1/1 Running 0 8m40s 10.46.0.2 elliot-03