be careful of x:
mcp devmessages json (like msg history)isso é um dump do que eu aprendi e anotei estudando kubernetes pra CKA.
essas anotações foram feitas pra mim, então se não entendeu algo se vira (ou me pergunta github@mtonio.com).
hoje em dia tudo da pra copiar e colar pra uma LLM, então o importante é manter palavras-chave, explicações de conceitos e edge cases, os especificos
k get all -A
lembra de usar a API reference ao invés de ficar perdido na documentação deles https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
k get pods –selector env=dev
k run podname –image=x –labels=”a=foo,b=bar”
k run podname –image=x –dry-run=client -o=yaml
use k get pod x -o=yaml > pod.yaml pra recriar o pod
k get pods -o=wide (pode ver em que node os pods estão)
você pode especificar Requests minimos e Limits máximos para os cpu e memória de um pod
quando você coloca –expose –port 80, ele cria um service clusterIp pra você junto com o pod
CrashLoopBackOff num pod pode ser varias coisas, se você der k get pod, dentro do yaml tem a razão pela qual ele deu erro
k logs podname –container=x pra ver os logs do pod
quando um pod é filho de um controller dá pra ver em k describe pod podname | grep ControlledBy:
volumes hostPath montam a pasta do pod diretamente no host, é muito usado em static pods
imagePullSecrets dentro da spec do pod pra usar um registry do docker privado
k delete pod –force pra não ter que ficar esperando
lembra de olhar os configmaps dos pods (que são montados como volumes), as vezes uma config importante está num configmap do pod e vc não sabe
sidecar containers são tipos especificos de init containers que tem restartPolicy: Always
se um init container tem restartPolicy: Always, ele só morre quando o container principal morrer tambem
Init Containers são usados na spec de pods pra criar um container itermediario pra fazer algum build ou setup antes do container principal, da pra dividir um volume entre os dois containers com volumeMounts pra eles terem acesso aos mesmos arquivos
init containers rodam um depois do outro, não simultaneamente
pra ver pq o init container falhou, usa k logs podname -c init-container-name
pods tambem podem rodar no node controlplane
você pode forçar um node manualmente num pod com k edit -> nodeName (manual scheduling)
k get nodes -o wide para pegar os ips dos nós
ssh node-ip para dar ssh num nó
k top pods/nodes (precisa do metrics server rodando)
kubectl drain node01 –ignore-daemonsets (adiciona taint de unschedulable pra fazer manutencao e mata todos os pods dentro)
drain não funciona pra dar evict em pods sem controler, pq ele deletaria algo pra sempre
kubectl uncordon node01 (deixa o node schedulable de novo)
use o comando ip a pra ver todas as network interfaces
a interface com (172.0.0.0/16) é a dos containeres
(kube-controller-manager.yaml dentro dos manifests é onde você encontra o range de ips dos pods)
ip route show default mostra o gateway padrão do nó (ip do roteador)
containeres tem um ip do roteador virtual que não precisa estar na mesma subnet da rede, se o nó for um container tipo minikube já sabe
deployments são controllers feitos só pra pods e replicasets
depois de uma mudança, você tem que dar scale=0 ou deletar os pods manualmente pro controller recriar
k create deploy –image=x –replicas=3
k scale –replicas=5 rs/new-replica-set
selector labels e template labels no spec de um controller é como o controller sabe de quais pods ele é dono
deployments do tipo RollingUpdate trocam pods um por um sem precisarem ser deletados
dns dos serviços tbm funciona se quebrado em partes (tanto service-name quanto service-name.default.svc.cluster.local) funcionam
o service tipo clusterIP é virtual, expõe uma porta acessado só internamente por outros pods
o service tipo nodeport expõe uma porta alta em todos nodes, a nodePort, mas ele tambem expõe uma porta interna port e leva em sua config a targetPort, do pod
da pra usar pod: nameselector pra escolher quais pods o service vai servir de proxy
static pod é um pod sem controller definido por padrão em em /etc/kubernetes/manifests/ ()
daemonset é um controller que roda um pod pra cada nó do cluster, e é muito comum em ferramentas de logging, monitoramento e networking
kube-proxy é um daemonset que implementa os services, ele tbm lida com firewalls de services
coredns roda no kube-system e é o que resolve os dns tipo .svc.cluster.local
o coredns é definidos nos pods como um servidor dns mesmo, na porta 53 e tudo mais
se você fizer ps aux | grep kubelet você consegue ver onde ficam os arquivos de configuração do kubelet, incluindo o –config que é o mais importante
é possivel deployar mais de um scheduler no kubernetes, e as vezes pra setups de infraestrutura muito customizados, ou que sofrem trafego de criacao/destruicao de pods muito alto é o que eles fazem
da pra usar o help dos binarios dos containeres que você não faz ideia do que fazem, tipo k exec -it kube-apiserver-controlplane -n kube-system – kube-apiserver –help
crictl ps -a (é tipo docker ps -a mas para os containeres que implementam o kubernetes)
crictl logs container-id
etcd node roda como pod mas você pode usar etcdctl no controlplane pra usar ele
etcd guarda todas as resource definitions e metadata de pods rodando
etc é um static pod em /etc/kubernetes/manifests/etcd.yaml, tipo o kube-apiserver
pra fazer um backup do etcd:
etcdctl snapshot save --endpoints --cacert --cert --key /opt/snapshot-pre-boot.db
etcdctl snapshot restore /opt/snapshot-pre-boot.db data-dir/
rm -rf /var/lib/etcd/ && mv data-dir /var/lib/etcd
o port do etcd 2379 é pra comunicação controlplane -> node
o port etcd 2380 é pra comunicação controlplane <-> controlplane (peer to peer)
se for application failure: olhe a config do service e do pod
se for failure no controlplane: olha os pods do kube-system e o /etc/kubernetes/manifests
se for failure no worker node: olha o systemctl status kubelet, a /var/lib/kubelet/config.yaml, e o /etc/kubernetes/kubelet.conf (acho que essas coisas estão no comando de instalação do kubelet ou no service)
se for network failure: olha se o CNI tá instalado, olha os pods do CNI (eles ficam em outros namespaces normalmente)
persistent volumes são como definições de espaço a ser usado em disco, tipo definições de uma pasta
da pra cirar um persistentvolume de tipo hostPath, que monta direto numa pasta do host
volumes com tipo readwritemany podem ser montados em varios nodes, readwriteonce só em um
se vc usar a config do pv retain ele fica unavailable depois de usado pra evitar que ele autodelete quando outro pod quiser usar ele
persistent volume claims são “escrituras/reservas” de persistent volume
pvc é como os pods usam o storage do pv, você referencia a pvc no spec
enquanto o pvc tiver criado, os dados vão continuar lá, reservados
1 pvc = 1 pv, sempre são de um pra um, nunca da pra fazer varios pvcs pra 1 pv, são monogamicos
PVCs com storageclass especificada não precisam de nenhum PV pré-criado, criam automaticamente
storageclassname é especificado na spec do pvc
kubectl describe pvc pvcname
taints afastam pods que não tenha toleration
tolerations toleram pods com taints especificas
taints normalmente são um key-value pair
k taint nodes node1 afasta=tudo:NoSchedule
node affinity é uma config do pod pra preferir/requisitar nodes com certas labels
k label node node01 gpu=True
o node affinity é editado no spec do deployment ou do pode
node affinity pode ser required ou preferred, with conditions key has value x or key exists
k get priorityclasses
k create priorityclass low-priority –value=1000 –description=”bla” –global-default=false
priorityclasses são classes que fazerm um pod ter prioridade sobre outros pods
priorityClassName pode ser especificado no spec de pods
a priorityclass do tipo PreemptLowerPriority dá evict em outros pods, a Never não
configmap é tipo um secret só que sem criptografia
dá pra usar os valores do configmap em environment variables
o único outro jeito de usar é em volumes (ai cada par key-value vira um arquivo no volume)
tem muitas vezes onde secrets são do tipo TLS, onde tem arquivos .crt, .key and .ca
tem secret do tipo docker-registry tambem, pra registries privados do docker
HPA precisa de requests / limits especificados no pod, pq ele calcula o threshold pra criar uma nova replica baseado nesses requests
VPA é um custom resource definition que vc precisa instalar, ele deleta o pod e cria de novo com mais memoria/cpu
o VPA usa machine learning pra dar update em limites de CPU e memoria
o VPA da erro quando tem só uma replica do que você tá autoscaling, pq o serviço ficaria indisponivel na recriação
o jeito mais comum sem um provider externo de criar um user no kubernetes é criado um certificado e uma clusterrole
certificado tls é composto por .crt, .key and .ca
.ca pode ser compartilhado as vezes, as vezes não, pq certificados TLS conseguem fazer uma chain de pai CAzão pra filho CAzinho pra filho CAzito
quando tu usa o comando do openssl x509, vem varios campos
nesses campos Subject CN: dentro do .crt é o CommonName, mostra o que ele representa, tipo o username dele
o campo Issuer CN mostra o pai dele, o CAzão
o Subject Alternative Name: tem todos os DNSs onde o certificado é usado
certificatesigningrequest é um recurso que é usado pra pedir aprovação de certificados TLS pra usuários da API
k get csr
k certificate approve fulano
a diferença de roles e clusterroles é que as clusterroles não se restringem por namespace
uma rolebinding binda uma role com permissões em um ou vários subjects, mas ela não consegue usar mais de uma role ao mesmo tempo não
dar acesso pra alguem é: criar role com permissão x + criar rolebinding dessa role no user
nas roles, os “apigroups” na spec são o que fica em cima da spec de todos recursos (o api:)
nas roles, resourceNames é tipo prefixo da role do IAM da aws, e.g.: quero permissão x pra todos pods com prefixo bonito-*
cluster roles são pra coisas tipo permissões de usuário ou pra dar permissão pra recursos sem namespace como nodes ou storageclasses
admission controllers podem ter o tipo mutating ou validating,
admission controllers são hookzinhos validadores de template que rodam depois que tu dá o comando de criar o recurso, mas antes dele serem efetivamente criados
exemplos de admission controller validating NamespaceExists (quando tu cria e ele da erro, valida se ja existe)
exemplos de admission controlller mutating NamespaceAutoProvision (quando tu da k create namespace e ele nao da erro)
tem recursos builtin pra fazer admission controllers customizados com webhooks
serviceaccounts são usados no campo serviceAccountName: dos pods pra dar direitos de kubectl pra eles
k create serviceaccount saname
k create token saname
é o firewall do kubernetes basicamente, tem ingress egress allow deny
o deny é meio que por padrao, se vc criar uma netpol e não botar nenhuma regra é tipo um deny all
k get netpol
da pra usar pod: nameselector na network policy e filtrar por pods
essa porra é mto complexa então usa essas receitas aqui https://github.com/ahmetb/kubernetes-network-policy-recipes
container network interface é quem decide como os ips entre os pods vão funcionar
eles são como se fossem plugins e você escolhe qual vai usar
flannel nao tem suporte pra networkpolicy
calico tem suporte pra networkpolicy
plugins cni são instalados em /etc/cni/net.d/
aliás, paths com unix:// paths são sockets unix (que são diferentes de sockets de rede)
um ingress no k8s é tipo um nginx, ele faz port forwarding usando http e regras de dns
vc tem que instalar um ingress especifico pra usar, no meu caso foi o nginx-ingress
o ingress associa um subdomínio tal com um service x e manda toda requisição q vc faz no subdominio pro service, você até associa um service default em caso de 404 no deployment do ingress
no ingress resourceannotation no metadata costuma importar, pelo menos no nginx-ingress entao toma cuidado
gateway é tipo um ingress só que tunado e muito mais complexo
no gateway as gateway routes definem quais namespaces podem usar o gateway,
a gatewayclass define um tipo de gateway, e tem o gateway que é a implementacao do gateway per se
no gateway tem o httproute que é um resource dedicado só pra uma rota subdominio -> service
add repo to apt repositories
apt install kubeadm='1.33.0-*' kubelet='1.33.0-*' kubectl='1.33.0-*'
no controlplane você dá kubeadm init
no worker você dá kubeadm join
depois você instala uma CNI, tipo o flannel
em cada upgrade de 1.32 -> 1.33 você tem que mudar o repositorio do APT, pra fazer upgrade do kubeadm kubectl e kubelet
em cada node:
apt install kubeadm='1.33.0-*' kubelet='1.33.0-*' kubectl='1.33.0-*'
kubeadm upgrade plan
kubeadm upgrade apply v1.33.0
kubeadm upgrade node
systemctl daemon-reload
systemctl restart kubelet
k config use-context research
a environment variable KUBECONFIG pode ser usada pra especificar o diretorio da kubeconfig tbm
k get pods –as my-context pra usar outro contexto programaticamente
custom resource definitions sao bem faceis de entender
vc define um plural e um grupo (que é o que fica na api version la em cima)
comandos de repos
helm search hub
helm repo add
helm install releasename repo/chart
helm upgrade releasename repo/chart –version 2.0.0
helm get manifest releasename
helm rollback releasename
touch ./kustomization.yaml && k apply -k .
o nome é kustomize pq vc pode pegar yamls prontos e dar override em valores deles num lugar central com mta facilidade, usando vários kustomize.yaml, um em cada folder
kustomize tem configs como dar overwrite em tudo com uma commonLabel, commonAnnotation, commonNamespace, e prefixos de nomes em comum tambem
no kustomize você exclui/inclui recursos separando eles em diretorios e referenciando eles no kustomize.yaml
kustomize tem os tipos de patch. change patch, $patch: delete e JSON 6902 patch
change patch exemplo: images: name: newName: pra trocar o nome da img, newTag pra trocar a tag
$patch: delete consegue deletar containeres de um pod
patch JSON 6902 permite trocar qualquer config de qualquer recurso
k patch é um comando default do kubernetes que edita recursos com um json
kustomize tem o conceito de bases e overlays
bases você importa
overlays são como dev/prod/staging, e tem patches e components
]]>
During the holidays my grandma showed me this old book of recipes.
It’s in portuguese and really worn out with oil stains (I suppose from using it while cooking).
Some of the recipes have interesting names, like Torta Besta (“Dumb Pie”), Beringelas “Tchan” (“Zing!” Eggplants), and Bolo D’água (Water Cake).
It also showed me how important and personal writing can be for people, and made me want to preserve it, so I decided to save it here.
]]>imagem por @alariko
Existe uma regra prática no mercado imobiliário: o aluguel de um imóvel geralmente corresponde a 0,3% do seu valor total, podendo chegar a 0,5% em áreas mais valorizadas. Vamos usar essa informação como base para a análise.
Imagine um apartamento com aluguel de R$ 5.000. Usando a regra do 0,5%, podemos calcular que seu valor seria aproximadamente R$ 1 milhão.
Muitos consultores sugerem que você pode comprar um imóvel se conseguir pagar um financiamento equivalente ao valor do aluguel. Mas vamos fazer as contas:
Isso me parece problemático, porque:
E esse número de parcelas está diretamente relacionado à porcentagem do aluguel (0,5%):
Dado isso, não faz tanto sentido assim alugar um imovel se você busca um “upgrade” em qualidade de vida (o que corresponderia a um aluguel maior que o atual).
A compra de um imóvel só realmente faz sentido financeiramente em algumas situações específicas:
Quando o aluguel representa uma parcela muito pequena da sua renda mensal, ou seja, apartamentos muito baratos ou pessoas muito ricas buscando renda passiva. Ou em operações de especulação imobiliária.
Logo a gente percebe que comprar um imóvel em grandes centros urbanos é só pra quem realmente tem muito dinheiro. O “sonho” da casa própria financiada é uma sacada emocional pra te vender uma furada.
Agora, cidades do interior e propriedades rurais já merecem outra análise, e, provavelmente fazem dão um melhor negócio.
]]>Eu sou adepto do cumbuquismo. Todos os dias eu reservo uma hora (12h-13h) pra cozinhar, lavar louça e comer. Como eu cozinho pra semana toda, nem sempre leva uma hora inteira.
Se eu vejo que não tem arroz, eu faço arroz pra semana toda. Se eu quero comer frango, eu frito 1kg de frango de uma vez. Então em algumas vezes levo 40 minutos pra fazer o almoço, as vezes 5, e vai conforme a necessidade. Se falta uma proteína, faço um ovo cozido por 8 minutos, se faltam legumes, faço couve crocante na air fryer por 5 minutos.
O cumbuquismo não é purista, eu por exemplo, comecei comendo marmita congelada. Com o tempo cheguei a dividir, metade da marmita congelada pro almoço e metade pra janta, e o resto da comida vou incrementando com o que cozinho. Muitas vezes, tem tantos “incrementos” que eu nem preciso da marmita congelada, e como só o que cozinhei.
Isso aqui é bem sério.
Me acompanha por um segundo pra entender o raciocínio.
Olha para o mundo a sua volta, ele é absolutamente dominado de pratismo. Tudo é servido em pratos rasos e gigantes, tudo leva um tempo absurdo pra cozinhar. Fazer feijão todos os dias, fazer arroz todos os dias, uma tonelada de panelas. Mães e avós passando o dia cozinhando e lavando louça. Restaurante PF, restaurante à quilo. Talvez o costume seja tão grande de almoçar em grupo que tenhamos perdido nossa individualidade.
Com essa perda, vieram instituições pratistas aceitáveis, como o Self-Service e o PF. Quando a gente menos percebeu, essas instituições pratistas puxaram o nosso tapete. A gente caiu no IFood, Griletto, Parmê, China in Box. Que são instituições demoníacas, é só você olhar a proporção de arroz pra proteína que eles colocam na comida.
Uma cadeia produtiva que era custo operacional -> consumidor, virou custo operacional -> franquiado -> aplicativo -> entregador -> consumidor.
Como essa cadeia produtiva é absolutamente insustentavel, o preço pago vai ser na comida.
O tapete vai ser puxado novamente e vamos cair nos burritos e hambúrgueres.
A alimentação precisa de um retorno ao essencial, achar a individualidade e cortar essa cadeia produtiva. Aqui está uma filosofia minimalista e anti-pratista, pros tempos de hoje.
Princípios Cumbuquistas:
Why we leave stuff for later, and how we build habits.
image by @deuveir
DISCLAIMER: I wrote this when I was 17, a lot has changed on my opinions since. For the sake of record-keeping, I have uploaded it here on my blog. Enjoy the read.
In my inevitable drive to criticize the actions of my social peers and family, I have noticed a pattern in their behaviour, a tendency to minimize pain and effort in exchange for comfort. It is present in everyone of my social circle, some of those in a disproportionate scale, diminishing their quality of life in return for some lazy slumber. Like a person who rarely dusts their house for the sake of laziness, and starts having severe allergies because of it.
Of course that, by the lack of thinking, they are somewhat blinded to the consequences of it, and start irrationally taking every opportunity to put aside their duties. This is equivalent to seeing preferential actions — those the consequences of not doing it are worse than the burden of doing it — as something bad and avoidable, instead of something beneficial like it really is — therefore the irrational characteristic of it.
So, if this tendency for slacking off creeps into our behavior, and is such a virus that keeps us from doing stuff, how can we learn to accept the effort instead of avoiding it, and start doing it constantly?
Well, it turns out you can’t do that.
Effort is, by the definition of the word, something that can only be done once in a while, something “out of the ordinary”. If you take effort every single time while doing things, it stops looking like effort to you, and it becomes ordinary routine. Like a runner that runs at his highest capacity every day, he in fact isn’t putting in any effort. What happened is that, by the sole factor of doing it every day, it has become -or rather is- a habit to him.
This mistakable correlation of “becoming” to “being” is what really throws us into confusion. Because, if he were just a sedentary guy — if he decided to waste all his energy in trying to run every day- it is highly improbable that he would keep doing it, and be where he is today. It didn’t “become” a habit for him, rather it “is” a habit for him.
But then how did he actually become this good at it? Well, the role of effort in building habits is approachable in many, widely different, ways of thinking, some of those being evolutionary biology, the economy of the human action, beyond many others. Not to speak of the watered down, condensed versions of these knowledge presented in self help books, that actually make a lot of money doing it.
I could take a very long time explaining each one of these concepts in detail, but, supposing that someone else is going to read it, I think it’s always less disastrous for people to find out their own way of doing things, instead of applying my not-at-all-wise words.
Nevertheless, I recommend you browse the list below and actually take a run at some of these books, with some skepticism towards the self help cliches. And please remember that, ultimately, success and failure at doing something are concepts that depend on your own interpretation of your action. The only thing truly objective at play is an attempt at doing something, an action being made, and without it, you can’t either succeed or fail.
]]>Human Action — Ludwig von Mises
Praxeology: Who Needs It — Roderick T. Long
The Power of Habit — Charles Duhigg
Behave: The Biology of Humans at Our Best and Worst — Robert Sapowski
How to Fail at Almost Everything and Still Win Big — Scott Adams