Estudo para certifica%C3%A7%C3%A3o CKA - tmadeira3009/cka GitHub Wiki
- Understand storage classes, persistent volumes
- Understand volume mode, access modes and reclaim policies for volumes
- Understand persistent volume claims primitive
- Know how to configure applications with persistent storage
- Evaluate cluster and node logging
- Understand how to monitor applications
- Manage container stdout & stderr logs
- Troubleshoot application failure
- Troubleshoot cluster component failure
- Troubleshoot networking
- Understand deployments and how to perform rolling update and rollbacks
- Use ConfigMaps and Secrets to configure applications
- Know how to scale applications
- Understand the primitives used to create robust, self-healing, application deployments
- Understand how resource limits can affect Pod scheduling
- Awareness of manifest management and common templating tools
- Manage role based access control (RBAC)
- Use Kubeadm to install a basic cluster
- Manage a highly-available Kubernetes cluster
- Provision underlying infrastructure to deploy a Kubernetes cluster
- Perform a version upgrade on a Kubernetes cluster using Kubeadm
- Implement etcd backup and restore
- Understand host networking configuration on the cluster nodes
- Understand connectivity between Pods
- Understand ClusterIP, NodePort, LoadBalancer service types and endpoints
- Know how to use Ingress controllers and Ingress resources
- Know how to configure and use CoreDNS
- Choose an appropriate container network interface plugin
#Alias
#CONFIG_ALIAS_N_COMPLETION
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> /.bashrc
complete -F __start_kubectl k
alias k=kubectl
alias kgp="kubectl get pods"
alias kgs="kubectl get service"
alias kd="kubectl delete"
alias kcf="kubectl create -f"
alias kaf="kubectl apply -f"
alias kgpa="kubectl get pods -A"
alias kg='kubectl get'
alias ke='kubectl explain'
alias cls=clear
alias reload="systemctl daemon-reload"
alias cluster='kubectl cluster-info'
alias ctx=kubectx
alias ns=kubens
alias kube-cert="cd /etc/kubernetes/pki"
alias etcd-cert="cd /etc/kubernetes/pki/etcd"
alias manifest="cd /etc/kubernetes/manifests"
export PATH=/.kubectx:$PATH
export do="-o yaml --dry-run=client"
export sys="-n kube-system"
export ETCDCTL_API=3
Liste o nome, o status e a função de todos os nós no cluster:
oc get nodes
Resuma o uso de CPU e memória para cada nó no cluster:
oc adm top nodes
Resuma o uso de CPU e memória para um nó específico:
oc adm top node <nome do node>
Verificar a saúde de todos operators do cluster:
oc get co
Verificar os detalhes do nodes e eventos:
oc describe node <node do node>
Verificar status do kubelet no nós: Como será executado nos nodes do ocp:
systemctl is-active kubelet
systemctl status kubelet.service
Consulte kubelet journaldlogs de unidade de nós de cluster do OpenShift. O exemplo mostra logs do kubelet nos nodes master:
oc adm node-logs --role=master -u kubelet
Colete logs de subdiretórios específicos /var/log/em nós de cluster.
- Recupere uma lista de logs contidos em um /var/log/subdiretório. O exemplo a seguir lista os arquivos em /var/log/openshift-apiserver/todos os nós do plano de controle:
$ oc adm node-logs --role=master --path=openshift-apiserver
- Inspecione um log específico em um /var/log/subdiretório. O exemplo a seguir gera o /var/log/openshift-apiserver/audit.logconteúdo de todos os nós do plano de controle:
$ oc adm node-logs --role=master --path=openshift-apiserver/audit.log
- Se a API não estiver funcional, revise os logs em cada nó usando SSH. As caudas de exemplo a seguir /var/log/openshift-apiserver/audit.log:
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log
Verificar status dos (PVs):
$ oc get pv
Mostra todos os pods com erros no cluster de todos namespaces:
Exemplo:
CrashLoopBackOff ErrImagePull Error
oc get pods --all-namespaces|egrep -v 'Running | Completed'
Verifique se há pods com uma contagem de reinicialização alta. Mesmo se estiverem em um estado Running, uma contagem alta de reinicialização pode indicar problemas subjacentes. No exemplo abaixo lista namespaces com pods que reiniciaram mais de 3 vezes:
oc get pods --all-namespaces --field-selector=status.phase=Running -o json | jq '.items[]|select(any( .status.containerStatuses[]; .restartCount > 3))|.metadata.name'
Verificando a saúde no etcd:
Verifique o status da condição de EtcdMembersAvailablestatus usando o seguinte comando:
oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'
Verificar status API service:
Verificando a conectividade de rede para um endpoint:
oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
Verificar se existem csr pendentes de aprovação. ( Possuimos um rotina que aprovar automaticamente os certificados)
oc get csr
Verifique se os aplicativos não estão usando referências obsoletas da API do Kubernetes. O MTC avisará você sobre quaisquer recursos usando referências obsoletas da API do Kubernetes.
(Opcional) Informações adicionais sobre o utilitário
ETCDCTL ETCDCTL é a ferramenta CLI usada para interagir com o ETCD.
O ETCDCTL pode interagir com o ETCD Server usando 2 versões de API - Versão 2 e Versão 3. Por padrão, está configurado para usar a Versão 2. Cada versão possui conjuntos de comandos diferentes.
Por exemplo, o ETCDCTL versão 2 oferece suporte aos seguintes comandos:
etcdctl backup
etcdctl cluster-health
etcdctl mk
etcdctl mkdir
etcdctl set
Considerando que os comandos são diferentes na versão 3
etcdctl snapshot save
etcdctl endpoint health
etcdctl get
etcdctl put
Para definir a versão correta da API, defina o comando ETCDCTL_API da variável de ambiente
export ETCDCTL_API=3
Quando a versão da API não está definida, supõe-se que esteja definida para a versão 2. E os comandos da versão 3 listados acima não funcionam. Quando a versão da API é definida para a versão 3, os comandos da versão 2 listados acima não funcionam.
Além disso, você também deve especificar o caminho para os arquivos de certificado para que o ETCDCTL possa se autenticar no ETCD API Server. Os arquivos de certificado estão disponíveis no etcd-master no caminho a seguir. Discutimos mais sobre certificados na seção de segurança deste curso. Portanto, não se preocupe se isso parecer complexo:
--cacert /etc/kubernetes/pki/etcd/ca.crt
--cert /etc/kubernetes/pki/etcd/server.crt
--key /etc/kubernetes/pki/etcd/server.key
Portanto, para que os comandos que mostrei anteriormente funciona, você deve especificar a versão da API ETCDCTL e o caminho para os arquivos de certificado. Abaixo segue o formulário final:
kubectl exec etcd-master -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl get / --prefix --keys-only --limit=10 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key"
Affinity - Taints - Tolerations
- Imagens Uma imagem de contêiner representa dados binários que encapsulam uma aplicação e todas as suas dependências de software. As imagens de contêiner são pacotes de software executáveis que podem ser executados de forma autônoma e que fazem suposições muito bem definidas sobre seu agente de execução do ambiente
- Conteiner É um sistema de código aberto que foi desenvolvido pelo Google para gerenciamento de aplicativos em containers através de múltiplos hosts de um cluster. Tem como principal objetivo facilitar a implantação de aplicativos baseados em microsserviço
- Pod Os pods são as menores unidades de computação implantáveis que você pode criar e gerenciar no Kubernetes. Um pod é um grupo de um ou mais containers, com recursos de armazenamento, rede compartilhada e uma especificação de como executar os contêineres.
- Worker Node Consiste em um conjunto de servidores de processamento, chamados nós, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (worker node). O servidor de processamento hospeda os Pods que são componentes de uma aplicação.
- Kubelet Um agente que é executado em cada node no cluster. Ele garante que os contêineres estejam sendo executados em um Pod. O kubelet utiliza um conjunto de PodSpecs que são fornecidos por vários mecanismos e garante que os contêineres descritos nesses PodSpecs estejam funcionando corretamente.
- Kube-proxy O kube-proxy é um proxy de rede executado em cada node do cluster, implementando o conceito de serviço do Kubernetes. Além disso, este componente mantém regras de rede nos nodes, permitindo a comunicação com seus pods a partir de sessões de rede dentro ou fora do cluster.
- Master Node Um nó mestre é um nó que controla e gerencia um conjunto de Worker Nodes (tempo de execução de cargas de trabalho) e se assemelha a um cluster no Kubernetes. Um nó mestre tem os seguintes componentes para ajudar a gerenciar nós do trabalhador:
- Kube-APIServer Ele atua como front-end para o cluster. Toda comunicação externa com o cluster é via API-Server.
- Etcd É o banco de dados de estado do cluster. O etcd é, na verdade, o nome da base de dados distribuída que é utilizada para armazenar tudo o que está acontecendo dentro do cluster, incluindo o estado da aplicação. Em ambientes de produção, um bom gerenciamento desses nós é essencial para garantir que o cluster esteja sempre disponível.
- Kubes-cheduler Que é responsável por agendar aplicativos oucontêineres em Nodes. É também chamado de agendador. Sua função é definir cargas de trabalho para nodes específicos. Para definir os trabalhos, o kube-scheduler leva em consideração fatores como: Recursos individuais e coletivos.
- Controller Manager É o componente do master que roda os controladores. Pensando pela lógica, cada controle tem um processo diferente, mas para reduzir a complexidade, eles são compilados em um único binário e rodam em um único processo. é um daemon que incorpora os loops de controle principais enviados com o Kubernetes. Em aplicações de robótica e automação, um loop de controle é um loop sem terminação que regula o estado do sistema. No Kubernetes, um controlador é um loop de controle que observa o estado compartilhado do cluster por meio do apiserver e faz alterações tentando mover o estado atual para o estado desejado. Exemplos de controladores que acompanham o Kubernetes hoje são o controlador de replicação, o controlador de endpoints, o controlador de namespace e o controlador de contas de serviço.
11a. Node-Controller
O Node Controller é responsável por inicializar um nó obtendo informações sobre os nós em execução no cluster do provedor de nuvem. O Node Controller executa as seguintes funções:
- Inicializar um node com labels de região/zona específicos para a nuvem.
- Inicialize um node com detalhes de instância específicos da nuvem, por exemplo, tipo e tamanho.
- Obtenha os endereços de rede e o nome do host do node.
- No caso de um node não responder, verifique a nuvem para ver se o node foi excluído da nuvem. Se o node foi excluído da nuvem, exclua o objeto Node do Kubernetes
11b. Replication-Controller Garante que um número especificado de réplicas de pod esteja em execução a qualquer momento. Em outras palavras, um ReplicationController garante que um pod ou um conjunto homogêneo de pods esteja sempre ativo e disponível.
As cotas de recursos garantem uma quantidade fixa de recursos de computação para um determinado cluster virtual, reservando os recursos citados para uso exclusivo em um único namespace definido.
Os compromissos excessivos decorrentes de cotas de recursos generosamente definidas são um motivo comum para o aumento do custo da infraestrutura. No entanto, cotas de recursos subcomprometidas correm o risco de degradar o desempenho do seu aplicativo.
Você também pode usar cotas de recursos para limitar o número de objetos criados por um determinado tipo ou por seu consumo de recursos no namespace.
Exemplo
Vamos criar uma cota de recursos em vários pods.
Primeiro, especificaremos um limite rígido de 2 pods. Isso significa que só é possível criar 2 pods no namespace padrão.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
name: pod-examples
spec:
hard:
pods: "2"
EOF
Com as Cotas de Recursos, vimos como você pode colocar uma restrição no consumo de recursos com base em namespaces. No entanto, os objetos criados no namespace definido ainda podem utilizar todos os recursos disponíveis nesse namespace. Isso pode fazer com que um objeto utilize todos os recursos disponíveis, essencialmente deixando os outros sem energia.
Os intervalos de limite superam esse problema definindo limites mínimos e máximos na CPU, RAM e solicitações de armazenamento por PVC em um namespace no nível do objeto.
Exemplo Vamos definir um limite que defina a alocação mínima e máxima de memória. Especificaremos um limite máximo de 1 GB e um limite mínimo de 500 MB.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: LimitRange
metadata:
name: min-max-memory-demo
spec:
limits:
- max:
memory: 1Gi
min:
memory: 500Mi
type: Container
EOF
O tipo padrão é ClusterIP. Para expor um serviço em um endereço IP externo, você precisa criar um ServiceType diferente de ClusterIP.
Tipos de serviço disponíveis:
ClusterIP : expõe o serviço em um IP interno do cluster. Este é o ServiceType padrão.
NodePort : Expõe o serviço no IP de cada nó em uma porta estática (o NodePort). Um Serviço ClusterIP, para o qual o Serviço NodePort roteia, é criado automaticamente. Você poderá entrar em contato com o Serviço NodePort, de fora do cluster, solicitando NodeIP: NodePort.
LoadBalancer : expõe o serviço externamente usando o balanceador de carga de um provedor de nuvem. Os serviços NodePort e ClusterIP, para os quais o balanceador de carga externo roteia, são criados automaticamente.
ExternalName : Mapeia o serviço para o conteúdo do campo externalName (por exemplo, foo.bar.example.com), retornando um registro CNAME.
$ echo -e "NAMESPACE\tNAME\tEXPIRY" && oc get secrets -A -o go-template='{{range .items}}{{if eq .type "kubernetes.io/tls"}}{{.metadata.namespace}}{{" "}}{{.metadata.name}}{{" "}}{{index .data "tls.crt"}}{{"\n"}}{{end}}{{end}}' | while read namespace name cert; do echo -en "$namespace\t$name\t"; echo $cert | base64 -d | openssl x509 -noout -enddate; done | column -t
Retorno pode demorar, pois são muitos certificados.
- Listar todos os namespaces no cluster
kubectl get namespaces
kubectl get ns
- Liste todos os pods em todos os namespaces
kubectl get po --all-namespaces
- Liste todos os pods no namespace específico
kubectl get po -n <nome do namespace>
- Liste todos os serviços no namespace específico
kubectl get svc -n <nome do namespace>
- Liste todos os pods mostrando o nome e o namespace com uma expressão no formato json
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'metadata.namespace']}"
- Crie um pod nginx em um namespace padrão e verifique o pod em execução
kubectl run nginx --image=nginx --restart=Never
Lista o pod
kubectl get po
- Crie o mesmo pod nginx com um arquivo yaml
// obtém o arquivo yaml com o parametro --dry-run
kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx-pod.yaml
// cat nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
// criar pod
kubectl create -f nginx-pod.yaml
- Gere o arquivo yaml do pod que você acabou de criar
kubectl get po nginx -o yaml
- Gere o arquivo yaml do pod que você acabou de criar sem as informações específicas do cluster
kubectl get po nginx -o yaml --export
- Obtenha os detalhes completos do pod que você acabou de criar
kubectl decribe o pod nginx
- Exclua o pod que você acabou de criar
kubectl delete po nginx
kubectl delete -f nginx-pod.yaml
- Exclua o pod que você acabou de criar (exclusão forçada)
kubectl delete po nginx --grace-period=0 --force
- Crie o pod nginx com a versão 1.17.4 e exponha-o na porta 80
kubectl run nginx --image=nginx:1.17.4 --restart=never --port=80
- Altere a versão da imagem para 1.15-alpine para o pod que você acabou de criar e verifique se a versão da imagem está atualizada
kubectl set image pod/nginx nginx=nginx:1.15-alpine
kubectl discrebe po nginx
// de outra forma ele abrirá o editor vi e mudará a versão
kubeclt edit po nginx
kubectl discribe po nginx
- Altere a versão da imagem de volta para 1.17.1 para o pod que você acabou de atualizar e observe as alterações
kubectl set image pod/nginx nginx=nginx:1.17.1
kubectl describe po nginx
kubectl get po nginx -w # flag "w" serve pra assistir o processo.
- Verifique a versão da imagem sem o comando describe, carrega informações do Json
kubectl get po nginx -o jsonpath='{.spec.containers[].image}{"\n"}'
- Crie o pod nginx e execute o shell simples no pod
// criando um pod
kubectl run nginx --image=nginx --restart=Never
// exec no pod
kubectl exec -it nginx /bin/sh
- Obtenha o endereço IP do pod que você acabou de criar e informações detalhadas:
kubectl get po nginx -o wide
- Crie um pod do busybox e execute o comando ls ao criá-lo e verifique os logs
kubectl run busybox --image=busybox --restart=never --bin/sh
**Pod para depuração ao vivo de um comando por exemplo. **
busybox há um shell básico que contém utilitários úteis. Por Exemplo nslookup, wget, nslookup. É útil resolução de problema:
kubectl logs busybox
Exemplo legal: # Tem como montar um volume e difinir um numero de replicas.
apiVersion: apps/v1
kind: Deployment
metadata:
name: wrx-busybox
namespace: default
spec:
progressDeadlineSeconds: 600
replicas: 2
selector:
matchLabels:
run: busybox
template:
metadata:
labels:
run: busybox
spec:
containers:
- args:
- sh
image: busybox
imagePullPolicy: Always
name: busybox
stdin: true
tty: true
volumeMounts:
- name: pvc1
mountPath: "/mnt1"
restartPolicy: Always
volumes:
- name: pvc1
persistentVolumeClaim:
claimName: rwx-test-claim
-
ReadWriteOnce: O volume pode ser montado como leitura/gravação por um único nó.
-
ReadOnlyMany: O volume pode ser montado somente leitura por muitos nós.
-
ReadWriteMany: O volume pode ser montado como leitura/gravação por muitos nós.
- Se o pod travar, verifique os logs anteriores do pod
kubectl logs busybox -p
- Crie um pod do busybox com o comando sleep 3600
kubectl run busybox --image=busybox --restart=Nunca -- /bin/sh -c "sleep 3600"
- Verifique a conexão do pod nginx do pod do busybox ( porta )
kubectl get po nginx -o wide
// verifica a conexão
kubectl exec -it busybox -- wget -o- <IP Address>
- Crie um pod do busybox e descreva a saída 'e ai mane' e exclua-o manualmente
kubectl run busybox --image=nginx --restart=Never -it -- echo "e ai mané"
kubectl delete pod busybox
- Crie um pod do busybox e de um echo a mensagem 'How are you' e exclua-o imediatamente // observe o sinalizador
kubectl run busybox --image=nginx --restart=Never -it -- echo "How are you"
kubectl delete po busybox
- Crie um pod nginx e liste o pod com diferentes níveis de detalhamento
// cria um pod
kubectl run nginx --image=nginx --restart=Never --port=80
// Lista o pod com detalhes diferentes
kubectl get po nginx --v=7
kubectl get po nginx --v=8
kubectl get po nginx --v=9
- Liste o pod nginx com colunas personalizadas POD_NAME e POD_STATUS
kubectl get po -o=custom-columns="POD_NAME:.metadata.name, POD_STATUS:.status.containerStatuses[].state"
- Liste todos os pods classificados por nome
kubectl get pods --sort-by=.metadata.name
- Liste todos os pods classificados por label de data/hora criado
kubectl get pods--sort-by=.metadata.creationTimestamp
Pods de vários contêineres (10%)
- Crie um Pod com três contêineres que vai executar o comandos “sleep; ls" “echo Olá Mundo; dormir 3600;”
// primeiro cria um pod de contêiner único com sinalizador de simulação (--dry-run)
kubectl run busybox --image=busybox --restart=Nunca --dry-run -o yaml -- bin/sh -c "sleep 3600; ls" > multi-container.yaml
// edite o pod para o seguinte yaml e crie-o
kubectl create -f multi-container.yaml
kubectl get po busybox
cápsula de vários contêineres
- Verifique os logs de cada contêiner que você acabou de criar
kubectl logs busybox -c busybox1
kubectl logs busybox -c busybox2
kubectl logs busybox -c busybox3
- Verifique os logs anteriores do segundo container busybox2 se houver
kubectl logs busybox -c busybox2 --previous
- Execute o comando ls no terceiro container busybox3 do pod acima
kubectl exec busybox -c busybox3 -- ls
- Mostre as métricas dos contêineres de pods acima e coloque-os no arquivo.log e verifique
kubectl top pod busybox --containers
// colocando-os no arquivo
kubectl top pod busybox --containers > file.log
cat file.log
- Crie um Pod com o container principal busybox e que execute este “while true; do echo 'Olá, sou do container principal' >> /var/log/index.html; dormir 5; done” e com contêiner sidecar com imagem nginx que expõe na porta 80. Use o volume emptyDir e monte este volume no caminho /var/log para busybox e no caminho /usr/share/nginx/html para contêiner nginx. Verifique se ambos os contêineres estão em execução.
// cria um arquivo yaml inicial com este kubectl run multi-cont-pod --image=busbox --restart=Never --dry-run -o yaml > multi-container.yaml
// edite o yml como abaixo e crie-o
kubectl create -f multi-container.yaml
kubectl get po multi-cont-pod
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: multi-cont-pod
name: multi-cont-pod
spec:
volumes:
- name: var-logs
emptyDir: {}
containers:
- image: busybox
command: ["/bin/sh"]
args: ["-c", "while true; do echo 'Hi I am from Main container' >> /var/log/index.html; sleep 5;done"]
name: main-container
resources: {}
volumeMounts:
- name: var-logs
mountPath: /var/log
- image: nginx
name: sidecar-container
resources: {}
ports:
- containerPort: 80
volumeMounts:
- name: var-logs
mountPath: /usr/share/nginx/html
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
- Execute em ambos os contêineres e verifique se main.txt existe e consulte o main.txt do contêiner sidecar com curl localhost
// exec no container principal
kubectl exec -it multi-cont-pod -c main-container -- sh
cat /var/log/main.txt
// exec no container sidecar
kubectl exec -it multi-cont-pod -c sidecar-container -- sh
cat /usr/share/nginx/html/index.html
// instala o curl e obtém a página padrão
kubectl exec -it multi-cont-pod -c sidecar-container -- sh
apt-get update && apt-get install -y curl
curl localhost
Design de cápsula (20%)
- Obtenha os pods com informações do rótulo
kubectl pods pods --show-labels
- Crie 5 pods nginx em que dois deles com a label como env=prod e três deles são label como env=dev
kubectl run nginx-dev1 --image=nginx --restart=Never --labels=env=dev
kubectl run nginx-dev2 --image=nginx --restart=Never --labels=env=dev
kubectl run nginx-dev3 --image=nginx --restart=Never --labels=env=dev
kubectl run nginx-prod1 --image=nginx --restart=Never --labels=env=prod
kubectl run nginx-prod2 --image=nginx --restart=Never --labels=env=prod
- Verifique se todos os pods foram criados com os rótulos corretos
kubeclt get pods --show-labels
- Obtenha os pods com o rótulo env=dev
kubectl get pods -l env=dev
- Obtenha os pods com o rótulo env=dev e também produza os rótulos
kubectl get pods -l env=dev --show-labels
- Obtenha os pods com o rótulo env=prod
kubectl get pods -l env=prod
- Obtenha os pods com o rótulo env=prod e também produza os rótulos
kubectl get pods -l env=prod --show-labels
- Obtenha os pods com rótulo env
kubectl gst pods -L env
- Obtenha os pods com rótulos env=dev e env=prod
kubectl get pods -l 'env in (dev,prod)'
- Obtenha os pods com rótulos env=dev e env=prod e produza os rótulos também
kubectl get pods -l 'env in (dev,prod)' --show-labels
- Altere o rótulo de um dos pods para env=uat e liste todos os pods para verificar
kubectl label pod/nginx-dev3 env=uat --overwrite
kubectl get pods --show-labels
- Remova os rótulos dos pods que criamos agora e verifique se todos os rótulos foram removidos
kubectl label pod nginx-dev{1..3} env-
kubectl label pod nginx-prod{1..2} env-
kubectl get po --show-labels
- Vamos adicionar o rótulo app=nginx para todos os pods e verificar
kubectl label pod nginx-dev{1..3} app=nginx
kubectl label pod nginx-prod{1..2} app=nginx
kubectl get po --show-labels
- Obtenha todos os nós com rótulos (se estiver usando o minikube, você obterá apenas o nó mestre)
kubectl get nodes --show-labels
- Rotule o nó (minikube se você estiver usando) nodeName=nginxnode
kubectl label node minikube nodeName = nginxnode
- Crie um pod que será implantado neste nó com o rótulo nodeName=nginxnode
kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > pod.yaml
// adicione o nodeSelector como abaixo e crie o pod
kubectl create -f pod.yaml
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
nodeSelector:
nodeName: nginxnode
containers:
- image: nginx
name: nginx
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}```
52. Verifique se o pod está agendado com o seletor de nó
`kubectl describe po nginx | grep Node-Selectors`
53. Verifique se o pod nginx que acabamos de criar tem esse rótulo
`kubectl describe po nginx | grep labels`
54. Anote os pods com name=webapp
`kubectl annotate pod nginx-dev{1..3} name=webapp `
`kubectl annotate pod nginx-prod{1..2} name=webapp`
55. Verifique os pods que foram anotados corretamente
`kubectl describe po nginx-dev{1..3} | grep -i annotations`
`kubectl describe po nginx-prod{1..2} | grep -i annotations`
56. Remova as anotações nos pods e verifique
`kubectl annotate pod nginx-dev{1..3} name-`
`kubectl annotate pod nginx-prod{1..2} name-`
`kubectl describe po nginx-dev{1..3} | grep -i annotations`
`kubectl describe po nginx-prod{1..2} | grep -i annotations`
57. Remova todos os pods que criamos até agora
`kubectl delete po --all`
58. Crie uma implantação chamada webapp com imagem nginx com 5 réplicas
kubectl create deploy webapp --image=nginx --dry-run -o yaml > webapp.yaml
// altere as réplicas para 5 no yaml e crie
kubectl create -f webapp.yaml
apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: webapp name: webapp spec: replicas: 5 selector: matchLabels: app: webapp strategy: {} template: metadata: creationTimestamp: null labels: app: webapp spec: containers: - image: nginx name: nginx resources: {} status: {}
59. Obtenha a implantação que você acabou de criar com rótulos
`kubectl get deploy webapp --show-labels`
60. Gere o arquivo yaml da implantação que você acabou de criar
`kubectl get deploy webapp -o yaml`
61. Obtenha os pods desta implantação
// obtém o rótulo da implantação
`kubectl get deploy --show-labels`
// obtém os pods com esse rótulo
`kubectl get pods -l app=webapp`
62. Dimensione a implantação de 5 réplicas para 20 réplicas e verifique
`kubectl scale deploy webapp --replicas=20`
`kubectl get po -l app = webapp`
63. Obtenha o status de implementação da implantação
`kubectl rollout status deploy webapp`
64. Obtenha o conjunto de réplicas criado com esta implantação
`kubectl get rs -l app=webapp`
65. Obtenha o yaml do replicaset e pods desta implantação
`kubectl get rs -l app=webapp -o yaml `
`kubectl get po -l app=webapp -o yaml`
66. Exclua a implantação que você acabou de criar e observe que todos os pods também estão sendo excluídos
`kubectl delete deploy webapp`
`kubectl get po -l app=webapp -w`
67. Crie uma implantação do webapp com a imagem nginx:1.17.1 com a porta do contêiner 80 e verifique a versão da imagem
`kubectl create deploy webapp --image=nginx:1.17.1 --dry-run -o yaml > webapp.yaml`
// adicione a seção da porta e crie a implantação
`kubectl create -f webapp.yaml`
// verifica
`kubectl describe deploy webapp | grep Imagem `
apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: webapp name: webapp spec: replicas: 1 selector: matchLabels: app: webapp strategy: {} template: metadata: creationTimestamp: null labels: app: webapp spec: containers: - image: nginx:1.17.1 name: nginx ports: - containerPort: 80 resources: {} status: {}
68. Atualize a implantação com a imagem versão 1.17.4 e verifique
`kubectl set image deploy/webapp nginx=nginx:1.17.4`
`kubectl describe deploy webapp | grep Image`
69. Verifique o histórico de Deploy e certifique-se de que está tudo ok após a atualização
`kubectl rollout history deploy webapp`
`kubectl get deploy webapp --show-labels`
`kubectl get rs -l app=webapp` rs = Replicaset
`kubectl get po -l app=webapp`
70. Desfaça a implantação para a versão anterior 1.17.1 e verifique se a imagem tem a versão anterior
`kubectl rollout undo deploy webapp`
`kubectl describe deploy webapp | grep Image`
71. Atualize a implantação com a imagem versão 1.16.1 e verifique a imagem e também o histórico de implantação
`kubectl set image deploy/webapp nginx=nginx:1.16.1`
`kubectl descreve o deploy da webapp | Imagem grep`
`kubectl rollout history deploy webapp`
72. Atualize a implantação para a Imagem 1.17.1 e verifique se está tudo ok
`kubectl set image deploy/webapp nginx=nginx:1.16.1`
`kubectl describe deploy webapp | grep Image`
`kubectl rollout history deploy webapp`
73. Atualize a implantação com a imagem errada versão 1.100 e verifique se há algo errado com a implantação
`kubectl set image deploy/webapp nginx=nginx:1.100`
`kubectl rollout status deploy webapp (still pending state)`
`kubectl get pods (ImagePullErr)`
74. Desfaça a implantação com a versão anterior e verifique se está tudo bem
`kubectl rollout undo deploy webapp`
`kubectl rollout status deploy webapp`
`kubectl get pods`
75. Verifique o histórico da revisão específica dessa implantação
`kubectl rollout history deploy webapp --revision=7`
76. Pausar o lançamento da implantação
`kubectl rollout pause deploy webapp`
77. Atualize a implantação com a versão da imagem mais recente e verifique o histórico e verifique se nada está acontecendo
`kubectl set image deploy/webapp nginx=nginx:latest`
`kubectl rollout history deploy webapp` (sem nova revisão)
78. Retome a distribuição da implantação
`kubectl rollout resume deploy webapp`
79. Verifique o histórico de lançamentos e verifique se tem a nova versão
`kubectl rollout history deploy webapp`
`kubectl rollout history deploy webapp --revision=9`
80. Aplique o escalonamento automático a esta implantação com no mínimo 10 e no máximo 20 réplicas e CPU de destino de 85% e
verifique se o hpa foi criado e as réplicas foram aumentadas para 10 de 1
`kubectl autoscale deploy webapp --min=10 --max=20 --cpu-percent=85`
`kubectl get hpa`
`kubectl get pod -l app=webapp`
81. Limpe o cluster excluindo a implantação e o hpa que você acabou de criar
`kubectl delete deploy webapp`
`kubectl delete hpa webapp`
82. Crie um trabalho com um nó de imagem que imprime a versão do nó e também verifica se há um pod criado para este trabalho
`kubectl create job nodeversion --image=node -- node -v`
`kubectl get job -w`
`kubectl get pod`
83. Obtenha os logs do trabalho recém-criado
`kubectl logs <nome do pod> // criado a partir do trabalho`
84. criar um arquivo yaml para o trabalho com a imagem busybox que echo "Olá, sou do trabalho"
`kubectl create job hello-job --image=busybox --dry-run -o yaml -- echo "Olá, sou do trabalho"`
85. Copie o arquivo YAML acima para o arquivo hello-job.yaml e crie o trabalho
`kubectl create job hello-job --image=busybox --dry-run -o yaml -- echo "Olá, sou do trabalho" > hello-job.yaml`
`kubectl create -f hello-job.yaml`
86. Verifique se o trabalho e o pod associado foram criados e verifique os logs também
`kubectl get job`
`kubectl get po`
`kubectl logs hello-job-*`
87. Exclua o trabalho que acabamos de criar
`kubectl delete job hello-job`
88. Crie o mesmo trabalho e execute-o 10 vezes uma após nó
`kubectl create job hello-job --image=busybox --dry-run -o yaml -- echo "Hello I am from job" > hello-job.yaml`
// edit o yaml e adcione completions: 10
`kubectl create -f hello-job.yaml`
```
apiVersion: batch/v1
kind: Job
metadata:
creationTimestamp: null
name: hello-job
spec:
completions: 10
template:
metadata:
creationTimestamp: null
spec:
containers:
- command:
- echo
- Hello I am from job
image: busybox
name: hello-job
resources: {}
restartPolicy: Never
status: {} ```
89. Observe o trabalho que é executado 10 vezes e verifique se 10 pods foram criados e exclua-os após a conclusão
`kubectl get job -w`
`kubectl get po`
`kubectl delete job hello-job`
90. Crie o mesmo trabalho e execute-o 10 vezes em paralelo
`kubectl create job hello-job --image=busybox --dry-run -o yaml -- echo "e ai mané " > hello-job.yaml`
// edite o arquivo yaml para adicionar paralelismo: 10
`kubectl create -f hello-job.yaml`
```apiVersion: batch/v1
kind: Job
metadata:
creationTimestamp: null
name: hello-job
spec:
parallelism: 10
template:
metadata:
creationTimestamp: null
spec:
containers:
- command:
- echo
- Hello I am from job
image: busybox
name: hello-job
resources: {}
restartPolicy: Never
status: {}
```
91. Observe o trabalho que é executado 10 vezes paralelamente e verifique se 10 pods foram criados e exclua-os após a conclusão
`kubectl get job -w`
`kubectl get po`
`kubectl delete job hello-job`
92. Crie um Cronjob com uma imagem do busybox que imprima a data e a mensagem de saudação do cluster do kubernetes a cada minuto
`kubectl create cronjob date-job --image=busybox --schedule="*/1 * * * *" -- bin/sh -c "date; echo Hello from kubernetes cluster"`
93. Gere o arquivo YAML do cronjob acima
`kubectl get cj date-job -o yaml`
94. Verifique se o CronJob está criando um trabalho e pods separados para cada minuto para executar e verificar os logs do pod
`kubectl get job`
`kubectl get po`
`kubectl logs date-job-<jobid>-<pod>`
95. Exclua o CronJob e verifique se todos os trabalhos e pods associados também foram excluídos.
`kubectl delete cj date-job`
// verifica pods e jobs
`kubectl get po `
`kubectl get job`
Destativa uma chonjob.
# acesse o projecto com a cron
`oc get cronjobs `
`oc patch cronjobs <nome_cronjob> -p "{\"spec\" : {\"suspend\" : true }}"`
_________________________________________________________________________________________________________
Persistência do Estado (8%)
96. Listar Volumes Persistentes no cluster
kubectl get pv
97. Crie um hostPath PersistentVolume chamado task-pv-volume com armazenamento 10Gi, modos de acesso ReadWriteOnce, manual storageClassName
e volume em /mnt/data e verifique
`kubectl create -f task-pv-volume.yaml`
`kubectl get pv`
```
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
```
98. Crie um PersistentVolumeClaim de pelo menos 3Gi de armazenamento e modo de acesso ReadWriteOnce e verifique se o status está vinculado
`kubectl create -f task-pv-claim.yaml`
`kubectl get pvc`
`apiVersion: v1`
`kind: PersistentVolumeClaim`
`metadata:`
`name: task-pv-claim`
`spec:`
`storageClassName: manual`
`accessModes:`
`- ReadWriteOnce`
`resources:`
`requests:`
`storage: 3Gi`
99. Excluir volume persistente e PersistentVolumeClaim que acabamos de criar
`kubectl delete pvc task-pv-claim `
`kubectl delete pv task-pv-volume`
100. Crie um Pod com uma imagem Redis e configure um volume que dure a vida útil do Pod
// emptyDir é o volume que dura a vida do pod
`kubectl create -f redis-storage.yaml`
101. Execute no pod acima e crie um arquivo chamado file.txt com o texto 'teste de arquivo'
no caminho /data/redis e abra outra guia e execute novamente com o mesmo pod e verifique se o arquivo existe no mesmo caminho.
// primeiro terminal
`kubectl exec -it redis-storage /bin/sh `
`cd /data/redis `
`echo 'Isso é um arquivo' > file.txt`
//abre outra aba
`kubectl exec -it redis-storage /bin/sh `
`cat /data/redis/file.txt`
102. Exclua o pod acima e crie novamente a partir do mesmo arquivo yaml e verifique se não há file.txt no caminho /data/redis
`kubectl delete pod redis`
`kubectl create -f redis-storage.yaml `
`kubectl exec -it redis-storage /bin/sh `
`cat /data/redis/file.txt // arquivo não existe`
103. Crie PersistentVolume chamado task-pv-volume com armazenamento 10Gi, modos de acesso ReadWriteOnce, manual storageClassName e volume em /mnt/data e Crie um PersistentVolumeClaim de pelo menos 3Gi de armazenamento e modo de acesso ReadWriteOnce e verifique se o status é Bound
`kubectl create -f task-pv-volume.yaml `
`kubectl create -f task-pv-claim.yaml`
`kubectl get pv `
`kubectl get pvc`
104. Crie um pod nginx com containerPort 80 e com um PersistentVolumeClaim task-pv-claime tenha um caminho de "/usr/share/nginx/html"
`kubectl create -f task-pv-pod.yaml`
```
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
```
_________________________________________________________________________________________
Configuração (18%)
Pratique perguntas com base nesses conceitos
Compreender os ConfigMaps
Compreender os contextos de segurança
Definir os requisitos de recursos de um aplicativo
Crie e consuma segredos
Compreender as contas de serviço
105. Liste todos os configmaps no cluster
`kubectl get cm `
`kubectl get configmap`
106. Crie um configmap chamado myconfigmap com valor literal appname=myapp
`kubectl create cm myconfigmap --from-literal=appname=myapp`
107. Verifique se o configmap que acabamos de criar tem esses dados
`kubectl get cm -o yaml`
`kubectl describe cm`
108. exclua o configmap myconfigmap que acabamos de criar
`kubectl delete cm myconfigmap`
109. Crie um arquivo chamado config.txt com dois valores key1=value1 e key2=value2 e verifique o arquivo
```
cat >> config.txt << EOF
key1=value1
key2=value2
EOF
cat config.txt
```
ativar e desatibar cronjob
oc get cronjobs | grep False | cut -d' ' -f 1 | xargs kubectl patch cronjobs -p '{"spec" : {"suspend" : true }}'
Troce o true por false e casa de ativação
110. Crie um configmap chamado keyvalcfgmap e leia os dados do arquivo config.txt e verifique se o configmap foi criado corretamente
`kubectl create cm keyvalcfgmap --from-file=config.txt`
`kubectl get cm keyvalcfgmap -o yaml`
111. Crie um pod nginx e carregue os valores de ambiente do configmap keyvalcfgmap e exec acima no pod e verifique as variáveis de ambiente e exclua o pod
// primeiro execute este comando para salvar o pod yml
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx-pod.yml`
// edite o yml para o arquivo abaixo e crie
`kubectl create -f nginx-pod.yml`
// verifica
`kubectl exec -it nginx -- env`
`kubectl delete po nginx`
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
envFrom:
- configMapRef:
name: keyvalcfgmap
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
112. Crie um arquivo env file.env com var1=val1 e crie um configmap envcfgmap deste arquivo env e verifique o configmap
`echo var1=val1 > file.env`
`cat file.env`
`kubectl create cm envcfgmap --from-env-file=file.env`
`kubectl get cm envcfgmap -o yaml --export`
113. Crie um pod nginx e carregue os valores de ambiente do configmap envcfgmap e exec acima no pod e verifique as variáveis de ambiente e exclua o pod
// primeiro execute este comando para salvar o pod yml
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx-pod.yml`
// edite o yml para o arquivo abaixo e crie
`kubectl create -f nginx-pod.yml`
// verifica
`kubectl exec -it nginx -- env`
`kubectl delete po nginx`
nginx-pod.yaml
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
env:
- name: ENVIRONMENT
valueFrom:
configMapKeyRef:
name: envcfgmap
key: var1
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
114. Crie um configmap chamado cfgvolume com valores var1=val1, var2=val2 e crie um pod nginx com volume nginx-volume que lê os dados deste configmap cfgvolume e
coloque-o no caminho /etc/cfg
// primeiro cria um configmap cfgvolume
kubectl create cm cfgvolume --from-literal=var1=val1 --from-literal=var2=val2
// verifica o configmap
kubectl describe cm cfgvolume
// cria o mapa de configuração
kubectl create -f nginx-volume.yml
// exec no pod
kubectl exec -it nginx -- /bin/sh
// verifica o caminho
cd /etc/cfg
ls
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
volumes:
- name: nginx-volume
configMap:
name: cfgvolume
containers:
- image: nginx
name: nginx
resources: {}
volumeMounts:
- name: nginx-volume
mountPath: /etc/cfg
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
115. Crie um pod chamado secbusybox com a imagem busybox que executa o comando sleep 3600 e garante que todos os Containers no Pod, todos os processos sejam
executados com ID de usuário 1000 e com ID de grupo 2000 e verifiquem.
// cria arquivo yml com execução a seco
`kubectl run secbusybox --image=busybox --restart=Nunca --dry-run -o yaml -- /bin/sh -c "sleep 3600;" > busybox.yml`
// edite o pod como abaixo e crie
`kubectl create -f busybox.yml`
// verifica
`kubectl exec -it secbusybox -- sh `
id // mostrará o id e o grupo
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: secbusybox
name: secbusybox
spec:
securityContext: # add security context
runAsUser: 1000
runAsGroup: 2000
containers:
- args:
- /bin/sh
- -c
- sleep 3600;
image: busybox
name: secbusybox
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
116. Crie o mesmo pod acima desta vez, defina o securityContext para o contêiner e verifique se o securityContext do contêiner substitui o securityContext
no nível do pod.
// create yml file with dry-run
`kubectl run secbusybox --image=busybox --restart=Never --dry-run -o yaml -- /bin/sh -c "sleep 3600;" > busybox.yml`
// edit the pod like below and create
`kubectl create -f busybox.yml`
// verify
`kubectl exec -it secbusybox -- sh`
id // you can see container securityContext overides the Pod level
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: secbusybox
name: secbusybox
spec:
securityContext:
runAsUser: 1000
containers:
- args:
- /bin/sh
- -c
- sleep 3600;
image: busybox
securityContext:
runAsUser: 2000
name: secbusybox
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
117. Crie um pod com uma imagem nginx e configure o pod com recursos NET_ADMINe SYS_TIME verifique os recursos
// cria o arquivo yaml
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx.yml`
// edite conforme abaixo e crie pod
`kubectl create -f nginx.yml`
// executa e verifica
`kubectl exec -it nginx -- sh `
`cd /proc/1 `
`cat status`
// você deve ver esses valores
CapPrm: 00000000aa0435fb
CapEff: 00000000aa0435fb
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
securityContext:
capabilities:
add: ["SYS_TIME", "NET_ADMIN"]
name: nginx
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
118. Crie um Pod nginx e especifique uma solicitação de memória e um limite de memória de 100 Mi e 200 Mi, respectivamente.
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx.yml`
`kubectl create -f nginx.yml`
`kubectl top pod`
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
requests:
memory: "100Mi"
limits:
memory: "200Mi"
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
119. Crie um Pod nginx e especifique uma solicitação de CPU e um limite de CPU de 0,5 e 1, respectivamente.
// cria um arquivo ymal
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx.yml`
// adiciona a seção de recursos e cria
`kubectl create -f nginx.yml`
// verifica
`kubectl top pod`
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
requests:
cpu: "0.5"
limits:
cpu: "1"
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
120. Crie um Pod nginx e especifique a CPU, as solicitações de memória e os limites juntos e verifique.
// cria um arquivo yml
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx.yml`
// adiciona a seção de recursos e cria
`kubectl create -f nginx.yml`
// verifica
`kubectl top pod`
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
requests:
memory: "100Mi"
cpu: "0.5"
limits:
memory: "200Mi"
cpu: "1"
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
121. Crie um Pod nginx e especifique uma solicitação de memória e um limite de memória de 100 Gi e 200 Gi, respectivamente, que é muito grande para os nós e verifique se o pod falha ao iniciar devido à memória insuficiente
// cria um arquivo yml
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx.yml`
// adiciona a seção de recursos e cria
`kubectl create -f nginx.yml`
// verifica
`kubectl describe po nginx` // você pode ver o estado pendente
```
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
requests:
memory: "100Gi"
cpu: "0.5"
limits:
memory: "200Gi"
cpu: "1"
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
```
122. Crie um secret mysecret com os valores user=myuser e password=mypassword
`kubectl create secret generic my-secret --from-literal=username=user --from-literal=password=mypassword`
123. Liste os segredos em todos os namespaces
`kubectl get secret --all-namespaces`
124. Emita o yaml do segredo criado acima
`kubectl get secret my-secret -o yaml`
125. Crie um pod nginx que leia o nome de usuário como a variável de ambiente
// cria um arquivo yml
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx.yml`
// adiciona a seção env abaixo e cria
`kubectl create -f nginx.yml`
//verifica
kubectl exec -it nginx -- env
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: nginx name: nginx spec: containers:
- image: nginx
name: nginx
env:
- name: USER_NAME valueFrom: secretKeyRef: name: my-secret key: username resources: {} dnsPolicy: ClusterFirst restartPolicy: Never status: {}
126. Crie um pod nginx que carregue o segredo como variáveis de ambiente
// cria um arquivo yml
`kubectl run nginx --image=nginx --restart=Never --dry-run -o yaml > nginx.yml`
// adiciona a seção env abaixo e cria
`kubectl create -f nginx.yml`
//verifica
k`ubectl exec -it nginx -- env`
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: nginx name: nginx spec: containers:
- image: nginx
name: nginx
envFrom:
- secretRef: name: my-secret resources: {} dnsPolicy: ClusterFirst restartPolicy: Never status: {}
127. Liste todas as contas de serviço no namespace padrão
`kubectl get sa`
128. Liste todas as contas de serviço em todos os namespaces
`kubectl get sa --all-namespaces`
129. Crie uma conta de serviço chamada admin
`kubectl create sa admin`
130. Gere o arquivo YAML para a conta de serviço que acabamos de criar
`kubectl get sa admin -o yaml`
131. Crie um pod busybox que execute este comando sleep 3600 com o administrador da conta de serviço e verifique:
`kubectl run busybox --image=busybox --restart=Never --dry-run -o yaml -- /bin/sh -c "sleep 3600" > busybox.yml`
`kubectl create -f busybox.yml`
`kubectl describe po busybox`
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: busybox name: busybox spec: serviceAccountName: admin containers:
- args:
- /bin/sh
- -c
- sleep 3600 image: busybox name: busybox resources: {} dnsPolicy: ClusterFirst restartPolicy: Never status: {}
Observabilidade (18%)
Pratique perguntas com base nesses conceitos
Compreender LivenessProbes e ReadinessProbes
Entenda a geração de registros de contêiner
Entenda como monitorar aplicativos no kubernetes
Entender a depuração no Kubernetes
[Artigo e Referência ](https://medium.com/@AADota/kubernetes-liveness-and-readiness-probes-difference-1b659c369e17)
[Artigo de Referências ](https://rodrigomelgar.medium.com/liveness-rediness-f6344e12acfa)
132. Crie um pod nginx com containerPort 80 e ele só deve receber trafego somente ele verifica o endpoint/na porta 80 e verifica e exclui o pod.
`kubectl run nginx --image=nginx --restart=Nunca --port=80 --dry-run -o yaml > nginx-pod.yaml`
// adiciona a seção readinessProbe e cria
`kubectl create -f nginx-pod.yaml`
// verifica
`kubectl describe pod nginx | grep -i readiness`
kubectl delete po nginx
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: nginx name: nginx spec: containers:
- image: nginx
name: nginx
ports:
- containerPort: 80 readinessProbe: httpGet: path: / port: 80 resources: {} dnsPolicy: ClusterFirst restartPolicy: Never status: {}
133. Crie um pod nginx com containerPort 80 e ele deve verificar o pod em execução no endpoint / healthz na porta 80 e verificar e excluir o pod.
`kubectl run nginx --image=nginx --restart=Never --port=80 --dry-run -o yaml > nginx-pod.yaml`
// adiciona a seção livenessProbe e cria
`kubectl create -f nginx-pod.yaml`
// verifica
`kubectl describe pod nginx | grep -i readiness`
`kubectl delete po nginx`
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: nginx name: nginx spec: containers:
- image: nginx
name: nginx
ports:
- containerPort: 80 livenessProbe: httpGet: path: /healthz port: 80 resources: {} dnsPolicy: ClusterFirst restartPolicy: Never status: {}
134. Crie um pod nginx com containerPort 80 e ele deve verificar o pod rodando no endpoint /healthz na porta 80 e ele só deve receber tráfego
somente ele verifica o endpoint /na porta 80. verifique o pod.
`kubectl run nginx --image=nginx --restart=never --port=80 --dry-run -o yaml > nginx-pod.yaml`
// adicione a seção livenessProbe e preparação e crie
`kubectl create -f nginx-pod.yaml`
// verify
`kubectl describe pod nginx | grep -i readiness`
`kubectl describe pod nginx | grep -i liveness`
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: nginx name: nginx spec: containers:
- image: nginx
name: nginx
ports:
- containerPort: 80 livenessProbe: httpGet: path: /healthz port: 80 readinessProbe: httpGet: path: / port: 80 resources: {} dnsPolicy: ClusterFirst restartPolicy: Never status: {}
135. Verifique quais são as opções que podemos configurar com as readiness and liveness probes
`kubectl explain Pod.spec.containers.livenessProbe`
`kubectl explain Pod.spec.containers.readinessProbe`
136. Crie o pod nginx com as sondagens de atividade e prontidão acima para que ele espere 20 segundos antes de verificar as sondagens
de atividade e prontidão e verifique a cada 25 segundos.
`kubectl create -f nginx-pod.yaml`
137. Crie um pod busybox com este comando “echo I am from busybox pod; dormir 3600;” e verifique os logs.
`kubectl run busybox --image=busybox --restart=Never -- /bin/sh -c "echo I am from busybox pod; sleep 3600;"`
`kubectl logs busybox`
138. copie os logs do pod acima para o arquivo busybox-logs.txt e verifique
`kubectl logs busybox > busybox-logs.txt`
`cat busybox-logs.txt`
139. Liste todos os eventos ordenados por timestamp e coloque-os em file.log e verifique
`kubectl get events --sort-by=.metadata.creationTimestamp`
// colocando-os em file.log
`kubectl get events --sort-by=.metadata.creationTimestamp > file.log`
cat arquivo.log
140. Crie um pod com uma imagem alpine que execute este comando ”enquanto true; do echo 'Oi, eu sou de alpino'; dormir 5; done” e verifique e siga os logs do pod.
// cria o pod
`kubectl run hello --image=alpine --restart=Never -- /bin/sh -c "enquanto true; faz eco 'Olá, eu sou da Alpine'; sleep 5;done"`
// verifica e segue os logs
kubectl logs --follow hello
141. Crie o pod com este kubectl create -f https://gist.githubusercontent.com/bbachi/212168375b39e36e2e2984c097167b00/raw/1fd63509c3ae3a3d3da844640fb4cca744543c1c/not-running.yml.
O pod não está no estado de execução. Depure-o.
// cria o pod
`kubectl create -f https://gist.githubusercontent.com/bbachi/212168375b39e36e2e2984c097167b00/raw/1fd63509c3ae3a3d3da844640fb4cca744543c1c/not-running.yml`
// obtém o pod
`kubectl get pod not-running`
`kubectl describe po not-running`
// claramente diz ImagePullBackOff algo errado com image
`kubectl edit pod not-running `// abrindo com editor
ou
`kubectl set image pod/not-running not-running=nginx` //sem abrir o editor
142. Este yaml a seguir cria 4 namespaces e 4 pods. Um dos pods em um dos namespaces não está no estado de execução. Depure e corrija.
https://gist.githubusercontent.com/bbachi/1f001f10337234d46806929d12245397/raw/84b7295fb077f15de979fec5b3f7a13fc69c6d83
`kubectl create -f https://gist.githubusercontent.com/bbachi/1f001f10337234d46806929d12245397/raw/84b7295fb077f15de979fec5b3f7a13fc69c6d83`
// get all the pods in all namespaces
`kubectl get po --all-namespaces`
// find out which pod is not running
`kubectl get po -n namespace2`
// update the image
`kubectl set image pod/pod2 pod2=nginx -n namespace2`
// verify again
`kubectl get po -n namespace2`
143. Obtenha a memória e o uso da CPU de todos os pods e descubra os 3 principais pods que têm o maior uso e coloque-os no arquivo cpu-usage.txt
// get the top 3 hungry pods
`kubectl top pod --all-namespaces | sort --reverse --key 3 --numeric | head -3`
// putting into file
`kubectl top pod --all-namespaces | sort --reverse --key 3 --numeric | head -3 > cpu-usage.txt`
// verify
`cat cpu-usage.txt`
Serviços e Redes (13%)
Pratique perguntas com base nesses conceitos
Entenda os serviços
Demonstrar uma compreensão básica de NetworkPolicies
144. Crie um pod nginx com um arquivo yaml com o rótulo my-nginx e exponha a porta 80
**kubectl run nginx --image=nginx --restart=Never --port=80 --dry-run -o yaml > nginx.yaml**
// edit the label app: my-nginx and create the pod
**kubectl create -f nginx.yaml**
apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: app: my-nginx name: nginx spec: containers:
- image: nginx
name: nginx
ports:
- containerPort: 80 resources: {} dnsPolicy: ClusterFirst restartPolicy: Never status: {}
145. Crie o serviço para este pod nginx com o aplicativo seletor de pod: my-nginx
// cria o serviço abaixo
**kubectl create -f nginx-svc.yaml**
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-nginx ports: - protocol: TCP port: 80 targetPort: 9376
nginx-svc.yaml
146. Descubra o rótulo do pod e verifique se o serviço tem o mesmo rótulo
// obtém o pod com rótulos
`kubectl get po nginx --show-labels`
// obtém o serviço e verifica a coluna seletora
`kubectl get svc my-service -o wide`
147. Exclua o serviço e crie o serviço com o comando kubectl expor e verifique o rótulo
// exclui o serviço
`kubectl delete svc my-service`
// cria o serviço novamente
`kubectl expor po nginx --port=80 --target-port=9376`
// verifica o rótulo
`kubectl get svc -l app=my-nginx`
148. Exclua o serviço e crie o serviço novamente com o tipo NodePort
// exclui o serviço
`kubectl delete svc nginx`
// cria o serviço com o comando
`kubectl expose po nginx --port=80 --type=NodePort`
149. Crie o pod temporário do busybox e acesse o serviço. Verifique se o serviço deve retornar a página nginx index.html.
// obtém o clusterIP deste comando
`kubectl get svc nginx -o wide`
// cria busybox temporário para verificar o nodeport
`kubectl run busybox --image=busybox --restart=Never -it --rm -- wget -o- <Cluster IP>:80`
150. Crie uma NetworkPolicy que negue todo o tráfego de entrada
apiVersion: networking.k8s.io/v1 Kind: NetworkPolicy metadata: name: default-deny spec: podSelector: {} policyTypes:
- Ingress
151. colocar node em "manutenção".
oc adm drain node-1 --ignore-daemonsets --delete-local-data --force --grace-period=0
# Alias
alias k='kubectl'
alias kc='k config view --minify | grep name'
alias kdp='kubectl describe pod'
alias krh='kubectl run --help | more'
alias ugh='kubectl get --help | more'
alias c='clear'
alias kd='kubectl describe pod'
alias ke='kubectl explain'
alias kf='kubectl create -f'
alias kg='kubectl get pods --show-labels'
alias kr='kubectl replace -f'
alias kh='kubectl --help | more'
alias krh='kubectl run --help | more'
alias ks='kubectl get namespaces'
alias l='ls -lrt'
alias ll='vi ls -rt | tail -1'
alias kga='k get pod --all-namespaces'
alias kgaa='kubectl get all --show-labels'
_________________________________________________________________________________________________
Via UI
Profile > Security > Security-domain > add
Nome "simple" - cacheType=default
> View > Authentication > add >
Code = Database
Flag = Required
> ModuleOptions > Add
nome = dsJndiName (procurar na doc)
value = java:jboss/DS_XA
> ModuleOptions > Add
nome = princialsQuery (procurar na doc)
value = select Password from JBTravel.USER where username=?
> ModuleOptions > Add
nome = RolesQuery (procurar na doc)
value = select null, ‘Roles’ from JBTRAVEL.USER where username=?
- Fazer deploy da aplicação