Posts tagged: containers

All posts with the tag "containers"

85 posts latest post 2026-03-23
Publishing rhythm
Mar 2026 | 2 posts
![[none]] --- apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: kanboard namespace: argocd spec: project: default destination: namespace: kanboard server: 'https://kubernetes.default.svc' source: path: kanboard repoURL: 'https://github.com/waylonwalker/homelab-argo' targetRevision: HEAD syncPolicy: automated: prune: true
Manual Upgrades | K3s You can upgrade K3s by using the installation script, or by manually installing the binary of the desired version. docs.k3s.io [1] You can give k3s an install channel to install stable, latest, or specific versions like 1.26. This is handy to make sure that you install the same version on all of your workers. curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=latest <EXISTING_K3S_ENV> sh -s - <EXISTING_K3S_ARGS> References: [1]: https://docs.k3s.io/upgrades/manual

For my reader app I am using cronjobs to schedule my a new build and upload to cloudflare pages every hour. In this example I have built a docker image docker.io/waylonwalker/reader-waylonwalker-com and pushed it to dockerhub. It uses a CLOUDFLARE_API_TOKEN secret to access cloudflare, and the entrypoint itself does the build and upload.

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: reader
  namespace: reader

---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: reader-cronjob
  namespace: reader
spec:
  schedule: "0 * * * *"
  successfulJobsHistoryLimit: 6
  failedJobsHistoryLimit: 6
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: reader-container
              image: docker.io/waylonwalker/reader-waylonwalker-com:latest
              env:
                - name: CLOUDFLARE_API_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: cloudflare-secret
                      key: cloudflare-secret
          restartPolicy: OnFailure
External Link sealed-secrets.netlify.app [1] kubeseal is a pretty simple to get started with way to manage secrets such that they can be stored in a git [2] repo and be picked up by your continuous delivery service. Sealed Secrets provides declarative Kubernetes Secret Management in a secure way. Since the Sealed Secrets are encrypted, they can be safely stored in a code repository. This enables an easy to implement GitOps flow that is very popular among the OSS community. References: [1]: https://sealed-secrets.netlify.app/ [2]: /glossary/git/

In my homelab kubernetes cluster I am using kubeseal to encrypt secrets. I have been using it successfully for a few months now wtih great success. It allows me to commit all of my secrets manifests to git with out risk of leaking secrets.

You see kubeseal encrypts your secrets with a private key only stored in your cluster, so only the cluster itself can decrypt them using the kubeseal controller.

kubeseal-post.png

KubeSeal #

https://sealed-secrets.netlify.app/

screenshot of https://sealed-secrets.netlify.app/

installation #

Installation happens in two steps. You need the kubernetes controller and the client side cli to create a sealed secret.

