Docker_dia4_K8S

Inicio da aula do Day-4
O que iremos ver hoje?
Hoje é dia de falar sobre dois objetos muito importantes no Kubernetes, os ReplicaSets e os DaemonSets.
Nós já sabemos o que é um Deployment e também já sabemos o que é um Pod no detalhe, então agora vamos conhecer essas duas figuras que estão super conectadas com o Deployment e com o Pod. Quando falamos sobre Deployment é impossível não falar sobre ReplicaSet, pois o Deployment é um objeto que cria um ReplicaSet e o ReplicaSet é um objeto que cria um Pod, veja que tudo está conectado.
Já o nosso querido DaemonSet é um objeto que cria um Pod e esse Pod é um objeto que fica rodando em todos os nodes do cluster, super importante para nós, pois é com DaemonSet que nós conseguimos garantir que teremos pelo menos um Pod rodando em cada node do cluster. Por exemplo, imagine que você precisa de instalar os agente do Datadog ou ainda um exporter do Prometheus em todos os nodes do cluster, para isso você precisa de um DaemonSet.
Ainda no dia de hoje, nós iremos aprender como garantir que os nossos Pods estão rodando corretamente, através das Probes do Kubernetes.
Nós vamos falar sobre Readiness Probe, Liveness Probe e Startup Probe, e claro, mostrando todos os detalhes em exemplos práticos e super explicativos.
Hoje é o dia de você aprender sobre esses dois objetos que são super importantes, e ainda, garantir que nós nunca colocaremos os nossos Pods em produção sem antes garantir que eles estão rodando corretamente e sendo checados pelas Probes do Kubernetes.
Bora lá! #VAIIII
===========================================

ReplicaSets

ReplicaSet
Uma coisa é super importante de saber, quando estamos criando um Deployment no Kubernetes, automaticamente estamos criando além do Deployment um ReplicaSet e esse ReplicaSet é quem vai criar os Pods que estão dentro do Deployment.
Confuso, não?
Não, não é e vou te explicar.
Quando criamos um Deployment, o Kubernetes cria um ReplicaSet para criar e fazer o gerenciamento das réplicas dos Pods em nosso cluster. Ele é o responsável por ficar observando os Pods e garantir o número de réplicas que nós definimos no Deployment.
É possível criar um ReplicaSet sem um Deployment, mas não é uma boa prática, pois o ReplicaSet não tem a capacidade de fazer o gerenciamento de versões dos Pods e também não tem a capacidade de fazer o gerenciamento de RollingUpdate dos Pods.
E olha que interessante, quando estamos fazendo a atualização de uma versão de um Pod com o Deployment, o Deployment cria um novo ReplicaSet para fazer o gerenciamento das réplicas dos Pods e quando a atualização termina, o Deployment remove as réplicas do ReplicaSet antigo e deixa apenas as réplicas do ReplicaSet novo.
Mas ele não remove o ReplicaSet antigo, ele deixa ele lá, pois ele pode ser usado para fazer um Rollback da versão do Pod caso algo dê errado. Sim, quando precisamos fazer o Rollback de uma atualização em nossos Pods, o Deployment somente muda o ReplicaSet que está sendo usado para fazer o gerenciamento das réplicas dos Pods, passando a utilizar o ReplicaSet antigo.
Vamos fazer isso na prática?
Acho que vai te ajudar a entender melhor.


Subimos um deployment com o seguinte ymal

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment02
  name: nginx-deployment02
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deployment02
  strategy: {}
  template:
    metadata:
      labels:
        app: nginx-deployment02
    spec:
      containers:
      - image: nginx:1.19.1
        name: nginx
        resources:
          limits:
            cpu: "0.5"
            memory: 256Mi
          requests:
            cpu: "0.25"
            memory: 128Mi

Subiemos ele com o comando
kubectl apply -f nginx-deployment.yaml

Confirmamos sua criação:
root@obi-System-Product-Name:~/k8s/day04# kubectl get deployment
NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment02   1/1     1            1           12m

Confirmamos o pod
kubectl get pods
NAME                                  READY   STATUS    RESTARTS   AGE
nginx-deployment02-6c4779d8dd-dvllq   1/1     Running   0          2m40s

