<laury.dev/>

#Snippets

Topics
>
server-side (27)
>
docker (14)
>
kubernetes (14)
>
development (8)
>
homelab (8)
>
raspberry-pi (4)
>
golang (3)
>
survival-guide (3)
>
macos (2)
>
mariadb (2)
>
mongodb (2)
>
postgresql (2)
October 08, 2024

#How to survive the Infrastructure and Operations world: from servers to Kubernetes

kubernetessurvival-guide

If you’re here, most likely, you’re trying to get into the infrastructure world. First, I’m so sorry. Second, the links here are my tried and true resources to navigate the fundamentals in this jungle. Hopefully, they’ll make a difference for you too.

How to host stuff: the easy way

Go for a Platform As A Service (PaaS). These cost more, but your time is also valuable:

How to host stuff: the hard way

Grab a generic server, SSH into it, and install whatever you need. It can be an AWS EC2 or, if you’re a cheapskate like me, you can live on the edge and use Oracle’s free servers.

Cools tools you can use to help:

  • portainer: cool and convenient web UI to manage Docker containers
  • watchtower: to update your Docker containers
  • FluxCD: to set up your own CD pipeline

How to survive AWS

AWS In Plain English is a great start.

To get a feeling for cloud architecture in the real world, take a peek at this playlist with quick videos of organizations showing the problems they had and how they fixed them (it’s a bit of an advertisement of AWS products, but still super valuable):

How to GitOps

As an introduction to the topic, refer to the video What is GitOps, How GitOps works and Why it’s so useful.

When it comes to implementation, these strategies are powerful starting points:

How to deal with networks and firewalls

No easy ways out here. On AWS, you’ll have to face the dreaded Security Groups. On Oracle Cloud, this tutorial should help.

And remember the classic port numbers:

  • SSH uses port 22
  • HTTP uses port 80
  • HTTPS uses port 443

How to deal with DNS

To make sure you got the basics covered, read these:

Now, get your hands dirty by creating live hosted zones with these tools:

How to think about Docker

Containers are a deeply misunderstood piece of technology. But you don’t need to know much to get value from them. Start here:

When you feel ready, go deeper:

How to survive Kubernetes

Don’t underestimate the official Kubernetes tutorials. They’re great.

Knowing what it does under the hood is a great way to feel comfortable with a tool. That’s why this half-hour presentation can leave a strong impression.

And, as Master Yoda once said, “The greatest teacher failure is”. With this spirit, peek at a fantastic read.

For debugging applications in Kubernetes, these resources can also be very powerful:

  • WhoAmI: a tiny server that returns OS information and HTTP request headers
  • Podinfo: similar to WhoAmI, but more feature rich
  • Telepresence: a powerful tool for debugging Kubernetes-native applications; (also check out these troubleshooting tips)

Section break
March 29, 2024

#Quick, dirty and effective commands for hacking your way into Kubernetes

kubernetessurvival-guide

Sometimes, we want to avoid going through the trouble of creating YAML files for resources, checking its syntax, and versioning everything. Sometimes, we only want something up and running for a POC, a quick test, or a debugging session. For those moments, these commands can help.

Spin up debug pods:

# Debug application for testing k8s features
## See docs here: https://github.com/stefanprodan/podinfo
kubectl create deployment podinfo --image=stefanprodan/podinfo

Create Services for applications:

# Basic Service (ClusterIP)
## Service will expose 'port' / target application listens on 'target-port'
kubectl expose deployment podinfo --port=80 --target-port=9898 --name=podinfo-service

# Port forward a cluster application to your local machine (access http://localhost:8080)
kubectl -n default port-forward service/podinfo-service 8080:80

# Expose the raw Kubernetes API Server on your local machine
kubectl proxy

Create and expose a Postgres database:

kubectl create deployment postgres --replicas=0 --image=postgres:16.0
kubectl set env deployment/postgres POSTGRES_PASSWORD=pass POSTGRES_USER=user
kubectl scale --replicas=1 deployment/postgres
kubectl expose deployment/postgres --port=5432 --target-port=5432

Run commands in containers:

# Latest Ubuntu container that spins up and gives you a shell 
# Container is deleted when you close the connection
kubectl run ubuntu --rm -it --image=ubuntu -- bash

# Similar to the previous one, but keeps the debug container active
kubectl create deployment ubuntu --image=ubuntu -- sleep infinity
kubectl exec -it deploy/ubuntu -- bash
kubectl delete deploy/ubuntu