For a more complete instruction see the [docs#installation](https://github.com/bitnami-labs/sealed-secrets?tab=readme-ov-file#installation]

installation - controller #

Warning

 **context**

Make sure that you are in the right context before running any kubectl commands.

kubectl config current-context

sealed-secrets is installed using the helm package manager. To install sealed-secrets run the following command.

helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets -n kube-system --set-string fullnameOverride=sealed-secrets-controller sealed-secrets/sealed-secrets

installation - client #

For the client you can check your OS package manager, brew, or the github-releases. For me I found it in the main arch repos.

paru -S kubeseal
# or
sudo pacman -S kubeseal
# or
brew install kubeseal

Note

 You will need to install kubeseal on every device that you will want to

create sealed secrets on.

Example #

Most of these commands come straight from the docs. From my experience I have always specified the namespace, my projects go per namespace and I don’t have any reason that other namepsaces should see the secret, and if they do I deploy another secret in that namespace.

# Create a json/yaml-encoded Secret somehow:
# (note use of `--dry-run` - this is just a local file!)
echo -n bar | kubectl create secret generic mysecret --dry-run=client --from-file=foo=/dev/stdin -o yaml -n thenamespace > mysecret.yaml

note that the key of the secret is foo and the value is bar

results

apiVersion: v1
data:
  foo: YmFy
kind: Secret
metadata:
  creationTimestamp: null
  name: mysecret
  namespace: thenamespace

Note

 The data is base64 encoded.
echo -n bar | base64
# YmFy
# This is the important bit:
kubeseal -f mysecret.yaml -w mysealedsecret.yaml

# At this point mysealedsecret.json is safe to upload to Github,
# post on Twitter, etc.

# Eventually:
kubectl create -f mysealedsecret.yaml -n thenamespace
# sealedsecret.bitnami.com/mysecret created

# Profit!
kubectl get secret mysecret
kubectl get secret mysecret -n thenamespace
# NAME       TYPE     DATA   AGE
# mysecret   Opaque   1      27s

cat mysealedsecret.yaml | kubeseal --validate

echo -n bar | kubectl create secret generic mysecret --dry-run=client --from-file=foo=/dev/stdin -o yaml \
  | kubeseal -o yaml -n thenamespace > mysealedsecret.yaml
echo -n baz | kubectl create secret generic mysecret --dry-run=client --from-file=bar=/dev/stdin -o yaml \
  | kubeseal -o yaml -n thenamespace --merge-into mysealedsecret.yaml

Results

---
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: mysecret
  namespace: thenamespace
spec:
  encryptedData:
    bar: AgBLkamltcLfH1dC1JxQ3qd8lJ8aBZF2ARoq3uo055hnzXOy8g2T5liTx5UPvyPV8yyWqABU8eOnwjNhDtzSATvYeBB3fGkucdOZziWEoiNsWTR9ZtFEkod7Ya6uGkzZOJwi3IkrHFVIT9oWZQUxxJZ6vFhPiFcx9Dorr8TNSzG4KOug25+PhWPPiHDgSup5N3CkWCZaYOF7dbZRVSA4nGP1fZxjFByHP4AsdjLCHptyVbkpLRKeiXTkLxfLX4K+JLZGM41S1On5bSP56mCfv1daTJx619kDXkRLw9l21Ot283/L0NMNAiw781AefYMVoO3aHmYgcT6wAtsQAKje9fyL7DQRHt8a5NZOWukp/P6XjdXRz/nfQasQlbSTrRkDpplKIM5/WdPcBoKi+yyoOL0rZ8x1X7YzUI3BggZmzWyEPD01BK1YAHGZnYIZbbCy1JSm8JCBvP+xWMg+i0Z/DCD8nclAhH1GX2Q7/NrNHF//589AJfuriymd2+mk7uaLA4RRsY0l5QeZD6HVAqSv5jWsVQQtSftWmI9vn9oL/Pno7sEUjSDpXPfF4nnsULhxsPEe2DFAMm1kZAjdF06ueF4/x2Fdy80ZQNyycaDx2CWm4z3b14A75WGyOXl2wJZQqxrFCz8el4hD2nH3zQFEzd6AIh49myqVAGuu2qGlYP4p94LJghVa+mQjztLD/2ZUZjY+anQ=
    foo: AgAducXW6iUCY900cPDdmRfuj7tKnh2hY4C1+2hFoAtjyvjepsKNWsiPJ81t8anaMfFPat4ta060l5VtTrceFE8oS/rViz1tvNWGPBjL+GwL/QjkGl6H8ju87vKERKQn5qw7B/V5j24VM8AxOd+/vJNt/IeRIHLubvFft4hyMq4b0xmIxaemBSTxchQX/5364T3VJH2kHaqpqd+JJgQnTbiTQe/XnyZokDX8GSxw4rAbJUJSRUtY9DB9ZDu2zC5VngX+GJjbwHGbv9EKs8LShJIPrD8xHqrDmlSXGkkP01D4A6268Qoi3x5S0H5aqDgtrgBiWsNkzdKwjfrTNx7pKecOi41lyFdffHOGUew4aPPMqjzWR2TEms9WNNQXwnBdDHKMkFsisocF52BolEkcjF8g/u5h2Af92abMu6k16VybJrB7TV1set5A9W7rqG1iXI4+1W6XQfFnpja8xL/zJBvZcyHgeYMNaxa3C3s6PANhPzAUVaXV9eedAkptGJLN13IZj4LujpoAxRKo6bEdydv/5P23R3fx5PgTOpVI7riECAOIg2PThFsEoVCUwStmKCvIx1I2+YixIlv/OiaUWo4lrI/3ve5WGp4ZnuiJPk34JoYAlRbR6+sX14d8Ek6viq/pJUUIfVpNIkNMboUL4u+KpT47eyQ/mWih/KFduQyX9II/vQ+/IJGzEEHIipxAhdmV+K4=
  template:
    metadata:
      creationTimestamp: null
      name: mysecret
      namespace: thenamespace

backing up your sealing key #

kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml >main.key

converting .env files to a secret #

Working with web applications .env is a common way to store credentials. Let’s look at how we can convert these to secrets.

kubectl create secret generic mysecret --from-env-file=.env -n thenamespace --dry-run=client -o yaml > mysecret.yaml

Now you have a secret that looks like this.

apiVersion: v1
data:
  foo: YmFy
kind: Secret
metadata:
  creationTimestamp: null
  name: mysecret
  namespace: thenamespace

Seal it up just like before.

kubeseal -f mysecret.yaml -w mysealedsecret.yaml

Using the secrets #

I typically use the secrets in the container spec.

containers:
  - name: myapp
    envFrom:
      - secretRef:
          name: mysecret
    # You can still have other env vars
    env:
      - name: foo
        value: bar

Sometimes I want to mount the secret as a volume.

containers:
  - name: myapp
    volumeMounts:
      - name: mysecret
        mountPath: /mysecret
volumes:
  - name: mysecret
    secret:
      secretName: mysecret

Image Pull Secrets #

I also need to use imagePullSecrets. Let’s walk through the whole process. Starting with the secret.

kubectl create secret docker-registry regcred --docker-server=myprivateregistry.example.com --docker-username=foo --docker-password=bar --dry-run=client -o yaml

Generates the following secret.

apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJteXByaXZhdGVyZWdpc3RyeS5leGFtcGxlLmNvbSI6eyJ1c2VybmFtZSI6ImZvbyIsInBhc3N3b3JkIjoiYmFyIiwiYXV0aCI6IlptOXZPbUpoY2c9PSJ9fX0=
kind: Secret
metadata:
  creationTimestamp: null
  name: regcred
type: kubernetes.io/dockerconfigjson

---

the secret

Now we we can seal that secret.

kubeseal -f regcred.yaml -w regcred-sealed.yaml

And that gives us the following sealed secret that we can deploy into our cluster.

---
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: regcred
  namespace: default
spec:
  encryptedData:
    .dockerconfigjson: AgATYVEywkyYEaoErQbJo6xEZfOnRn1ydNTLkO3Jt/NF/UH+0o9lHpDecRpN0XnVu8xJUcdjkgD9q2XkwP8e6qQDS2mMPTiTNIN+8gbJx97WrD1YQDT0lXBuoyi9I/iwlXxx6MgH/6GY6CeGTz5SRlvoU0Xhlt4d11s7/xapdE8QMLsAReqPEv8oZHEyAxDRrjXX0V+tO8dV+G+GXjUDMBBceLael9rvGzSKIwDVXACVqQhLkB6FoP98M+yyBE46RBNnSnS0ShQM5PprL24HKpRZ43x4RM53KBrQ7R/MxeshafY+B6vUvrolmVox4sud8xngMOcjTO28LLOrck5V8ZiDabhN7ajHEf03IESr1o/ADGf5k9988Vv1txJtsZW0K2mpRu0D7/BLVL9KzbZ5ywULqIoD/Ur2GIGnZqMAKOq4laGp/GJtMKLrhmEvekT397wC/Gf/xdDKVhHf2p4ocsPu7LKFuS5H/Auel/Q5grdn8L5wwrO4VWRv3eJroKh/Hux7Qd7f64O7qdi0XthDocf+gmtjys+Gy72M7tyf8f/O+3oKbS4CWQVTj4ZThMc9znrFnHqt2q/7pAyytTQCpk51wlzOsNvOhCueJM/jmeahaL0LuBrqngqISpnd65sgVzBcZpwK9i2Fckyt0DrZLH+NoIuvaqNhzlF+OMbAft/ylWWKCH4WUP+FKG+1LXM7ud7AA3MMbGSBxHL0/WK/INa7MB56xZKMqqyvvLLQHFTQUROJjkgkzsumdOgwZTRgIFnAZ4+vOX3/1Rtt3mAs3vdoJhL4GuKUYCnEHt908eKkWEVEs7eMk5SdSRtIsbaXO2s0dtADwg==
  template:
    metadata:
      creationTimestamp: null
      name: regcred
      namespace: default
    type: kubernetes.io/dockerconfigjson

Now that we have our sealed registry secret, we can deploy it into our cluster.

kubectl apply -f regcred-sealed.yaml

Now we can use it to pull images from our private registry.

containers:
  imagePullSecrets:
    - name: regcred

Full example #

Here is a full deployment example using all the secrets we have created.

  • regcred
  • mounting a secret
  • envFrom secret
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    service: myservice
  name: myservice
  namespace: mynamespace
spec:
  replicas: 1
  selector:
    matchLabels:
      service: myservice
  strategy:
    type: Recreate
  template:
    metadata:
      creationTimestamp: null
      labels:
        service: myservice
    spec:
      containers:
        - envFrom:
            - secretRef:
                name: mysecret
          env:
            - name: foo
              value: bar
          image: private-registry.io/myimage:1.0.0
          name: myimage
          ports:
            - containerPort: 5000
              protocol: TCP
          resources: {}
          volumeMounts:
            - mountPath: /mysecret
              name: mysecret
      restartPolicy: Always
      volumes:
        - name: mysecret
          secret:
            secretName: mysecret
      imagePullSecrets:
        - name: regcred

Downside #

Now the main downside I see with kubeseal is that it does not provide a way to store your secrets in a way that you can access outside of your cluster. So you need to make sure that you have another solution in place to store your secrets so that you still have them if you ever were to take the cluster down or move from k8s to something else.

Overall the likelyhood of you loosing a production cluster is pretty low, so maybe it’s ok to just trust it depending on what the secrets are. Especially for things you control and can rotate anyways its fine.

kubernetes 6 months in

I stumbled into kubernetes December 2023 when I was looking for a better way to self host [1] applications. I was looking for something that didn’t require logging into a server and building and deploying like a cave man. I wanted a smoother experience than docker compose was giving me. https://waylonwalker.com/looking-for-a-heroku-replacement/ This post turned into a list of tools that I have adopted into my k8s workflow, and plan to keep. enjoy. Kompose # [2] [3] Kompose is a great tool for gettting going and converting your docker-compose to kubernetes manifests or helm templates. It was a great tool for me to get started with, but I was afraid that it was hindering me learning more and just blindly using its output so I have tried to use it less and less. I’m now not solely leaning on it, but using it to get out quick POCs with low friction. Kompose really helped me go 0 to 60 and get right into kubernetes with my existing docker compose files and very little change. I fou...
Configure Liveness, Readiness and Startup Probes This page shows how to configure liveness, readiness and startup probes for containers. For more information about probes, see Liveness, Readiness and Startup Probes. Before you beginYou need to ha... Kubernetes · kubernetes.io [1] What is the difference between health, liveness, readiness, and startup? This article does a great job at a full writeup description of how it works in kubernetes, here is my TLDR. - health 200 OK - I’m still responding to requests - health ERR - something happened and I cant respond to requests - liveness 200 OK - I’m ready for more work - liveness ERR - I’m still responding to requests, and i’m already working send requests to another pod, or scale up Z-pages # [2] These probes are commonly deployed at /healthz and /livez endpoints. Why the z? z is a convention that comes from google for meta endpoints to reduce conflict with actual endpoints, and can be deployed to any application. References: [1]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ [2]: #z-pages
GitHub - jesseduffield/lazydocker: The lazier way to manage everything docker The lazier way to manage everything docker. Contribute to jesseduffield/lazydocker development by creating an account on GitHub. GitHub · github.com [1] I’ve been using this for a few weeks now and it’s fantastic. It’s reminds me of lazygit, it gives a nice quick interface into the things I need and it just works. Yes I can git [2] status to see what changed, then diff the files, then commit hunks, but lazygit can do that in just a few keystrokes. lazydocker does this for docker. It gives me a nice view into whats running, what’s eating up disk space, and the networks I have. And if I see I have a bunch of exited containers, there is a bulk command righ there to clean them up. tldr docker ps on steroids [3] References: [1]: https://github.com/jesseduffield/lazydocker [2]: /glossary/git/ [3]: https://github.com/jesseduffield/lazydocker/blob/master/docs/resources/demo3.gif?raw=true
Uptime Kuma A self-hosted monitoring tool uptime.kuma.pet [1] Uptime kuma is a fantastic self hosted [2] monitoring tool. One docker run command and you are up and running. Once you are in you have full control over checking status of urls, frequency, allowed timeouts, and a HUGE list of notification providers docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 I deployed it in my homelab [3] today. [4] References: [1]: https://uptime.kuma.pet/ [2]: /self-host/ [3]: /homelab/ [4]: https://twitter.com/_WaylonWalker/status/1723077941649707468
- I am converting my docker compose env secrets over to k8s secrets. This guide was clear and to the point how I can replicate this exact workflow. First set the secret, the easiest way is to use kubectl wtih –from-literal because it automatically base64 encodes for you. kubectl create secret generic minio-access-key --from-literal=ACCESS_KEY=7FkTV**** -n shot If you don’t use the --from-literal you will have to base64 encode it. echo "7FkTV****" | openssl base64 Once you have your secret deployed, you have to update the container spec in your deployment manifest to get the valueFrom secretKeyRef. spec: containers: - env: - name: ACCESS_KEY valueFrom: secretKeyRef: key: ACCESS_KEY name: minio-access-key - name: SECRET_KEY valueFrom: secretKeyRef: key: SECRET_KEY name: minio-secret-key image: registry.wayl.one/shot-scraper-api name: shot-wayl-one ports: - containerPort: 5000 protocol: TCP resources: {} restartPolicy: Always
waylon walker (@_WaylonWalker) on X Which is more complicated X (formerly Twitter) · twitter.com [1] Wow, shocked at these results. All this time I’ve been told and believed that k8s is incredibly hard, and you need a $1M problem before you think about it because it will take a $1M team to maintain it. So far my experience has been good, and I definitely do not have a $1M problem in my homelab [2]. [1] References: [1]: https://twitter.com/_WaylonWalker/status/1718300097174270193 [2]: /homelab/
External Link thoughts.waylonwalker.com [1] I was looking to add running kubernetes jobs to a python cli I am creating, and I found this solution, mostly thanks to ollama run mistral:7b-instruct-q4_K_M and my loose understanding of what the yaml syntax is supposed to look like for a kubernetes job. This will let me create a job in the cluster, choose the image that runs, the command that is called, and how long until the job expires and is cleaned up. While the job still exists I can go in and look at the logs, but once its ttl has expired they are gone. from kubernetes import client, config # Load the default kubeconfig config.load_kube_config() # Define the API client for batch jobs api_instance = client.BatchV1Api() # Create a new job object job = client.V1Job( api_version="batch/v1", kind="Job", metadata=client.V1ObjectMeta(name="myjob"), spec=client.V1JobSpec( ttl_seconds_after_finished=100, template=client.V1PodTemplateSpec( metadata=client.V1ObjectMeta(labels={"app": "myjob"}), spec=client.V1PodSpec( containers=[ client.V1Container( name="myjobcontainer", image="busybox", command=["ls", "/"], ), ], restart_policy="Never", ), ), backoff_limit=1, )...
GitHub - mkimuram/k8sviz: Generate Kubernetes architecture diagrams from the actual state in a namespace Generate Kubernetes architecture diagrams from the actual state in a namespace - mkimuram/k8sviz GitHub · github.com [1] This is a sick kubernetes architecture diagran generation tool. Here is an example [2] installation # [3] $ curl -LO https://raw.githubusercontent.com/mkimuram/k8sviz/master/k8sviz.sh $ chmod u+x k8sviz.sh Usage # [4] ./k8sviz.sh --kubeconfig ~/.config/kube/falcon-k3s.yaml -t png -o k8sviz.png References: [1]: https://github.com/mkimuram/k8sviz [2]: https://raw.githubusercontent.com/mkimuram/k8sviz/master/examples/wordpress/default.png [3]: #installation [4]: #usage
Translate a Docker Compose File to Kubernetes Resources What Kubernetes · kubernetes.io [1] kompose is a sick cli to convert docker-compose.yml to kubernetes manifest. # install curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-linux-amd64 -o kompose kompose convert kompose convert -o deployment.yaml References: [1]: https://kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes/
[1] Running your own docker registry in one line podman run -d -p 5000:5000 --restart=always --name registry registry:latest References: [1]: /static/https://blog.nashcom.de/nashcomblog.nsf/dx/k3s-podman-and-a-registry.htm
[1] I was curious to see what was going on inside of my minio object storage. Great technique here by Frank to create an inspector pod, then you can do as you wish with the data. I created the manifest as pvc-inspector.yml apiVersion: v1 kind: Pod metadata: name: pvc-inspector spec: containers: - image: busybox name: pvc-inspector command: ["tail"] args: ["-f", "/dev/null"] volumeMounts: - mountPath: /pvc name: pvc-mount volumes: - name: pvc-mount persistentVolumeClaim: claimName: pvc-name Then used it like this. # create pvc-inspector pod kubectl apply -f pvc-inspector.yml # exec into inspector kubectl exec -it pvc-inspector -- sh # explore data ls /pvc # cleanup kubectl delete -f pvc-inspector.yml References: [1]: /static/https://frank.sauerburger.io/2021/12/01/inspect-k8s-pvc.html
Reddit - Please wait for verification reddit.com [1] Right after installing k3s you are going to need to use sudo to use any kubectl command. The reason for this is that the default config is owned by root. To get around this you will need to make your own config and set the KUBECONFIG environment variable To do this I used sudo one last time to copy the k3s.yaml file into my own directory and take ownership of it. sudo cp /etc/rancher/k3s/k3s.yaml /home/waylon/.config/kube sudo chown -R waylon:waylon ~/.config/kube export KUBECONFIG=~/.config/kube/k3s.yaml References: [1]: https://www.reddit.com/r/kubernetes/comments/cojjf5/can_i_access_k3s_using_just_kubectl_no_sudo_and/