E tb verificamos o replicasets
root@obi-System-Product-Name:~/k8s/day04# kubectl get rs
NAME                            DESIRED   CURRENT   READY   AGE
nginx-deployment02-6c4779d8dd   1         1         1       12m

Depois disso alteramos o nosso yaml com uma outra versão do nginx e aplicamos novamente nosso deployment,
como essa alteração foi criado outro replicaset e o anterior fico vazio
root@obi-System-Product-Name:~/k8s/day04# kubectl get rs
NAME                            DESIRED   CURRENT   READY   AGE
nginx-deployment02-6c4779d8dd   1         1         1       12m
nginx-deployment02-76d55c5f64   0         0         0       6m23s

Depoois voltamos realizamos um rollout para versão anterior
root@obi-System-Product-Name:~/k8s/day04# kubectl rollout undo deployment nginx-deployment02
deployment.apps/nginx-deployment02 rolled back

Criamos mais replicas do nosso pod com o comando:
kubectl scale deployment nginx-deployment02 --replicas 3
kubectl scale deployment nginx-deployment02 --replicas 3
deployment.apps/nginx-deployment02 scaled
root@obi-System-Product-Name:~/k8s/day04# kubectl get pods
NAME                                  READY   STATUS              RESTARTS   AGE
nginx-deployment02-6c4779d8dd-6c2bg   0/1     ContainerCreating   0          6s
nginx-deployment02-6c4779d8dd-dvllq   1/1     Running             0          7m12s
nginx-deployment02-6c4779d8dd-h9dkr   0/1     ContainerCreating   0          6s
root@obi-System-Product-Name:~/k8s/day04# kubectl get pods
NAME                                  READY   STATUS              RESTARTS   AGE
nginx-deployment02-6c4779d8dd-6c2bg   1/1     Running             0          8s
nginx-deployment02-6c4779d8dd-dvllq   1/1     Running             0          7m14s
nginx-deployment02-6c4779d8dd-h9dkr   0/1     ContainerCreating   0          8s
root@obi-System-Product-Name:~/k8s/day04# kubectl get pods
NAME                                  READY   STATUS    RESTARTS   AGE
nginx-deployment02-6c4779d8dd-6c2bg   1/1     Running   0          10s
nginx-deployment02-6c4779d8dd-dvllq   1/1     Running   0          7m16s
nginx-deployment02-6c4779d8dd-h9dkr   1/1     Running   0          10s
root@obi-System-Product-Name:~/k8s/day04#

========================================
Criando uma replicaset

vim nginx-replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: nginx-app
  name: nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx01
        image: nginx:1.19.1
        resources:
          limits:
            cpu: 0.5
            memory: 256Mi
          requests:
            cpu: 0.3
            memory: 128Mi

kubectl aplly - f nginx-replicaset.yaml

Verificar se foi criado:
kubectl get rs
NAME                            DESIRED   CURRENT   READY   AGE
nginx-deployment02-6c4779d8dd   1         1         1       7d22h
nginx-deployment02-76d55c5f64   0         0         0       7d22h
nginx-replicaset                3         3         3       14s

Realizamos um teste de alterar a versão do nginx para 19.1.2 e executamos o comando para atualizar o mesmo
kubectl apply -f nginx-replicaset.yaml
ele mostra que configurou, mas não atualizou a versão do pods.
Para realizar a alteração foi necessário apagar o pod
kubectl delete pods nginx-replicaset-nm8zz
Após o delete o replicaset subiu um novo pods com a versão atualizada
Normal  Pulling    30s   kubelet            Pulling image "nginx:1.19.2"

Esse caso não é o indicado de se realizar, o correto é ter o deployment
Para garantir o não usarmos mais esse cara vamos matar ele
kubectl delete rs nginx-replicaset

o resumo, replicaset é o cara resposavel por garantir as replicas ok e números ok, e tb responsavel por realizar o rollback
de um versão se for necessário.
=============================================

