today i'm launching Havril
an open-source context memory layer for AI platforms
easily save and inject your memories across ChatGPT or Gemini or Claude
never repeat yourself again
more coming soon
Day 57/99 of diving into Kubernetes
today i cleaned up my understanding of liveness and readiness probes.
The thing that helped most was realizing they answer two completely different questions about the same container.
K8s already restarts containers when the process crashes, that part is automatic. But what about an app that is technically running, process alive, port open, just deadlocked or hung on a request that never returns.
The kernel sees nothing wrong so Kubernetes does nothing while users keep timing out.
That is the zombie problem and that is exactly what a liveness probe solves. The kubelet periodically pokes the app with an HTTP call, a TCP connection or a custom command, and if the response is bad enough times in a row, the container gets killed and restarted. Readiness probe is the same mechanism but for a different decision.
Instead of asking "should I restart this?" it asks "should I send traffic to this?" When it fails, the pod is removed from the service endpoints, traffic stops flowing to it, but the container keeps running.
Great for slow startups when the app needs 30 seconds to warm up before serving requests, or for temporary dependency outages where restarting would not help anyway.
The clean rule, if restarting would fix it use liveness, if you just want to pause traffic until it recovers use readiness. Most production apps use both.
I really enjoyed being part of the google summer of code, but how will this one be different from it?
will it still around open source or more like a bootcamp where students learn how to use AI tools it?
really except it to be around working directly with projects learning while doing
Day 55/99 of diving into Kubernetes
i spent today understanding ServiceAccounts and RBAC properly. Pods sometimes need to talk to the K8s API to create or list resources but the API has no idea who is making a request unless something proves it.
That something is a ServiceAccount which is just a non-human identity that lives in the cluster.
When a pod is created with serviceAccountName: myuser, Kubernetes automatically mounts a token into the pod and that token is what the pod uses to prove who it is on every API call.
But authentication is only half the story. Knowing who you are does not mean you are allowed to do anything.
That is where RBAC comes in. A Role defines a list of verbs allowed on specific resources like get, list, watch, create, delete.
A RoleBinding connects that Role to a service account. The pod inherits whatever permissions are bound to its identity. Want to make sure a pod cannot randomly delete things, leave the delete verb out of its role. That is literally the entire mechanism.
ServiceAccount is the identity, Role is the list of allowed actions, RoleBinding ties them together, and the pod references the account by name.
@devops_nk Deployment with a PVC works for 1 stateful pod but the moment you need multiple replicas of a stateful app, the whole thing collapses that's why StatefulSets exist bcs some pods are not interchangeable
Day 55/99 of diving into Kubernetes
i spent today understanding ServiceAccounts and RBAC properly. Pods sometimes need to talk to the K8s API to create or list resources but the API has no idea who is making a request unless something proves it.
That something is a ServiceAccount which is just a non-human identity that lives in the cluster.
When a pod is created with serviceAccountName: myuser, Kubernetes automatically mounts a token into the pod and that token is what the pod uses to prove who it is on every API call.
But authentication is only half the story. Knowing who you are does not mean you are allowed to do anything.
That is where RBAC comes in. A Role defines a list of verbs allowed on specific resources like get, list, watch, create, delete.
A RoleBinding connects that Role to a service account. The pod inherits whatever permissions are bound to its identity. Want to make sure a pod cannot randomly delete things, leave the delete verb out of its role. That is literally the entire mechanism.
ServiceAccount is the identity, Role is the list of allowed actions, RoleBinding ties them together, and the pod references the account by name.
Day 54/99 of diving into kubernetes
today was a long one. i covered SecurityContext, resource limits, quotas, and the two completely different ways to inject a secret into a pod.
A lot of small things that change how the pod actually behaves at runtime. Let me break it down
The mental model that helped me most today. If the secret looks like a sentence, use an env var. If it looks like a file, mount it as a volume. Short tokens and API keys go in env.
Certs, SSH keys, config blobs go on disk. Both can coexist in the same pod, they are different tools for different shapes of data.
Day 54/99 of diving into kubernetes
today was a long one. i covered SecurityContext, resource limits, quotas, and the two completely different ways to inject a secret into a pod.
A lot of small things that change how the pod actually behaves at runtime. Let me break it down
Day 53/99 of diving into Kubernetes
i learned three new things today on security and resource management.
1st runAsUser forces the container to run as a specific UID instead of whatever the image defaulted to.
running as root inside a container is a security risk, this is how you avoid it. Second, Linux capabilities like NET_ADMIN and SYS_TIME which let you give a container one specific privilege without making it fully root.
way cleaner than just granting full access when you only need one thing.
3rd, resource requests and limits. Requests are what Kubernetes reserves for the pod when scheduling decisions are made, limits are the hard ceiling at runtime.
without requests Kubernetes does not know how much space your pod actually needs and can pack nodes wrong.
without limits one pod can eat the whole node. Small fields with real impact.
Volumes also auto-update inside the running pod when you change the secret in Kubernetes, no restart needed. Better for things that rotate, better for things that are too big to be env vars, better when leaks via crash dumps matter.