Get a bird’s eye view of your cluster state:

# See all running pods on your cluster (regardless of namespace)
kubectl get pods -A

# Increase verbosity level of kubectl's output (works with all its operations)
kubectl -v=8 get pods -A

# Combine the previous command with "watch" to get an evergreen view
watch kubectl get pods -A

# List all container images running
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

# Read CPU and RAM consumption of your nodes (requires metrics-server)
kubectl top nodes

# Read CPU and RAM consumption of all your pods (requires metrics-server) 
kubectl top pods -A

# Get cluster cluster state including logs from control plane applications
kubectl cluster-info dump

Copy folders to and from running pods (requires tar on both local and remote environments):

tar cf - /local-source | kubectl exec -i my-pod -- tar xf - -C /remote-destination
kubectl exec my-pod -- tar cf - /remote-source | tar xf - -C /local-destination

Force all Pods of a Deployment to be recreated:

kubectl rollout restart deployment <deployment_name>

Remove finalizers from an existing object (make sure you really know what you’re doing, though):

kubectl patch <object_name> -p '{"metadata":{"finalizers":[]}}' --type=merge

Grab logs from a pod managed by a specific deployment:

kubectl logs deploy/my-app > my-app-`date '+%Y_%m_%d__%H_%M_%S'`.log

List permission-related information for your current user:

kubectl auth whoami
kubectl auth can-i --list

Some useful Helm commands to manage chart configurations:

# See all configurable options with detailed comments (equivalent to reading the values.yml)
# Example with the Coroot Helm Chart
helm show values coroot/coroot

# See all provided versions of a Helm Chart
helm search repo coroot/coroot --versions

# Get the values used when installing a Helm release
helm get values argocd -n argocd > argocd-values.yaml
helm upgrade argocd argo/argo-cd --version 5.9.1 --namespace argocd -f argocd-values.yaml

# Upgrade an existing Helm release in-place while keeping values provided during installation
helm upgrade argocd argo/argo-cd --reuse-values --force --version 5.9.1 --namespace argocd

# List all available revisions of a given release
helm -n nginx history ingress-nginx

# Get user-supplied values of a specific revision
helm -n nginx get values ingress-nginx --revision 3

# Rollback the release to a specific revision
helm -n nginx rollback ingress-nginx 3

In order to debug your own Helm Charts, you can leverage:

helm template --debug <release_name> <chart_path> -f <values_file_path>

helm install --generate-name --dry-run --debug <chart_path>

Notable domain names available in-cluster:

https://kubernetes.default (Kubernetes API Server)
http://<service_name> (reaches a service in the same namespace as the client)
http://<service_name>.<namespace>
http://<service_name>.<namespace>.svc.cluster.local

References

Official kubectl Quick Reference

Section break
July 02, 2022

#Basic survival guide and commands for iptables

server-sidesurvival-guide

iptables is a Linux firewall tool that manages packet routing and can block or allow traffic based on rules like a packet’s origin or destination.

Its settings are organized in tables which contain sets of rules, called chains, that will filter data packets.

# Lists existing rules with the "specification" syntax
iptables -S

# Delete a rule by its specification string
iptables -D <spec>

# List existing rules by chain and alongside packet matching statistics
iptables -L -v --line-numbers

# Delete a rule by its row index
iptables -D <chain> <num>

# Reset the packet counters on all chains
iptables -Z

# Accept all requests from an IP
iptables -I INPUT -s <ip> -j ACCEPT

# Drop all requests from an IP
iptables -I INPUT -s <ip> -j DROP

# Accept all incoming TCP traffic to a given port
iptables -I INPUT -m state --state NEW -p tcp --dport <port> -j ACCEPT

# Drop all requests from a range of IPs
iptables -I INPUT -m iprange --src-range <ip_range_start>-<ip_range_end> -j DROP

# Drop all traffic (must be run after acceptance rules; `-A` stands for "append")
iptables -A INPUT -j DROP

# Delete all current rules
iptables -F

# Restore iptables rules from last persisted version
iptables-restore < /etc/iptables/rules.v4

# Persist changes to disk
/sbin/iptables-save
# Depending on your setup, you may need to run another command instead
netfilter-persistent save

References

How the Iptables Firewall Works

How To List and Delete Iptables Firewall Rules