O DaemonSet
Já sabemos o que é um Pod, um Deployment e um ReplicaSet, mas agora é a hora de conhecermos mais um objeto do Kubernetes, o DaemonSet.
O DaemonSet é um objeto que garante que todos os nós do cluster executem uma réplica de um Pod, ou seja, ele garante que todos os nós do cluster executem uma cópia de um Pod.
O DaemonSet é muito útil para executar Pods que precisam ser executados em todos os nós do cluster, como por exemplo, um Pod que faz o monitoramento de logs, ou um Pod que faz o monitoramento de métricas.
Alguns casos de uso de DaemonSets são:
Execução de agentes de monitoramento, como o Prometheus Node Exporter ou o Fluentd.
Execução de um proxy de rede em todos os nós do cluster, como kube-proxy, Weave Net, Calico ou Flannel.
Execução de agentes de segurança em cada nó do cluster, como Falco ou Sysdig.
Portanto, se nosso cluster possuir 3 nós, o DaemonSet vai garantir que todos os nós executem uma réplica do Pod que ele está gerenciando, ou seja, 3 réplicas do Pod.
Caso adicionemos mais um node ao cluster, o DaemonSet vai garantir que todos os nós executem uma réplica do Pod que ele está gerenciando, ou seja, 4 réplicas do Pod.

Criando o primeiro Daemonset via yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: node-exporter-daemonset
  name: node-exporter-daemonset
spec:
  selector:
    matchLabels:
      app: node-exporter-daemonset
  template:
    metadata:
      labels:
        app: node-exporter-daemonset
    spec:
      hostNetwork: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:latest
        ports:
        - containerPort: 9100
          hostPort: 9100
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
        - name: sys
          mountPath: /host/sys
          readOnly: true
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys
Visualizando o daemonset criado
kubectl get daemonst
kubectl get daemonset
NAME                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
node-exporter-daemonset   3         3         3       3            3           <none>          17s

root@obi-System-Product-Name:~/k8s/day04# kubectl get pods
NAME                                  READY   STATUS    RESTARTS       AGE
nginx-deployment02-6c4779d8dd-dvllq   1/1     Running   10 (13h ago)   7d23h
node-exporter-daemonset-bcr29         1/1     Running   0              3m23s
node-exporter-daemonset-f4npm         1/1     Running   0              3m23s
node-exporter-daemonset-t7wk2         1/1     Running   0              3m23s

root@obi-System-Product-Name:~/k8s/day04# kubectl get nodes
NAME                            STATUS   ROLES           AGE     VERSION
kind-multinodes-control-plane   Ready    control-plane   7d23h   v1.24.0
kind-multinodes-worker          Ready    <none>          7d23h   v1.24.0
kind-multinodes-worker2         Ready    <none>          7d23h   v1.24.0
kind-multinodes-worker3         Ready    <none>          7d23h   v1.24.0

Se for necessário aumentar o número de node com o scale, automaticamente o daemonset cria um pod no node novo

Esse cara pode ser usado para uma agente do data dog q faz o monitoramento do node

=============================================

Hj vamos falar de probes
As Probes do Kubernetes
Antes de seguir, eu queria trazer algo novo além dos dois novos objetos que você já aprendeu no dia de hoje. Eu queria que você saisse do dia de hoje com a segurança que você e capaz de criar um Pod, um Deployment, um ReplicaSet ou um DaemonSet, mas também com a segurança que você pode monitorar o seus suas aplicações que estão rodando dentro do cluster de maneira efetiva e utilizando recursos que o Kubernetes já nos disponibiliza.
O que são as Probes?
As probes são uma forma de você monitorar o seu Pod e saber se ele está em um estado saudável ou não. Com elas é possível assegurar que seus Pods estão rodando e respondendo de maneira correta, e mais do que isso, que o Kubernetes está testando o que está sendo executado dentro do seu Pod.
Hoje nós temos disponíveis três tipos de probes, a livenessProbe, a readinessProbe e a startupProbe. Vamos ver no detalhe cada uma delas.

Hj vamos usar o probe para garantir a integridade do nosso container dentro do pod, se ele esta vivo mesmo.
Vamos criar nossa validação usando o yaml já existente e vamos somente add as informação do probe

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment03
  name: nginx-deployment03
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deployment03
  strategy: {}
  template:
    metadata:
      labels:
        app: nginx-deployment03
    spec:
      containers:
      - image: nginx:1.19.1
        name: nginx
        resources:
          limits:
            cpu: "0.5"
            memory: 256Mi
          requests:
            cpu: "0.25"
            memory: 128Mi
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
Adicionamos as informações usando a livenessProbe

livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3

