Thibaut Freedisch

Backend Engineer • write on Distributed Systems & Kubernetes
ex. @OWASP • Google Summer of Code '24

[Thibaut Freedisch @freedisch]

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

[Thibaut Freedisch @freedisch]

@devops_nk Hi everyone, open to connect with everyone, currently doing a 99 days series on Kubernetes👋🏾

[Thibaut Freedisch @freedisch]

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.

[Thibaut Freedisch @freedisch]

Day 56/99 of diving into Kubernetes

i spent the day working k8s observability especially on Liveness, readiness and startup probes.

[Thibaut Freedisch @freedisch]

@academiadgamers @grok what song is this?

[Thibaut Freedisch @freedisch]

@it_is_moussa @hthieblot just hustling mann🥲

[Thibaut Freedisch @freedisch]

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

[Thibaut Freedisch @freedisch]

Day 56/99 of diving into Kubernetes

i spent the day working k8s observability especially on Liveness, readiness and startup probes.

[Thibaut Freedisch @freedisch]

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.

[Thibaut Freedisch @freedisch]

just use Graphql man

[Tomilola Oluwafemi | Software Engineer @tomilola_ng]

216 API Endpoints delivered in just 3 weeks

This are the best times to build ✅

[Thibaut Freedisch @freedisch]

@kristijan_kralj Basically saying my Kubernetes mastery won’t save me from bad architecture decisions 😅

[Thibaut Freedisch @freedisch]

@devops_nk ECR when AWS bills got tired of Docker's rate limits

[Thibaut Freedisch @freedisch]

@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

[Thibaut Freedisch @freedisch]

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.

[Thibaut Freedisch @freedisch]

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

[Thibaut Freedisch @freedisch]

@0xlelouch_ the collective hours spent explaining Ingress and still seeing 404s is a rite of passage at this point

[Thibaut Freedisch @freedisch]

@systemdesignone I'm old fashion i still prefer microsoft word

[Thibaut Freedisch @freedisch]

@SumitM_X For sure, HTTPS is non-negotiable

[Thibaut Freedisch @freedisch]

@fromcodetocloud they follow each other u can't do 1 without the other

[Thibaut Freedisch @freedisch]

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.

[Thibaut Freedisch @freedisch]

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

[Thibaut Freedisch @freedisch]

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.

[Thibaut Freedisch @freedisch]

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.