DEV Community: Adeoye Malumi

Kubernetes Network Policies Explained (and How I Actually Made Them Work)

Adeoye Malumi — Thu, 09 Jul 2026 16:50:22 +0000

If you've ever wondered, "How do I stop my pods from randomly talking to everything in my cluster?" – this is the post for you.

Today, I dove into Kubernetes Network Policies – the way you control who can talk to whom inside your cluster. I started with weavenet, then switched to Calico, and I'm excited to walk you through how it all came together.

What Even Is a Network Policy?

A NetworkPolicy in Kubernetes is like a firewall rule for your pods. It lets you:

Control inbound traffic (who can talk to a pod)
Control outbound traffic (where a pod can talk to)

For example:

You can create a deny-all policy that blocks all incoming traffic to a pod.
Or an allow-only policy that says: "Only the backend pods can talk to the mysql pod on port 3306."

Without network policies, by default, everything can talk to everything in your cluster. That's fine for demos, terrible for real security.

Why I Needed a Different CNI

Kubernetes itself doesn't implement network policies. It just defines them. The actual work is done by your CNI plugin (Container Network Interface).

I started with weavenet, which supports basic network policies. But as I dug deeper, I realized I wanted something more powerful and production-friendly. That's when I switched to Calico, which is:

Fast
Scalable
Great for complex network policies
Works well with kind clusters (as long as you configure it correctly)

If you're just experimenting, weavenet is fine. If you want to level up your cluster networking, Calico is a great next step.

My Test Cluster: A Kind Setup with Calico

To test network policies, I created a simple kind cluster with:

1 control-plane node
2 worker nodes
Disabled default CNI (disableDefaultCNI: true)
Custom pod subnet: 192.168.0.0/16

kind Cluster YAML

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30001
        hostPort: 30001
  - role: worker
  - role: worker
networking:
  disableDefaultCNI: true
  podSubnet: "192.168.0.0/16"

Creating the Cluster

With the YAML saved as kind-config.yaml, I created the cluster like this:

kind create cluster --name day26 --config kind-config.yaml

Then I checked the nodes:

kubectl get nodes

And here's the part that was a bit confusing at first:

Until I installed a CNI (like Calico), the worker nodes stayed in a NotReady state.

That's because Kubernetes needs a CNI to:

Assign IPs to pods
Set up networking between nodes
Enable traffic to flow across the cluster

Without a CNI, the control-plane node can be Ready, but the worker nodes will remain NotReady until networking is configured.

Only after installing Calico did all nodes show as Ready:

kubectl get nodes
# NAME           STATUS   ROLES           AGE   VERSION
# day26-control-plane   Ready    control-plane   ...
# day26-worker          Ready    worker          ...
# day26-worker2         Ready    worker          ...

Once Calico was running, my cluster was ready for real network policy experiments.

The App I Built: Frontend → Backend → MySQL

To make network policies meaningful, I created a tiny 3-tier app:

frontend pod + service
backend pod + service
mysql pod + service (db service)

Pods & Services

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    role: frontend
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - name: http
          containerPort: 80
          protocol: TCP
***
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    role: frontend
spec:
  selector:
    role: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
***
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    role: backend
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - name: http
          containerPort: 80
          protocol: TCP
***
apiVersion: v1
kind: Service
metadata:
  name: backend
  labels:
    role: backend
spec:
  selector:
    role: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
***
apiVersion: v1
kind: Service
metadata:
  name: db
  labels:
    name: mysql
spec:
  selector:
    name: mysql
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
***
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    name: mysql
spec:
  containers:
    - name: mysql
      image: mysql:latest
      env:
        - name: "MYSQL_USER"
          value: "mysql"
        - name: "MYSQL_PASSWORD"
          value: "mysql"
        - name: "MYSQL_DATABASE"
          value: "testdb"
        - name: "MYSQL_ROOT_PASSWORD"
          value: "verysecure"
      ports:
        - name: http
          containerPort: 3306
          protocol: TCP

At this point, everything could talk to everything:

frontend could reach backend
backend could reach mysql
frontend could also reach mysql directly (which we probably don't want)

Now it was time to lock it down.

My First Real Network Policy: Only Backend → MySQL

The goal:

mysql should only accept traffic from pods with label role: backend
On port 3306
No one else (including frontend) should touch the database

NetworkPolicy Manifest

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-test
spec:
  podSelector:
    matchLabels:
      name: mysql
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: backend
      ports:
        - port: 3306

Key parts:

podSelector: targets the mysql pod (name: mysql)
policyTypes: [Ingress]: we're controlling inbound traffic
ingress.from.podSelector: only pods with role: backend are allowed
ports: only port 3306

After applying this:

backend → mysql works
frontend → mysql blocked
mysql → anywhere (outbound) still allowed (we didn't restrict Egress)

How I Tested It

I used a simple approach:

Run a temporary pod with curl or mysql client.
Try to reach services from different pods.
Observe which connections succeed or fail.

Example:

# From frontend pod – should fail
kubectl exec -it frontend -- curl -s http://db:3306

# From backend pod – should succeed
kubectl exec -it backend -- curl -s http://db:3306

Seeing the first one fail and the second one succeed was the "aha!" moment: the policy is actually working.

Wrapping Up

Network Policies are one of those things that feel abstract until you actually apply them and see connections blocked in real time. Once that happens, you suddenly understand:

Why security matters
Why "everything can talk to everything" is not a strategy
How Kubernetes gives you granular control over your cluster's traffic

Understanding Kubernetes Service Accounts (The Identity Every Pod Uses)

Adeoye Malumi — Tue, 07 Jul 2026 15:58:47 +0000

Most of us learn about Kubernetes users before we learn about Service Accounts. That's actually where the confusion starts Service Accounts end up looking like "just another kind of user," and you file them away without really getting what makes them different.

They're not just another user. They solve a completely different problem.

Today I learned that human users authenticate from outside the cluster — you, sitting at your laptop, running kubectl with your certificate or your login. But Pods run inside the cluster, and they often need to talk to the Kubernetes API too — to list other pods, read a ConfigMap, watch for changes, whatever. A Pod can't exactly type in a username and password. It needs its own identity.

That identity is called a Service Account.

User vs. Service Account

Before touching a single command, it's worth seeing the two side by side:

User	Service Account
Used by humans	Used by Pods
External to Kubernetes	Managed by Kubernetes
Usually authenticated using certificates	Authenticated using tokens
You create it outside the cluster	Kubernetes creates and manages it

Keep that table in your head — everything below is really just this table playing out in the terminal.

Step 1 — Checking Existing Service Accounts

❯ k get sa
NAME      AGE
default   38d

Notice I didn't create this. It was already there, 38 days old — as old as the namespace itself.

That's the first thing to internalize: every namespace automatically gets a Service Account called default. You don't ask for it. If you create a Pod and never say which Service Account it should use, Kubernetes quietly attaches this one for you. Keep that in mind — it comes back to bite (in a good way) later in this post.

Step 2 — Creating My Own Service Account

❯ k create sa build-sa
serviceaccount/build-sa created

❯ k describe sa build-sa
Name:                build-sa
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Events:              <none>

Simple enough — I now have a second identity, build-sa, sitting in the default namespace, ready to be attached to Pods later.

But here's the question that trips a lot of beginners up: why doesn't it have a token?

If you learned Kubernetes a few years ago, or you're reading an older tutorial, you'll expect describe sa to show a Tokens: field pointing at an auto-generated Secret. Not anymore. Newer versions of Kubernetes stopped automatically minting long-lived Secret-based tokens for every Service Account, mainly for security reasons — a token that never expires and just sits around as a Secret is a standing risk if it leaks. Instead, Kubernetes now prefers short-lived, automatically-rotated tokens issued on demand.

Since I specifically wanted a durable token I could inspect and use for --as testing, I had to create it myself.

Step 3 — Creating a ServiceAccount Token Secret

I wrote a secret.yaml that, at minimum, needs this annotation:

metadata:
  annotations:
    kubernetes.io/service-account.name: build-sa

This one line is doing all the work. It tells the Kubernetes controller: "This Secret isn't just a random Opaque blob — it's a token for the build-sa Service Account." Because of that annotation, a built-in controller notices the Secret, generates a signed token for build-sa, and populates the Secret with it automatically.

❯ k apply -f secret.yaml
secret/build-robot-secret created

❯ k get secret
NAME                 TYPE                                  DATA   AGE
backend-user         Opaque                                1      5d3h
build-robot-secret   kubernetes.io/service-account-token   3      14s

See the TYPE column — kubernetes.io/service-account-token, not Opaque. That type is exactly what tells Kubernetes "treat this Secret specially and fill it with SA credentials."

Inspecting the Secret

❯ k describe secret build-robot-secret
Name:         build-robot-secret
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: build-sa
              kubernetes.io/service-account.uid: d065d358-58fa-44a6-9656-8263e0fa05eb

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1107 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIs... (truncated)

Three fields, each with a job:

ca.crt — the cluster's certificate authority. Whoever holds this Secret can verify they're really talking to the real API server, not an impersonator.
namespace — just the namespace this identity belongs to (default), so any client using this Secret knows where it "lives."
token — the important one. This is a JWT (JSON Web Token), signed by the cluster. This is what a Pod, script, or client hands to the API server to say "I am build-sa, and here's proof." I've truncated the token above — treat these things like passwords, not like log output, even in a lab cluster.

If you decode a Service Account JWT (there's nothing secret about the structure, just don't paste your actual token online), you'll find claims like the issuer, the namespace, and a sub field that looks like system:serviceaccount:default:build-sa. That string is the Service Account's real, canonical identity inside Kubernetes — remember it, it matters in a minute.

Testing Permissions

Now the interesting part. I wanted to see what build-sa could actually do, without creating a Pod yet:

❯ k get pods --as build-sa
Error from server (Forbidden): pods is forbidden: User "build-sa" cannot list resource "pods" in API group "" in the namespace "default"

Two things to unpack here.

First — what does --as actually do? It's easy to assume you're "logging in" as build-sa. You're not. --as is impersonation. You're still using your own admin credentials to talk to the API server, but you're telling it: "Evaluate this request as if it came from build-sa instead of me." The API server checks whether your account is allowed to impersonate build-sa (admin usually is), and if so, it re-runs the authorization check as that identity. It's a testing and debugging superpower — you get to try on someone else's permissions without actually needing their credentials.

Second — why Forbidden? This is the single most important lesson in this whole exercise: the Service Account existed. The token existed. Authentication succeeded. Authorization failed.

Those are two separate gates in Kubernetes:

Authentication — "Who are you?" build-sa proved this fine, via impersonation.
Authorization — "What are you allowed to do?" Nothing had granted build-sa any permissions at all, so RBAC said no.

A lot of beginners collapse these into one concept. They're not the same thing, and separating them in your head will save you hours of confused debugging later.

Creating the Role

❯ k create role build-role \
--verb=list,get,watch \
--resource=pod
role.rbac.authorization.k8s.io/build-role created

Breaking down the flags:

role build-role — I'm creating a Role, which is a namespaced set of permissions (as opposed to a ClusterRole, which applies cluster-wide).
--verb=list,get,watch — the specific actions this Role allows. Not create, not delete — just read-style operations.
--resource=pod — the Kubernetes resource type these verbs apply to.

On its own, a Role does nothing. It's a permission template sitting unused until something binds an identity to it.

Creating the RoleBinding

❯ k create rolebinding rb \
--role=build-role \
--user=build-sa
rolebinding.rbac.authorization.k8s.io/rb created

This is the glue: it binds the build-role permissions to the identity build-sa.

One honest caveat worth flagging, since I want this post to be technically accurate and not just "it worked so it's fine": I used --user=build-sa here, and it worked in this exercise because I was testing purely through impersonation with --as build-sa, and --as treats whatever string you give it as a plain username.

But that's not actually how a real Service Account identifies itself to the cluster. Its canonical identity is system:serviceaccount:<namespace>:<name> — in my case, system:serviceaccount:default:build-sa. In production, the standard, correct way to bind a RoleBinding to a Service Account is:

--serviceaccount=default:build-sa

If I'd actually mounted this token inside a real client and tried to use it (rather than testing through admin impersonation), a binding made with --user=build-sa would not match that Service Account's real identity, and the request would still be Forbidden. So: my command worked for this specific impersonation test, but if you're setting this up for a real workload, use --serviceaccount=<namespace>:<name> instead. Good to know the difference exists before it costs you a debugging session.

Testing Again

❯ k get pods --as build-sa
No resources found in default namespace.

No error this time — just an empty result, because there genuinely were no pods yet. Authentication and authorization both passed. That's the fix landing.

Creating a Deployment

❯ k create deploy test --image=nginx
deployment.apps/test created

Worth pointing out deliberately: I created this Deployment as myself (admin), not as build-sa. build-sa only has list, get, and watch on pods — nowhere near enough permission to create a Deployment. If I'd tried k create deploy test --image=nginx --as build-sa, it would have been Forbidden too.

Watching the Pod

❯ k get po -w --as build-sa
NAME                    READY   STATUS    RESTARTS   AGE
test-56848fd9dc-fhdjv   1/1     Running   0          89s

The -w flag means watch — instead of printing the pod state once and exiting, kubectl keeps the connection open and streams updates as the pod's status changes. Combined with --as build-sa, this also confirms build-sa's watch verb from the Role is working, not just list and get.

Going Inside the Pod

This is where it got genuinely interesting.

❯ k exec -it test-56848fd9dc-fhdjv bash
error: exec [POD] [COMMAND] is not supported anymore. Use exec [POD] -- [COMMAND] instead

I hit this error a few times before it clicked. Older kubectl versions let you run kubectl exec pod bash and it would figure out where your flags ended and the container's command began. Modern kubectl refuses to guess — it wants an explicit -- to separate "arguments meant for kubectl" from "the command to run inside the container." So:

❯ k exec -it test-56848fd9dc-fhdjv -- bash
root@test-56848fd9dc-fhdjv:/#

That extra -- is the whole fix. Everything after it belongs to the container, not to kubectl.

The Most Interesting Discovery

Once inside, I went looking for exactly the kind of thing this Pod would need to talk to the API server — and there it was:

root@test-56848fd9dc-fhdjv:/var/run/secrets/kubernetes.io/serviceaccount# ls -lrt
total 0
lrwxrwxrwx 1 root root 12 Jul  7 14:38 token -> ..data/token
lrwxrwxrwx 1 root root 16 Jul  7 14:38 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 13 Jul  7 14:38 ca.crt -> ..data/ca.crt

Same three files as the Secret I inspected earlier — token, namespace, ca.crt — automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount, with no configuration from me at all. Kubernetes does this for every Pod by default, via a projected volume, so that any process running inside the container can immediately authenticate to the API server if it needs to (this is how things like controllers and operators, running as Pods themselves, talk back to Kubernetes).

Now the obvious beginner question, and the one I asked myself immediately: "Wait — I created build-sa. Why does the token in here say default?"

Sure enough, decoding what's inside shows a sub claim of system:serviceaccount:default:default — the default Service Account, not build-sa.

The answer is almost anticlimactic once you see it: my Deployment spec never included serviceAccountName: build-sa. I never told Kubernetes which Service Account this Pod should use — so it fell back to the one thing every namespace already has, the one from Step 1. The default Service Account.

This is, genuinely, the most valuable lesson from the whole exercise: creating a Service Account doesn't automatically attach it to anything. You have to explicitly wire it into a Pod (or Deployment, or Job, etc.) with serviceAccountName — or Kubernetes will silently keep using default on your behalf, and you won't get an error telling you. You'll just quietly have the wrong permissions, or, worse in production, the default Service Account might have more access than you meant to grant that workload.

Key Takeaways

Service Accounts are identities for Pods — not humans.
Every namespace automatically gets a default Service Account.
Service Accounts authenticate using tokens (JWTs), not certificates.
Newer Kubernetes versions don't auto-create long-lived token Secrets anymore — you create them explicitly when you need one.
RBAC still governs what a Service Account is allowed to do, exactly like it does for users.
--as impersonates another identity for testing — it doesn't log you in as them.
Authentication and authorization are two separate checks: proving who you are is not the same as being allowed to do something.
Bind RoleBindings to Service Accounts with --serviceaccount=<namespace>:<name> in real setups, not --user=<name>.
Pods automatically get their Service Account's credentials mounted at /var/run/secrets/kubernetes.io/serviceaccount — no extra config needed.
If you don't set serviceAccountName on a Pod, Kubernetes silently uses default. Always check.

Understanding Kubernetes ClusterRoles and ClusterRoleBindings

Adeoye Malumi — Tue, 07 Jul 2026 13:13:42 +0000

Yesterday I learned about Roles and RoleBindings. Today I explored ClusterRoles and ClusterRoleBindings for cluster-scoped resources like Nodes.

Why a Role Wasn't Enough

kubectl auth can-i get nodes

Output:

Warning: resource 'nodes' is not namespace scoped
no

Nodes are cluster-scoped resources, so a namespace Role cannot grant access.

Creating a ClusterRole

kubectl create clusterrole node-reader --verb=get,list,watch --resource=nodes

Verify:

kubectl get clusterrole | grep node-reader

Creating a ClusterRoleBinding

I first made a mistake:

kubectl create clusterrolebinding reader-binding --clusterrole=cluster-reader --user=adeoye

Checking permissions:

kubectl auth can-i get nodes --as adeoye

returned:

no - RBAC: clusterrole.rbac.authorization.k8s.io "cluster-reader" not found

The binding referenced a ClusterRole that didn't exist.

I fixed it by deleting and recreating the binding:

kubectl delete clusterrolebinding reader-binding
kubectl create clusterrolebinding reader-binding --clusterrole=node-reader --user=adeoye

Now:

kubectl auth can-i get nodes --as adeoye

returned:

yes

Testing as adeoye

kubectl config use-context adeoye
kubectl get nodes

Listing nodes worked.

Describing a node:

kubectl describe node cka-cluster3-worker

showed most information, but RBAC blocked access to leases and pods because the ClusterRole only granted access to nodes.

Trying to delete a node:

kubectl delete node cka-cluster3-worker

returned Forbidden because the ClusterRole only included get, list, and watch.

Key Takeaways

Roles are namespace-scoped.
ClusterRoles are cluster-scoped.
ClusterRoleBindings grant cluster-wide permissions.
RBAC permissions are resource-specific.
Kubernetes follows the principle of least privilege.

Understanding Kubernetes RBAC: Roles, RoleBindings, and and Client Certificates

Adeoye Malumi — Mon, 06 Jul 2026 14:14:46 +0000

One thing I discovered today is that before Kubernetes can decide what you're allowed to do, it first needs to know who you are.

That means there are two separate steps:

Authentication – Proving your identity using a client certificate.
Authorization – Deciding what you're allowed to do using RBAC.

In this lab, I created my own Kubernetes user named adeoye, authenticated the user with a certificate, and then used RBAC to control what that user could access.

Step 1 – Generate a Private Key

openssl genrsa -out adeoye.key 2048

This generates a 2048-bit RSA private key.

Think of this as your digital identity. It should never be shared.

Step 2 – Generate a Certificate Signing Request (CSR)

openssl req -new -key adeoye.key -out adeoye.csr -subj "/CN=adeoye"

A Certificate Signing Request asks Kubernetes to issue a client certificate.

The important part is:

/CN=adeoye

The Common Name (CN) becomes the Kubernetes username.

Step 3 – Base64 Encode the CSR

cat adeoye.csr | base64 | tr -d '\n'

Kubernetes expects the CSR to be embedded inside a YAML manifest as Base64-encoded text. The tr -d '\n' removes line breaks so it becomes a single continuous string.

Step 4 – Submit the CSR

After inserting the encoded CSR into csr.yaml, I submitted it.

kubectl apply -f csr.yaml

Initially, the request was in the Pending state so I had to approve the request.

Step 5 – Approve the Certificate

kubectl certificate approve adeoye

Approving the request tells Kubernetes to trust the user and issue a signed client certificate.

Step 6 – Extract the Signed Certificate

kubectl get csr adeoye -o jsonpath='{.status.certificate}' | base64 -d > adeoye.crt

Now I had:

adeoye.key
adeoye.crt

The key proves my identity, while the certificate proves Kubernetes trusts that identity.

Step 7 – Configure kubectl

kubectl config set-credentials adeoye \
--client-key=adeoye.key \
--client-certificate=adeoye.crt

Then I created a context.

kubectl config set-context adeoye \
--cluster=kind-cka-cluster3 \
--user=adeoye

A mistake I made: I initially typed lind-cka-cluster3 instead of kind-cka-cluster3, which caused API errors until I corrected the cluster name.

Finally, I switched to my new user.

kubectl config use-context adeoye

At this point I was authenticated, but I still didn't have permissions to perform actions.

RBAC Time!

Authentication tells Kubernetes who I am.

RBAC tells Kubernetes what I'm allowed to do.

Creating the Role

role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs:
    - get
    - watch
    - list

This Role only allows reading Pods.

Apply it:

kubectl apply -f role.yaml

Creating the RoleBinding

binding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default

subjects:
- kind: User
  name: adeoye
  apiGroup: rbac.authorization.k8s.io

roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

This binds the adeoye user to the pod-reader Role.

kubectl apply -f binding.yaml

Testing the Permissions

Verify permission:

kubectl auth can-i get pods

Output:

yes

List Pods:

kubectl get pods

Output:

No resources found in default namespace.

That means the command succeeded, but there were simply no Pods.

Next, I tried listing Deployments.

kubectl get deploy

Output:

Error from server (Forbidden): deployments.apps is forbidden

Why Could I Read Pods but Not Deployments?

The answer is in the Role.

It only grants access to:

resources:
- pods

It does not include Deployments.

Deployments belong to the apps API group, while Pods belong to the core API group.

Since my RoleBinding connects adeoye to the pod-reader Role, Kubernetes only allows the permissions defined there.

No Deployment permissions were granted, so Kubernetes correctly denied access.

This is the Principle of Least Privilege in action.

What I Learned

Kubernetes first authenticates users using client certificates.
The certificate's Common Name becomes the Kubernetes username.
A Role defines permissions.
A RoleBinding assigns those permissions to users.
Authentication and authorization are separate processes.
RBAC only grants explicitly defined permissions.
Pods and Deployments are different resources, so access to one doesn't imply access to the other.

Final Thoughts

Today's lab tied together authentication and authorization. Creating my own client certificate, configuring a new kubectl context, and then restricting that user with RBAC made the concepts much easier to understand.

Security in Kubernetes isn't about giving users full access,but about giving them exactly the permissions they need, nothing more.

Day 20&21/40 - Manage TLS Certificates In a Kubernetes Cluster

Adeoye Malumi — Fri, 03 Jul 2026 11:57:11 +0000

Today's challenge was about understanding how Kubernetes uses TLS certificates to secure communication between its components, and getting hands-on by onboarding a "new user" into the cluster using a Certificate Signing Request (CSR).

If you've ever wondered how kubectl actually proves to the API server that you're allowed to run commands, this is the exercise that answers it.

A quick rule of thumb before diving in: if a filename or extension has the word "key" in it, it's a private key. Otherwise, it's a public certificate. Keep that in mind as you read through the commands below.

Step 1: Generate a private key and a CSR

openssl genrsa -out adeoye.key 2048
openssl req -new -key adeoye.key -out adeoye.csr -subj "/CN=adeoye"

genrsa creates the private key, and req -new uses that key to generate a Certificate Signing Request. The -subj "/CN=adeoye" flag sets the "Common Name" on the certificate — this becomes the username Kubernetes will recognize once the cert is issued.

Gotcha: I typed adam.key in my req command before actually creating a file with that name, and got:
Could not open file or uri for loading private key from adam.key: No such file or directory
Lesson learned — the key file has to exist before you reference it when generating the CSR. Double-check your filenames match across commands.

Step 2: Base64-encode the CSR

The CSR object in Kubernetes expects the request in base64 form inside a YAML manifest. This is where things got interesting:

cat adeoye.csr | base64 tr -d "/"

That's wrong — it treats tr as a filename argument for base64, not a separate piped command:

base64: extra operand '/'

The correct version needs a pipe (|) before tr, and the actual newline character (\n), not the literal string "/n":

cat adeoye.csr | base64 | tr -d "\n"

This gives you a single-line base64 blob with no line breaks — exactly what the CSR YAML needs.

Step 3: Create the CSR manifest and apply it

Create a csr.yaml file with the base64-encoded request embedded in it, following the structure from the Kubernetes docs, then:

kubectl apply -f csr.yaml
kubectl get csr

NAME     AGE   SIGNERNAME                            REQUESTOR          REQUESTEDDURATION   CONDITION
adeoye   25s   kubernetes.io/kube-apiserver-client   kubernetes-admin   24h                 Pending

The CSR shows up as Pending — Kubernetes has received the request but it hasn't been approved yet.

Step 4: Approve the CSR

kubectl certificate approve adeoye

certificatesigningrequest.certificates.k8s.io/adeoye approved

Checking again with kubectl get csr now shows Approved,Issued — the cluster has signed the certificate.

Gotcha: kubectl approve certificate adeoye doesn't work — the order of the words matters:
error: unknown command "approve" for "kubectl"
It's kubectl certificate approve <name>, not kubectl approve certificate <name>.

Step 5: Retrieve and decode the issued certificate

kubectl get csr adeoye -o yaml > issuecert.yaml

The issued certificate lives (base64-encoded) inside that YAML file under status.certificate. To read the actual PEM certificate, decode it:

echo "<base64-blob>" | base64 -d

This prints out the human-readable certificate:

-----BEGIN CERTIFICATE REQUEST-----
MIICVjCCAT4CAQAwETEPMA0GA1UEAww...
-----END CERTIFICATE REQUEST-----

Gotcha: Pasting a long base64 string directly into the terminal can trigger "bracketed paste mode," which shows up as weird escape codes and leaves your shell hanging on a dquote> prompt. If that happens, press Ctrl+C to cancel and try again — wrapping the string in quotes (echo "...") helps avoid it.

To save the decoded certificate directly to a file instead of just printing it, redirect the output:

echo "<base64-blob>" | base64 -d > learner.crt

Gotcha: Writing -o learner.crt instead of > learner.crt doesn't work here — -o isn't a flag for base64, and the shell will try to run it as its own command:
zsh: command not found: -o
Use the > redirect operator to send output to a file.

Repeating the process for a second user

To make sure the workflow actually sank in, I repeated the whole thing for a second user, learner, this time being more careful with the pipe syntax:

openssl genrsa -out learner.key 2048
openssl req -new -key learner.key -out learner.csr -subj "/CN=learner"
kubectl apply -f learner.yaml
kubectl certificate approve learner
kubectl get csr learner -o yaml > issuecert-learner.yaml

NAME      AGE     SIGNERNAME                            REQUESTOR          REQUESTEDDURATION   CONDITION
learner   4m37s   kubernetes.io/kube-apiserver-client   kubernetes-admin   7d                  Approved,Issued

Once the certificate was decoded and saved to learner.crt, it would be ready to plug into a kubeconfig for that user, giving them client-cert-based access to the cluster.

Key commands from today

Generate a private key:

openssl genrsa -out adeoye.key 2048

Generate a CSR:

openssl req -new -key adeoye.key -out adeoye.csr -subj "/CN=adeoye"

Approve a CSR:

kubectl certificate approve <certificate-signing-request-name>

Deny a CSR:

kubectl certificate deny <certificate-signing-request-name>

Reference: Kubernetes docs — Create CertificateSigningRequest

What I took away from today

A CSR workflow has four clean stages: generate a key → generate a CSR → submit it to the API server as a CertificateSigningRequest object → get it approved and retrieve the signed cert.
base64 | tr -d "\n" (with the pipe, and a real newline character) is the correct way to get a clean, single-line encoded string for a YAML manifest.
kubectl certificate approve — command, then subcommand, then name — not the other way around.
Almost all my mistakes today were syntax slips (missing pipes, wrong flags, mismatched filenames), not conceptual ones. That's usually a good sign you understand what you're doing, even when the terminal disagrees with you for a minute.

Day 19/40 - Kubernetes ConfigMaps and Secrets

Adeoye Malumi — Thu, 02 Jul 2026 11:22:28 +0000

Today's mission: stop hardcoding values into pod manifests and learn how to inject them properly using ConfigMaps and Secrets. I also managed to break a few things along the way, which honestly taught me more than if everything had just worked first try. Let's get into it.

What is a ConfigMap?

As your manifest grows, it becomes harder to manage a pile of environment variables directly inside it. A ConfigMap lets you:

Pull those key-value pairs out of the manifest and store them as their own Kubernetes object
Inject that ConfigMap into a pod as environment variables (or as files, but that's for another day)
Reuse the same ConfigMap across multiple pods, so you're not repeating yourself everywhere

Basically, it's a clean way to separate configuration from your application definition.

Creating a ConfigMap

kubectl create cm app-cm --from-literal=firstname=adeoye --from-literal=lastname=malumi

Here, firstname and lastname are the keys, and adeoye / malumi are the values.

My first "gotcha" of the day

I actually tried to split this command across two lines like this:

kubectl create cm app-cm --from-literal=firstname=adeoye \
--from-literal=lastname=malumi

First attempt gave me:

error: exactly one NAME is required, got 2

Turns out I had a trailing space after the backslash on the first line. In bash, the \ has to be the very last character on the line for line continuation to work. A space after it breaks the continuation, and the shell just treats the next line as a separate (garbled) argument. When I finally got the syntax right, kubectl describe cm app-cm showed the value for firstname as adeoye--from-literal=lastname=malumi — my second flag had literally been glued onto the first value as text!

Lesson learned: either keep the command on one line, or make sure there's truly nothing (not even a space) after your \.

Once fixed, describe showed exactly what I wanted:

Data
====
firstname:
----
adeoye

lastname:
----
malumi

Injecting a ConfigMap into a Pod

Here's the pod manifest I used to consume the ConfigMap as environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    env:
    - name: FIRSTNAME
      valueFrom:
        configMapKeyRef:
          name: app-cm
          key: firstname
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']

The valueFrom.configMapKeyRef block tells Kubernetes: "don't hardcode this value — go fetch it from the app-cm ConfigMap, using the firstname key."

Gotcha #2: Pods are mostly immutable

After creating my ConfigMap with both firstname and lastname, I went back and added a LASTNAME env var to my already-running pod's manifest, then ran:

kubectl apply -f pod.yaml

And got slapped with:

The Pod "myapp-pod" is invalid: spec: Forbidden: pod updates may not change fields other than 
`spec.containers[*].image`,`spec.initContainers[*].image`,`spec.activeDeadlineSeconds`,
`spec.tolerations` (only additions to existing tolerations),
`spec.terminationGracePeriodSeconds` (allow it to be set to 1 if it was previously negative)

This was a great reminder: a bare Pod's spec is mostly frozen once it's created. Kubernetes only lets you patch a small allowlist of fields in-place — image, a couple of grace period settings, and tolerations. Environment variables are not on that list.

Two ways around this:

Option 1 — Delete and recreate:

kubectl delete pod myapp-pod
kubectl apply -f pod.yaml

Option 2 — Force replace in one shot:

kubectl replace --force -f pod.yaml

I went with replace --force, and it worked perfectly:

❯ kubectl replace --force -f pod.yaml
pod "myapp-pod" deleted from default namespace
pod/myapp-pod replaced

Verified inside the container:

❯ kubectl exec -it myapp-pod -- sh
/ # echo $FIRSTNAME
adeoye
/ # echo $LASTNAME
malumi

Side note: this is actually one of the reasons Deployments exist and are preferred over bare Pods in real-world use. A Deployment lets you update the pod template (image, env vars, etc.) and kubectl apply will handle the rolling replacement of pods for you — no manual delete/recreate dance required.

Secrets: same idea, but for sensitive data

Secrets work almost identically to ConfigMaps, except they're meant for sensitive values like passwords, tokens, or usernames you don't want sitting in plain text in your manifests.

I followed the official Kubernetes docs on defining container environment variables using Secret data.

Creating a Secret

kubectl create secret generic backend-user --from-literal=backend-username='adeoye-admin'

Using the sample pod from the docs

kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml

This pod injects the secret as an environment variable called SECRET_USERNAME.

One more small hiccup

Right after creating the pod, I tried to exec into it immediately:

❯ kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
error: Internal error occurred: unable to upgrade connection: container not found ("envars-test-container")

Checking kubectl get po showed the pod was still ContainerCreating. Classic case of being too impatient — I just needed to wait a few seconds for the container to actually spin up. Once it hit Running:

❯ kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
adeoye-admin

And there it is — the secret successfully injected as an env var.

Key Takeaways

ConfigMaps decouple non-sensitive configuration from your pod manifests, and can be reused across multiple pods.
Secrets work the same way but are the right home for sensitive values.
Both can be injected into a pod's containers via env.valueFrom.configMapKeyRef or secretKeyRef.
Watch your shell syntax — a stray space after a line-continuation \ will silently mangle your command.
Pods are mostly immutable once created. Only image, tolerations, and a couple of grace-period fields can be patched live. Everything else means delete + recreate, or kubectl replace --force. This is a big part of why Deployments exist.
Give newly created pods a moment to leave ContainerCreating before you exec into them.

That's Day 19 done — small errors, but each one taught me something I'll remember longer than if it had just worked on the first try.

Day 17/40 — Kubernetes Autoscaling: HPA vs VPA Explained With Hands-On Practice

Adeoye Malumi — Wed, 01 Jul 2026 12:09:21 +0000

If you've ever wondered how Kubernetes knows when to spin up more pods or give a pod more memory, that's autoscaling — and it's one of those concepts that sounds intimidating until you actually do it yourself. Day 17 of the #40DaysOfKubernetes challenge is where it clicked for me.

What is Autoscaling in Kubernetes?

At its core, autoscaling means Kubernetes adjusts resources automatically based on demand. You don't manually intervene every time traffic spikes. There are two main types:

HPA (Horizontal Pod Autoscaler) — adds or removes pods based on CPU/memory usage
VPA (Vertical Pod Autoscaler) — adjusts the resources (CPU/memory) of existing pods

Think of HPA as hiring more staff when the shop gets busy. VPA is more like giving one staff member more tools to handle the workload alone.

What I Did — Setting Up HPA

First I deployed the sample php-apache app with defined CPU requests and limits:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: registry.k8s.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m

apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

The key part is setting resources.requests.cpu — HPA needs this to calculate utilization. Without it, the autoscaler has nothing to measure against.

Then I created the HPA object targeting 50% average CPU utilization, with a minimum of 1 pod and maximum of 10. This is the declarative method:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

While this is the imperative method:

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Generating Load to Watch It Scale

This is the fun part. I ran a load generator in a separate pod — basically a loop hammering the apache service with requests:

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- \
  /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

Then watched the HPA respond in real time:

kubectl get hpa php-apache --watch

Watching the replica count climb from 1 to several pods as CPU utilization crossed 50% made the whole concept land in a way that reading documentation never does.

HPA vs VPA — When Do You Use Which?

	HPA	VPA
Scales	Number of pods	Pod resource limits
Best for	Stateless apps with variable traffic	Apps where sizing is hard to predict upfront
Works with	CPU, memory, custom metrics	CPU and memory

In practice, most production workloads use HPA. VPA is useful during early deployment when you're still figuring out the right resource requests for an app.

Key Takeaway

Don't skip setting resources.requests in your deployment spec. HPA is blind without it. That one line is what connects your workload to the autoscaler.

Resource Requests and Limits in Kubernetes (Hands-on with Metrics Server) #40DaysOfKubernetes – Task 16/40

Adeoye Malumi — Fri, 19 Jun 2026 16:18:45 +0000

What this is about

Today’s mission was simple on paper:
Teach Kubernetes how to handle memory politely.

In reality:
Kubernetes behaved like a strict landlord, and my containers learned consequences.

We explored:

memory requests (what you ask for)
memory limits (what you’re allowed to touch)
what happens when containers ignore both

Step 1: Creating a safe playground (namespace)

I started by isolating everything so I wouldn’t accidentally break the entire cluster (again):

kubectl create namespace mem-example

Step 2: Installing Metrics Server (the “fitness tracker” for pods)

Metrics Server is basically Kubernetes’ way of checking:

“Who is eating all the RAM?”

Installed it using the provided YAML.

Then… immediately learned Kubernetes loves drama.

Problem #1: Image pull failure 😭

My pod refused to start:


ImagePullBackOff

Translation:

“I tried to download your image… but the internet said no.”

So before I could even stress memory, Kubernetes was already stressed.

Then I sorted it out by deleting the metrics server and restarting it.

Step 3: A well-behaved container (for once)

Now I created a pod with rules:

Request: 100Mi (be reasonable)
Limit: 200Mi (don’t get greedy)
resources:
requests:
memory: "100Mi"
limits:
memory: "200Mi"

And then I told it:

“You may use 150Mi, but don’t embarrass me.”

Command:

kubectl apply -f memory-request-limit.yaml

What happened?

Shockingly… it behaved.

Checked usage:

kubectl top pod memory-demo -n mem-example

It used ~150Mi.

So Kubernetes basically said:

“You asked for 100Mi, but I’ll allow vibes up to 200Mi. Based off the yaml specifications”

Step 4: The “don’t exceed your limit” experiment 💀

Now I got ambitious (or careless).

Created another pod:

Request: 50Mi
Limit: 100Mi
Actual attempt: 250Mi (yes… I pushed it)

kubectl apply -f mem2.yaml

The result: Kubernetes said NO.

OOMKilled
Exit code 137

The container basically got:

“You exceeded your budget. Session terminated.”

And then it restarted… and died again… and again.

So yes, I successfully created a loop of failure.

Step 5: The “impossible request” experiment

Now I tried something unrealistic:

Request: 1000Gi memory
Limit: 1000Gi

Basically:

“I would like half the cluster please.”

Result:

Pod stayed in Pending
No node could even consider it

Kubernetes response:

“Be serious.”

What I learned (the real value)
Requests are not suggestions — they decide where your pod even goes
Limits are not suggestions — they decide how your pod dies
Kubernetes is very polite… until you exceed limits
OOMKilled is just Kubernetes saying “enough”
If your request is unrealistic, your pod doesn’t crash — it just never gets invited in

The Tutorial I followed:

Predicting Tomorrow's Tremors: A Machine Learning Approach to Earthquake Nowcasting in California

Adeoye Malumi — Thu, 03 Jul 2025 12:56:11 +0000

Earthquakes are a constant, terrifying reality, especially in tectonically active zones like California. While pinpointing the exact time and location of a future quake remains one of science's grand challenges, the concept of earthquake nowcasting offers a pragmatic alternative: assessing the current probability of a significant event happening within a near-term window.

This article walks through the entire journey of building and deploying a machine learning model designed to nowcast the likelihood of Magnitude 6.0+ earthquakes in California within a 30-day horizon. I'll cover everything from robust data acquisition to feature engineering, model training, and the practicalities of deployment.

1. The Bedrock: Data Acquisition

Every data-driven project starts with data. For me, this meant building a comprehensive historical catalog of seismic events in California.

I leveraged the ObsPy library to interact with the USGS FDSN client. My goal was to gather all earthquakes with a Magnitude 2.0 or greater (M2+) within a specific region (32.0°N to 42.0°N latitude, -125.0°W to -114.0°W longitude) from 1990 to the present day.

One of the initial hurdles was dealing with potential API request limits when trying to fetch decades of data at once. To overcome this, I implemented a robust chunking mechanism. Instead of one massive request, I'd iteratively fetch data in smaller time windows (starting with years, then recursively breaking down into months, weeks, or even days if a chunk proved too large). This ensured I could reliably acquire the entire historical catalog without hitting service caps. The collected data was then saved locally as a CSV for efficient reuse.

2. Sculpting Signals: Feature Engineering

Raw earthquake event lists aren't directly useful for machine learning. The magic happens in feature engineering – transforming this raw data into meaningful numerical representations that the model can learn from.

For each sliding time window, I calculated a rich set of features:

Regional Features (Across the Entire California Study Area):
These capture the overall seismic state of the broader region:
Seismicity Rate: The total number of events within the window.
b-value: A critical seismological parameter indicating the ratio of small to large earthquakes. A decrease in b-value can sometimes precede larger events, suggesting increased stress.
Magnitude Statistics: Mean, standard deviation, and maximum magnitude.
Inter-Event Time Statistics: Mean and coefficient of variation of the time between successive earthquakes. Irregularity (high CV) might be a signal.
Depth Statistics: Mean and standard deviation of earthquake depths.

Spatial Features (Per Grid Cell):

To capture localized patterns, I divided the entire California region into a grid of 0.5-degree by 0.5-degree cells. For each cell, if it contained at least 3 events within the window (our MIN_EVENTS_PER_CELL threshold to ensure statistical significance), I calculated:

Local Seismicity Rate
Local b-value
Local Mean Magnitude

I used a 90-day sliding window to compute these features, advancing the window by 7 days for each new sample. The target label for the model was binary: 1 if a Magnitude 6.0+ earthquake occurred within the subsequent 30-day prediction horizon after the feature window, and 0 otherwise.

3. The Brain: Model Training & Evaluation

With our features ready, it was time to train the predictive brain of our system.

I chose XGBoost Classifier as the core model. It's a powerful gradient boosting framework known for its performance and ability to handle complex, tabular datasets.

Tackling Class Imbalance

Earthquake nowcasting suffers from extreme class imbalance: periods without a large earthquake significantly outnumber periods preceding one. To address this, we employed several strategies:
Stratified Splitting: When splitting data into training and test sets, we used stratify=y to ensure both sets maintained the original proportion of large earthquake events.
SMOTE (Synthetic Minority Over-sampling Technique): Applied to the training data, SMOTE generated synthetic samples of the minority class (large earthquake events), effectively balancing the dataset for the model to learn from. We dynamically adjusted SMOTE's k_neighbors parameter to ensure it always had enough real minority samples to work with.

Hyperparameter Tuning & Evaluation

We performed hyperparameter tuning using GridSearchCV, focusing on optimizing the model's F1-score. The F1-score is particularly valuable for imbalanced datasets as it provides a balance between precision (minimizing false positives) and recall (minimizing false negatives).

After training, the model's performance was rigorously evaluated on the untouched test set. I examined:

Classification Report: Providing precision, recall, and F1-score for both classes.
ROC-AUC Score: A measure of the model's ability to distinguish between classes across all possible thresholds.
Confusion Matrix: A visual breakdown of true positives, true negatives, false positives, and false negatives.

Here's an example of a Confusion Matrix from a training run:

We also analyzed the Precision-Recall Curve
, which is often more informative than ROC for imbalanced datasets:

Finally, we looked at Feature Importance to understand which seismic indicators the XGBoost model deemed most influential in its predictions. Features related to regional seismicity rate, standard deviation of depth, coefficient of variation of inter-event time, and localized spatial b-values often topped the list.

The Optimal Threshold

Crucially, we didn't just rely on the model's default 0.5 probability threshold. We analyzed the Precision, Recall, and F1-score across a range of thresholds and identified the optimal F1-score threshold as 0.3593. This value provides the best balance between catching large earthquakes and avoiding excessive false alarms for our specific model.

4. Bringing it Live: Model Deployment

Training a great model is one thing; making it useful in a real-world setting is another. This required careful deployment steps.

Model Serialization

After training, the best_model (our optimized XGBoost classifier) was saved to disk using joblib. But there's a critical detail: XGBoost models are sensitive to the order of input features. So, alongside the model, we also saved the exact ordered list of feature column names that the model was trained on. This ensures that when the model is loaded later for prediction, the incoming data is always presented in the correct sequence.

Python

import joblib
# ... after model training ...
joblib.dump(best_model, "earthquake_prediction_model.joblib")
joblib.dump(X.columns.tolist(), "model_feature_columns.joblib")

The Prediction Script (predict_earthquake.py)

A separate, lightweight Python script (predict_earthquake.py) was created specifically for making live predictions. This script is designed to run independently, without needing to retrain the model. Its core functions are:

Load Assets: It loads the saved earthquake_prediction_model.joblib and the model_feature_columns.joblib list.

Fetch Latest Data: It connects to the USGS FDSN client to fetch only the most recent earthquake data required for the current 90-day feature window (ending at the current time).

Consistent Feature Engineering: It applies the exact same feature engineering logic as the training pipeline to this latest data. This consistency is paramount. It also handles cases where certain grid cells might be inactive in the current window by filling their features with zeros, matching how the training data was prepared.

Predict: The engineered features are passed to the loaded model, which outputs a probability score.

Threshold & Alert: The pre-determined optimal threshold of 0.3593 is applied. If the predicted probability exceeds this, an alert is triggered.

5. Staying Vigilant: Automation & Alerting

A prediction system is only useful if it runs consistently and communicates its findings effectively.

Automated Scheduling
To ensure continuous nowcasting, predict_earthquake.py was automated to run at regular intervals (e.g., daily). This was set up using:

cron jobs for Linux/macOS environments, which allow scheduling commands to run at specific times.

Task Scheduler for Windows, providing a graphical interface for similar functionality.

Robust Alerting & Logging
Beyond simple console output, the system was enhanced for practical deployment:

Dedicated Log File: All prediction cycle information – data fetches, warnings (like NaN values being filled), and final predictions – are written to a dedicated log file (earthquake_prediction.log). This is invaluable for monitoring the system's health and troubleshooting.

Email Notifications: Crucially, if a "Large Quake" prediction is made (probability >= 0.3593), the script is configured to send an immediate email alert. This ensures that relevant stakeholders are notified without needing to constantly monitor logs.

Python

# Conceptual snippet for email alert in predict_earthquake.py
import smtplib
from email.mime.text import MIMEText
import logging # Already configured earlier

# ... email config variables ...

def send_email_alert(subject, body):
    try:
        msg = MIMEText(body)
        msg["Subject"] = subject
        msg["From"] = EMAIL_SENDER
        msg["To"] = EMAIL_RECEIVER
        with smtplib.SMTP(SMTP_SERVER, SMTP_PORT) as server:
            server.starttls()
            server.login(EMAIL_SENDER, EMAIL_PASSWORD)
            server.send_message(msg)
        logging.info(f"Email alert sent successfully to {EMAIL_RECEIVER}")
    except Exception as e:
        logging.error(f"Failed to send email alert: {e}")

# ... later in make_prediction() ...
if prediction_label == 1:
    alert_message = (f"ALERT! A large earthquake (M{TARGET_MAGNITUDE}+) is predicted "
                     f"in California within the next {PREDICTION_HORIZON_DAYS} days.\n"
                     f"Probability: {prediction_proba:.4f}")
    logging.warning(f"Prediction: {alert_message}")
    send_email_alert("Earthquake Prediction ALERT!", alert_message)

Conclusion

This project successfully establishes a complete, automated pipeline for earthquake nowcasting in California using machine learning. From meticulously gathering and engineering seismic data to training a robust XGBoost model and deploying it with automated scheduling and alerting, the system represents a significant step towards leveraging data science for natural hazard preparedness.

While the inherent complexities of earthquake prediction mean no model is perfect, this system provides a valuable, data-driven assessment of current seismic risk. The journey highlights the importance of not just model accuracy, but also the practical considerations of data handling, feature consistency, and operational deployment in building real-world ML solutions.

The next steps involve continuous monitoring of the system's performance, periodic retraining with updated data to ensure relevance, and potentially exploring more advanced validation techniques like time-series cross-validation for even greater robustness.

Resources

Full Project Code (GitHub):(https://github.com/oye-bobs/siesmicanalyzer)

ObsPy Library: https://docs.obspy.org/

USGS FDSN Web Service: https://earthquake.usgs.gov/ws/

Scikit-learn Documentation: https://scikit-learn.org/

XGBoost Documentation: https://xgboost.readthedocs.io/

Embracing Open Source: A Catalyst for Scientific Progress

Adeoye Malumi — Fri, 19 Apr 2024 13:41:52 +0000

Hey Dev Community!

Let's embark on a thrilling journey through the realm of open source, where innovation knows no bounds and collaboration reigns supreme!

Today, we're diving into why open source is the ultimate game-changer for scientific progress and how it's shaping a brighter future for us all. Get ready for a wild ride!

Why Open Source Matters in Science:

Transparency: Open source is like a spotlight shining on the secrets of science. It unveils research methodologies, algorithms, and data for all to see, fostering a culture of transparency and trust within the scientific community.
Collaboration: Imagine a global science party where everyone's invited! That's the power of open source. By tearing down barriers to access, it brings together brilliant minds from around the world to collaborate on groundbreaking research.
Faster Iteration: With open source, the innovation treadmill goes into overdrive! Scientists can build upon existing solutions, tweak them to perfection, and share their creations with the world—all at warp speed.
Reproducibility: Science is all about trust, and open source ensures that trust never falters. By providing open access to source code and data, it makes research findings easily reproducible, empowering others to verify and validate discoveries.

Illustrating the Impact:

Let's take a joyride through the world of climate science, where open source is leading the charge:

Data Sharing: Climate data from every corner of the globe flows freely, thanks to open source platforms like Open Climate GIS. This treasure trove of data fuels cutting-edge research and fuels our understanding of Earth's ever-changing climate.
Collaborative Research: Scientists from diverse fields come together on platforms like Open Climate Collaborative to tackle climate change head-on. From atmospheric physicists to data wizards, everyone brings their A-game to the fight against the climate crisis.
Reproducibility: The winds of change blow strong in the world of climate research, where transparency reigns supreme. Researchers openly share their methodologies, code, and data, ensuring that every discovery is as solid as a rock.
Innovation: Open-source innovation is the wind beneath our wings as we soar towards a greener future. From AI-powered climate models to blockchain-based carbon markets, the possibilities are endless!

Conclusion:
So there you have it, fellow adventurers—open source isn't just a buzzword; it's the key to unlocking a world of endless possibilities. In the grand quest for scientific progress, let's hoist the open source flag high and march boldly into the future!

What are your thoughts on the role of open source in scientific progress? Share your insights below and let's keep the conversation going!

What was your win this week?

Adeoye Malumi — Fri, 19 Apr 2024 13:28:17 +0000

I started coding again and I've been able to learn a whole lot on github. from learning how to use code spaces to developing my own portfolio page, It's been a really interesting journey.