Vamos testar essa validação, trocamos a porta do nginx para 81, e mandamos configurar novamente.
Após a validação esse foi o erro que detectamos no describe

Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  3m13s                default-scheduler  Successfully assigned default/nginx-deployment03-59c7ffd7df-t2qs4 to kind-multinodes-worker
  Normal   Pulling    3m13s                kubelet            Pulling image "nginx:1.19.1"
  Normal   Pulled     3m6s                 kubelet            Successfully pulled image "nginx:1.19.1" in 6.421516918s
  Normal   Created    93s (x4 over 3m6s)   kubelet            Created container nginx
  Normal   Started    93s (x4 over 3m6s)   kubelet            Started container nginx
  Warning  Unhealthy  93s (x9 over 2m53s)  kubelet            Liveness probe failed: dial tcp 10.244.2.2:81: connect: connection refused
  Normal   Killing    93s (x3 over 2m33s)  kubelet            Container nginx failed liveness probe, will be restarted
  Normal   Pulled     93s (x3 over 2m33s)  kubelet            Container image "nginx:1.19.1" already present on machine

Também podemos fazer via httpGet, conforme testado a baixo.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment03
  name: nginx-deployment03
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deployment03
  strategy: {}
  template:
    metadata:
      labels:
        app: nginx-deployment03
    spec:
      containers:
      - image: nginx:1.19.1
        name: nginx
        resources:
          limits:
            cpu: "0.5"
            memory: 256Mi
          requests:
            cpu: "0.25"
            memory: 128Mi
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3

Liveness Probe
A livenessProbe é a nossa probe de verificação de integridade, o que ela faz é verificar se o que está rodando dentro do Pod está saudável. O que fazemos é criar uma forma de testar se o que temos dentro do Pod está respondendo conforme esperado. Se por acaso o teste falhar, o Pod será reiniciado.
Para ficar mais claro, vamos mais uma vez utilizar o exemplo com o Nginx. Gosto de usar o Nginx como exemplo, pois sei que toda pessoa já o conhece, e assim, fica muito mais fácil de entender o que está acontecendo. Afinal, você está aqui para aprender Kubernetes, e se for com algo que você já conhece, fica muito mais fácil de entender.
Bem, vamos lá, hora de criar um novo Deployment com o Nginx, vamos utilizar o exemplo que já utilizamos quando aprendemos sobre o Deployment.
==========================

Vamos falar agora de outra probe, agora vamos falar de readinessProbe, esse probe garante que o nosso container esta apto a receber conexões
se ele falhar ele remove o container do loadbalancer por exemplo.

YAML criado

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment03
  name: nginx-deployment03
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deployment03
  strategy: {}
  template:
    metadata:
      labels:
        app: nginx-deployment03
    spec:
      containers:
      - image: nginx:1.19.1
        name: nginx
        resources:
          limits:
            cpu: "0.5"
            memory: 256Mi
          requests:
            cpu: "0.25"
            memory: 128Mi
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          exec:
            command:
            - curl
            - -f
            - http://localhost:80/
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
          successThreshold: 1

Readiness Probe
A readinessProbe é uma forma de o Kubernetes verificar se o seu container está pronto para receber tráfego, se ele está pronto para receber requisições vindas de fora.
Essa é a nossa probe de leitura, ela fica verificando se o nosso container está pronto para receber requisições, e se estiver pronto, ele irá receber requisições, caso contrário, ele não irá receber requisições, pois será removido do endpoint do serviço, fazendo com que o tráfego não chegue até ele.
Ainda iremos ver o que é service e endpoint, mas por enquanto, basta saber que o endpoint é o endereço que o nosso service irá usar para acessar o nosso Pod. Mas vamos ter um dia inteiro para falar sobre service e endpoint, então, relaxa.
Voltando ao assunto, a nossa probe da vez irá garantir que o nosso Podestá saudável para receber requisições.

==========================================
Outra probe não menos importante é a startupProbe, ela monitora se o container iniciou corretamente no momento do star do container

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment03
  name: nginx-deployment03
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deployment03
  strategy: {}
  template:
    metadata:
      labels:
        app: nginx-deployment03
    spec:
      containers:
      - image: nginx:1.19.1
        name: nginx
        resources:
          limits:
            cpu: "0.5"
            memory: 256Mi
          requests:
            cpu: "0.25"
            memory: 128Mi
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          exec:
            command:
            - curl
            - -f
            - http://localhost:80/
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
          successThreshold: 1
        startupProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 10
          timeoutSeconds: 5
          failureThreshold: 1

Startup Probe
Chegou a hora de falar sobre a probe, que na minha humilde opinião, é a menos utilizada, mas que é muito importante, a startupProbe.
Ela é a responsável por verificar se o nosso container foi inicializado corretamente, e se ele está pronto para receber requisições.
Ele é muito parecido com a readinessProbe, mas a diferença é que a startupProbe é executada apenas uma vez no começo da vida do nosso container, e a readinessProbe é executada de tempos em tempos.
========================================================

Desafio do Jeff, criar 3 deployment com td que apredemos nesse dia.

Comando para listar os pods de diferentes namespace
kubectl get pods --all-namespaces | grep -E "NAMESPACE|obivas|obivas02|obivas03"

Para esse desafio criamos 3 namespace via yaml

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: obivas
spec: {}
status: {}

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: obivas02
spec: {}
status: {}

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: obivas03
spec: {}
status: {}

=====================================================
1 deployment do nosso amigo nginx

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment01
  name: nginx-deployment01
  namespace: obivas
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment01
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx-deployment01
    spec:
      containers:
      - image: nginx:1.16.0
        name: nginx
        resources:
          limits:
            cpu: "500m"
            memory: 256Mi
          requests:
            cpu: "300m"
            memory: 128Mi
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3

Agora nosso amigo node-exporter

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: node-exporter-deployment02
  name: node-exporter-deployment02
  namespace: obivas02
spec:
  replicas: 2
  selector:
    matchLabels:
      app: node-exporter-deployment02
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: node-exporter-deployment02
    spec:
      hostNetwork: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:latest
        resources:
          limits:
            cpu: "0.5"
            memory: 256Mi
          requests:
            cpu: "0.25"
            memory: 128Mi
        ports:
        - containerPort: 9100
          hostPort: 9100
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
        - name: sys
          mountPath: /host/sys
          readOnly: true
        livenessProbe:
          httpGet:
            path: /
            port: 9100
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys

E por úlitmo e não menos importante Redis

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: redis-deployment
  name: redis-deployment
  namespace: obivas03
spec:
  replicas: 3
  selector:
    matchLabels:
      app: redis-deployment
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: redis-deployment
    spec:
      containers:
      - name: redis
        image: redis:latest
        resources:
          limits:
            cpu: "0.5"
            memory: 256Mi
          requests:
            cpu: "0.25"
            memory: 128Mi
        ports:
        - containerPort: 6379
        livenessProbe:
          tcpSocket:
            port: 6379
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3

root@obi-System-Product-Name:~/k8s/day04# kubectl get namespaces
NAME                 STATUS   AGE
default              Active   74m
kube-node-lease      Active   74m
kube-public          Active   74m
kube-system          Active   74m
local-path-storage   Active   74m
obivas               Active   73m
obivas02             Active   38m
obivas03             Active   7m7s
root@obi-System-Product-Name:~/k8s/day04# kubectl get deployment --all-namespaces | grep -E "NAMESPACE|obivas|obivas02|obivas03"
NAMESPACE            NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
obivas               nginx-deployment01           2/2     2            2           51m
obivas02             node-exporter-deployment02   2/2     2            2           38m
obivas03             redis-deployment             3/3     3            3           7m4s
root@obi-System-Product-Name:~/k8s/day04# kubectl get pods --all-namespaces | grep -E "NAMESPACE|obivas|obivas02|obivas03"
NAMESPACE            NAME                                                    READY   STATUS    RESTARTS   AGE
obivas               nginx-deployment01-9bcff7486-q57gt                      1/1     Running   0          51m
obivas               nginx-deployment01-9bcff7486-xv7nn                      1/1     Running   0          51m
obivas02             node-exporter-deployment02-9889b966f-4mcvn              1/1     Running   0          17m
obivas02             node-exporter-deployment02-9889b966f-n5lfp              1/1     Running   0          15m
obivas03             redis-deployment-777998f8d-2sbr6                        1/1     Running   0          7m8s
obivas03             redis-deployment-777998f8d-dscls                        1/1     Running   0          7m8s
obivas03             redis-deployment-777998f8d-wzsh5                        1/1     Running   0          7m8s
root@obi-System-Product-Name:~/k8s/day04#