Forem: Md Khurshid

Kubernetes 102: Setting Up Your First Cluster and Core Concepts 🚀

Md Khurshid — Wed, 17 Sep 2025 19:11:49 +0000

In the previous post Kubernetes 101, we learned what Kubernetes is, its features, and how it works behind the scenes.

Now it’s time to get hands-on! In this guide, we’ll:

1. Install a lightweight Kubernetes cluster (using K3s)
2. Explore the basic concepts of Kubernetes (nodes, pods, deployments, etc.)
3. Learn how to interact with Kubernetes using kubectl

Let’s get started.

⚙️ Installing Kubernetes (K3s)

There are multiple ways to install Kubernetes:

Minikube – runs Kubernetes inside a VM
Kind – runs Kubernetes using Docker containers
MicroK8s – Canonical’s lightweight K8s for Linux
K3s – an ultra-lightweight distribution

👉 For this tutorial, we’ll use K3s because it’s super lightweight, easy to install, and comes with everything you need (including kubectl).

Step 1: Install K3s

Run this command to install K3s:

$ curl -sfL https://get.k3s.io | sh -

This will download and install the latest version of K3s, then start it as a system service.

Step 2: Configure kubectl

Now, copy the kubeconfig file so that kubectl can talk to your cluster:

$ mkdir -p ~/.kube
$ sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
$ sudo chown $USER:$USER ~/.kube/config

Tell your shell to use this config:

$ export KUBECONFIG=~/.kube/config

👉 Add this line to ~/.bashrc or ~/.zshrc to make it permanent.

Step 3: Verify the Cluster

$ kubectl get nodes

You should see something like:

NAME       STATUS   ROLES                  AGE   VERSION
myhost     Ready    control-plane,master   2m    v1.31.0+k3s1

🎉 Congrats! Your Kubernetes cluster is up and running!

🔑 Kubernetes Basic Terms and Concepts

Before we deploy apps, let’s understand the building blocks of Kubernetes.

1. Nodes

Nodes are the machines (computers or VMs) that make up your Kubernetes cluster.

They actually run the containers for your apps.
Kubernetes keeps track of every node’s health and status.

2. Namespaces

Namespaces are like separate rooms inside the cluster.
They help organize and isolate resources, so names don’t clash.

Two Pods in the same namespace cannot have the same name.
But two Pods with the same name can exist in different namespaces.
Useful for teams, projects, or different environments (like dev, test, prod).

3. Pods

Pods are the smallest unit in Kubernetes.
They are like a wrapper around one or more containers that must run together on the same node.

Often, one Pod = one container.
But a Pod can have multiple containers that share storage and network.
Special containers (init or ephemeral) can be added for setup or debugging.

4. ReplicaSets

ReplicaSets make sure the right number of Pod copies (replicas) are always running.

If a Pod crashes or a Node fails, the ReplicaSet creates a new Pod automatically.

5. Deployments

A Deployment is a higher-level controller on top of ReplicaSets.

You declare how many Pods you want and what version of the app to run.
Kubernetes then updates or rolls back automatically.
You can pause, scale, or roll back easily.

6. Services

Services expose Pods to the network so other apps or users can reach them.

They provide a stable IP or DNS name even if Pods come and go.
Ingress works with Services to set up HTTP/HTTPS routes and load balancing.
You can also add TLS certificates for HTTPS.

7. Jobs
Jobs run one-time or batch tasks.

A Job creates Pods and waits until they finish.
If a Pod fails, it retries until the task completes.
CronJobs are like Jobs with a schedule (e.g., run every night at 1 a.m.).

8. Volumes

Volumes are storage that lives outside a Pod’s life.

They let Pods store data that doesn’t disappear when a Pod restarts.
Good for databases or file servers.
Kubernetes works with many storage types (cloud disks, local disks, etc.).

9. Secrets and ConfigMaps

Secrets store sensitive data like passwords, API keys, or certificates.
ConfigMaps store normal configuration like app settings.
Both can be given to Pods as environment variables or as files mounted in a volume.

10. DaemonSets

A DaemonSet makes sure one Pod runs on every Node in the cluster.

Useful for things that must run everywhere, like: Logging agents, Monitoring tools
When a new Node joins, Kubernetes automatically runs the DaemonSet Pod on it.

11. Network Policies

Network Policies are rules for traffic between Pods.

They control who can talk to whom inside the cluster.
Two types of rules:

Ingress: control incoming traffic.
Egress: control outgoing traffic.

If a policy denies traffic, Pods cannot connect.

Using Kubectl to interact with Kubernetes

Now you’re familiar with the basics, you can start adding workloads to your cluster with Kubectl. Here’s a quick reference for some key commands.

List Pods
This displays the Pods in your cluster:

$ kubectl get pods
No resources found in default namespace

Specify a namespace with the -n or --namespace flag:

$ kubectl get pods -n demo
No resources found in demo namespace

Alternatively, get Pods from all your namespaces by specifying --all-namespaces:

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                      READY   STATUS      RESTARTS   AGE
kube-system   coredns-b96499967-4xdpg                   1/1     Running     0          114m

...
This includes Kubernetes system components.

Create a Pod
Create a Pod with the following command:

$ kubectl run nginx --image nginx:latest
pod/nginx created

This starts a Pod called nginx that will run the nginx:latest container image.

Create a Deployment
Creating a Deployment lets you scale multiple replicas of a container:

$ kubectl create deployment nginx --image nginx:latest --replicas 3
deployment.apps/nginx created

You’ll see three Pods are created, each running the nginx:latest image:

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7597c656c9-4qs55   1/1     Running   0          51s
nginx-7597c656c9-gdjl9   1/1     Running   0          51s
nginx-7597c656c9-7sxrc   1/1     Running   0          51s

Scale a Deployment
Now use this command to increase the replica count:

$ kubectl scale deployment nginx --replicas 5
deployment.apps/nginx scaled

Kubernetes has created two extra Pods to provide additional capacity:

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7597c656c9-4qs55   1/1     Running   0          2m26s
nginx-7597c656c9-gdjl9   1/1     Running   0          2m26s
nginx-7597c656c9-7sxrc   1/1     Running   0          2m26s
nginx-7597c656c9-kwm6q   1/1     Running   0          2s
nginx-7597c656c9-nwf2s   1/1     Running   0          2s

Expose a Service
Now let’s make this NGINX server accessible.

Run the following command to create a service that’s exposed on a port of the Node running the Pods:

$ kubectl expose deployment/nginx --port 80 --type NodePort
service/nginx exposed

Discover the port that’s been assigned by running this command:

$ kubectl get services
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.43.0.1      <none>        443/TCP        121m
nginx        NodePort    10.43.149.39   <none>        80:30226/TCP   3s

The port is 30226. Visiting :30226 in your browser will show the default NGINX landing page.

You can use localhost as if you’ve been following along with the single-node K3s cluster created in this tutorial.


$ kubectl get nodes -o wide
NAME       STATUS   ROLES                  AGE    VERSION        INTERNAL-IP
ubuntu22   Ready    control-plane,master   124m   v1.24.4+k3s1   192.168.122.210

Using port forwarding
You can access a service without binding it to a Node port by using Kubectl’s integrated port-forwarding functionality. Delete your first service and create a new one without the --type flag:

$ kubectl delete service nginx
service/nginx deleted

$ kubectl expose deployment/nginx –port 80
service/nginx exposed

This creates a ClusterIP service that can be accessed on an internal IP, within the cluster.

Retrieve the service’s details by running this command:

$ kubectl get services
NAME        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
nginx       ClusterIP   10.100.191.238   <none>     80/TCP  2s

The service can be accessed inside the cluster at 10.100.191.238:80.

You can reach this address from your local machine with the following command:

$ kubectl port-forward service/nginx 8080:80

Visiting localhost:8080 in your browser will display the NGINX landing page. Kubectl is redirecting traffic to the service inside your cluster. You can press Ctrl+C in your terminal to stop the port forwarding session when you’re done.

Port forwarding works without services too. You can directly connect to a Pod in your deployment with this command:

$ kubectl port-forward deployment/nginx 8080:80

Visiting localhost:8080 will again display the NGINX landing page, this time without going through a service.

Apply a YAML file
Finally, let’s see how to apply a declarative YAML file to your cluster. First, write a simple Kubernetes manifest for your Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest

Save this manifest to nginx.yaml and run kubectl apply to automatically create your Pod:

$ kubectl apply -f nginx.yaml
pod/nginx created

You can repeat the command after you modify the file to apply any changes to your cluster.

Now you’re familiar with the basics of using Kubectl to interact with Kubernetes!

🎯 Wrapping Up

Kubernetes is the leading container orchestrator, and in this blog we explored its features, understood how it works, and looked at the key components that power your applications. You now have the foundation to start experimenting and building with Kubernetes. 🚀

But this is just the beginning! In the upcoming blogs, we’ll dive into advanced Kubernetes topics — from real-world challenges and best practices to security, scaling, and hands-on deployments.

🙌 Stay tuned for the next part of the series where we’ll go beyond the basics and make Kubernetes work for you.

👉 Follow me here, or connect with me on LinkedIn and Twitter for updates, tips, and more developer content.

Kubernetes 101: Understanding the Basics, Features, and Architecture 🚀

Md Khurshid — Mon, 01 Sep 2025 20:15:19 +0000

☸️ What is Kubernetes?

Kubernetes (often called K8s)is an open-source platform that helps you automate the deployment and management of containers. It was first created by Google and is now maintained by the Cloud Native Computing Foundation (CNCF).

The reason Kubernetes has become so popular is because it solves many of the challenges that come with running containers in production. Instead of manually starting and managing containers, Kubernetes makes it possible to easily launch as many copies of your application as you need, spread them across multiple servers, and handle the networking so users can reliably access your services.

In this beginner’s guide, we’ll explore:
1. What Kubernetes is.
2. The main features it offers.
3. How it works behind the scenes.

What is Kubernetes Used For?

Kubernetes is designed to manage and scale applications running in containers. Containers are like small, isolated boxes that hold everything an app needs to run.

Now imagine you have hundreds of these containers running across multiple servers — it’s tough to manage them manually. Kubernetes makes this easy by automating the process.

Here’s what Kubernetes can do for you:

Start new apps automatically when needed.
Restart apps if they crash.
Distribute workloads so no server gets overloaded.
Scale apps up or down depending on demand.

In short: Kubernetes is like a system administrator that keeps your apps healthy and running smoothly, without you doing everything manually.

🤔 Is Kubernetes Easy to Learn?

Honestly… not at first 😅. Learning Kubernetes can be a bit challenging in the beginning. Why? Because it has many moving parts, and it’s built for running apps at scale.

Most developers first learn Docker, which helps run one container at a time. But Docker alone is low-level — you still have to manage containers manually. Kubernetes, on the other hand, provides high-level tools and abstractions so you can describe your apps in configuration files, and Kubernetes takes care of the rest.

So yes, the learning curve is steep at first. But once you understand the core concepts (like Pods, Nodes, and Deployments), things start to click.

✨ Kubernetes Features

Kubernetes is packed with features that make running containers easier and more reliable. Let’s go through the key ones:

1. Automated rollouts, scaling, and rollbacks

You can define how many copies (replicas) of your app should run.
Kubernetes automatically spreads them across servers.
If a server goes down, Kubernetes reschedules your containers.
You can scale apps up or down instantly, either manually or automatically (based on CPU, memory, or custom metrics).

2. Service discovery, load balancing, and ingress

Kubernetes handles internal communication between apps.
It can also expose your apps to the outside world.
Load balancers ensure traffic is spread across all available instances.

3. Supports both stateless and stateful apps

Initially, Kubernetes was focused on apps that don’t store data (stateless).
Now, it also supports apps that need persistent data (stateful), like databases.

4. Storage management

Kubernetes connects your containers to storage — whether it’s cloud storage, a network drive, or your local filesystem.

5. Declarative state management

You don’t have to manually tell Kubernetes what steps to take.
Instead, you write a YAML file describing the state you want (e.g., “I want 3 replicas of this app”).
Kubernetes then works to make the cluster match that state automatically.

6. Works across environments

Run Kubernetes locally on your laptop (using Minikube, Kind, or K3s).
Use it in the cloud (AWS, Google Cloud, Azure all provide managed Kubernetes).
Or even run it at the edge.

7. Highly extensible

Kubernetes has many built-in features, but you can extend it.
You can create custom objects, controllers, or operators to support your unique use cases.

With all these features, Kubernetes is suitable for almost any situation where you want to run containers reliably.

🛠 How Does Kubernetes Work?

Kubernetes often feels complex because it has many different parts working together. But once you understand the basics and how these pieces fit, getting started becomes much easier.

In Kubernetes, the whole setup is called a cluster. A cluster is made up of nodes, which are just machines that run your containers. These machines can be physical servers or virtual machines.

Every cluster has two main parts: the control plane and the nodes. The control plane is like the brain of the system — it manages the cluster, schedules new containers on the nodes, and provides the API server you use to interact with Kubernetes. To increase reliability, a cluster can also run with multiple control plane instances so it keeps working even if one fails.

Let’s look at the important components inside Kubernetes:

Component	Description
kube-apiserver	This is the part of the control plane that runs the API server. It’s the only way to interact with a running Kubernetes cluster. You can issue commands to the API server using the Kubectl CLI) or an HTTP client.
kube-controller-manager	The controller manager starts and runs Kubernetes’ built-in controllers. A controller is essentially an event loop that applies actions after changes in your cluster. They create, scale, and delete objects in response to events such as an API request or increased load.
kube-scheduler	The scheduler assigns new Pods (containers) onto the nodes in your cluster. It establishes which nodes can fulfill the Pod’s requirements, then selects the most optimal placement to maximize performance and reliability.
kubelet	Kubelet is a worker process that runs on each of your nodes. It maintains communication with the Kubernetes control plane to receive its instructions. Kubelet is responsible for pulling container images and starting containers in response to scheduling requests.
kube-proxy	Proxy is another component found on individual nodes. It configures the host’s networking system so traffic can reach the services in your cluster.

And then there’s kubectl — the command-line tool you’ll use to interact with Kubernetes. With it, you can deploy apps, check logs, scale workloads, and much more.

🎯 Wrapping Up
Kubernetes may seem complex, but once you understand the basics, it becomes an incredibly powerful tool for managing applications.

This was just the start! In the next part, we’ll go beyond theory and actually get hands-on with Kubernetes.

In the next part of this Kubernetes 102, we’ll dive into:

Installing and setting up Kubernetes step by step
Core concepts like Node, Pod, Namespace, ReplicaSet, and Deployment
Using kubectl to interact with your cluster

👉 Follow me here, or connect with me on LinkedIn and Twitter for updates, tips, and more developer content.

Breaking Into Open Source: My Transformative Journey with Microcks and LFX Mentorship

Md Khurshid — Tue, 03 Jun 2025 18:28:47 +0000

I’ve always been curious and passionate about open source. The concept fascinated me: people from any part of the world contributing to real-world projects, gaining hands-on, industry-level experience, and being mentored by the project maintainers themselves.

Thanks to Kunal Kushwaha and Harkirat Singh, from whom I learned a lot about open source, my interest only grew stronger. Kunal, a former LFX mentee, shared his journey and experiences—which truly resonated with me. I knew I wanted to be part of something like that.
Earlier, my academic workload didn’t leave me much time, but after my semester exams, I finally got the chance to explore the LFX Mentorship portal—where one project instantly caught my eye: CNCF - Microcks.

Why I Chose Microcks

What really made me choose Microcks was the friendly and supportive community—especially how active and helpful the mentors were on Discord.

Also, the project “Building Community-Driven Documentation for Deploying Microcks in Cloud Production Environments” felt like a great match for me. I already had some experience with AWS, GCP, and Docker, but I had never worked with Kubernetes before. This project seemed like the perfect chance to learn something new and in-demand—cloud-native deployments.

Getting Involved (Even Before Selection!)

I only discovered the project a week before the deadline—February 18, 2025—but I didn’t let that stop me. In just a few days, I:

Joined the Microcks Discord server
Got my first PR merged (a guide for installing hub.microcks.io locally)
Actively helped other contributors navigate the project setup — also got a PR merged in the CNCF Kubestellar project
Shared everything I learned on Twitter to help grow awareness

This shows that you don’t always have to contribute to the codebase to make an impact. You can get involved through documentation, stay active on Discord or Slack, and support the community in meaningful ways. I submitted cover letters and resume for the projects.

🎉 The Selection Day Surprise

I still remember staying up until 4 AM fixing broken links and polishing the docs. The next morning, I woke up and checked my email — and my heart skipped a beat.
“Congratulations! You were accepted to CNCF - Microcks: Community-Driven Docs for Deploying Microcks in Cloud Production.”
I read it twice to believe it. I was so happy and excited! I shared the news with my friends and couldn’t wait to get started.

🗓️ Mentorship Kickoff

The program officially started on March 3rd. During the onboarding, we had a CNCF-wide session hosted by Nate Waddington, Head of CNCF Mentorship & Documentation. He shared stories, set expectations, and made us all feel welcomed and excited.

Our first Microcks mentee meeting with Yacine Kheddache and Laurent Broudoux outlined the mentorship structure, expectations, and goals. I was assigned Yacine as my mentor for weekly 1-on-1 calls. These calls were essential in keeping my work focused, solving blockers quickly, and receiving continuous feedback.

We used a shared Google Doc to plan and track weekly goals and updates.

Three-Month Milestone — What I Accomplished

Month 1: Laying the Foundation

Organized documentation folders under installation/ to clearly separate guides for AWS, GCP, Azure, OVH, Oracle, and Scaleway.
Deployed an external Keycloak on GKE, integrated with Cloud SQL (PostgreSQL) using secure IAM roles and VPC peering. This setup followed GCP production best practices.
Integrated Google Firestore as a NoSQL backend, making the setup fully cloud-native and scalable.

Month 2: Strengthening Deployments

Enabled Kafka support in Microcks using Strimzi Operator, which simplified asynchronous protocol testing.
Implemented TLS certificates with cert-manager and Let's Encrypt, ensuring automatic HTTPS provisioning and enhanced security.
Wrote a comprehensive Troubleshooting Guide that addressed common errors in external Keycloak and MongoDB deployments—this helped reduce user onboarding friction.
Authored a Cloud-Agnostic Common Guidelines doc that outlined infrastructure patterns, IAM setups, database connections, and Helm configurations for different cloud providers.
Presented my work to the Microcks community, gathered feedback, and welcomed suggestions.

Month 3: Deep Dive into Azure (AKS)

Deployed Microcks on Azure Kubernetes Service (AKS).
Set up an external Keycloak backed by Azure Database for PostgreSQL.
Configured a managed MongoDB instance on AKS and connected it to Microcks.
Integrated Azure Active Directory (AAD) for secure AKS access and authentication.
Documented all the above in a detailed, step-by-step guide covering CLI commands, YAML manifests, and Helm chart values for real-world production setups.

Challenges Faced & How I Overcame Them

IAM Permissions on GCP
Setting up the right permissions for services like Cloud SQL, GKE, and Keycloak was tricky. I had to strike a balance between security and functionality, learning how to handle permission errors, scoped tokens, and workload identity.

Helm Chart Customization
The default Helm charts are built for internal Keycloak and MongoDB. I needed to override multiple values to use external services, which taught me a lot about Helm templating and real-world deployment tweaks.

Stateful Workloads in Kubernetes
Deploying databases like MongoDB or PostgreSQL required understanding persistent storage, stateful sets, and backup strategies—especially on AKS. I spent time digging into best practices to manage these safely.

Learning Kubernetes from Scratch
This was my first real dive into Kubernetes. Terms like pods, ingress, and config maps were confusing at first, but thanks to my mentor’s support and hands-on work, I picked it up step by step.

🙌 Wrapping Up

During this mentorship:

I got 11 PRs merged into the official Microcks documentation repo
Promoted Microcks and my contributions on social media, especially Twitter and LinkedIn, sharing deployment tips, learnings, and threads
Helped onboard new contributors by responding on Discord and pointing them to helpful docs and resources
Actively encouraged others to explore the LFX program and join the open-source community

Merged PR's

On June 12, during the final Microcks community meeting, we mentees, shared our experiences. It was a beautiful moment to reflect on our growth and conclude the mentorship with pride.

💬 Final Thoughts

This was my first open source contribution—and first time being part of a global mentorship program. The experience was transformative.

I'm deeply thankful to my mentors Yacine Kheddache and Laurent Broudoux for their support, technical guidance, and continuous encouragement. Without them, this journey wouldn’t have been the same.
Although the program has officially ended, my journey with Microcks continues—and I look forward to contributing more in the future.

If you’re thinking about applying for LFX—do it. You don’t have to be an expert. If you're passionate, willing to learn, and ready to contribute, the community will welcome you with open arms.
You can check out all my contributions on the Microcks repository, and I’m always happy to help anyone get started!

💙 Thanks for reading!
If you're passionate about open source and cloud-native technologies, the next LFX mentorship batch is a great chance to gain hands-on experience, collaborate with communities, and grow professionally.

Linkedin | Github
LFX’25 Mentee at Microcks

My Second Month as an LFX Mentee: Advancing Microcks Deployments

Md Khurshid — Sun, 11 May 2025 07:07:58 +0000

Hello everyone! It’s been another productive month in the LFX Mentorship program with the CNCF Microcks project. This month, I focused on enhancing Microcks deployments on Google Kubernetes Engine (GKE) and improving documentation for cloud-specific deployment strategies. Additionally, I had the opportunity to present my contributions during the community meeting, where I encouraged others to contribute, provide feedback, and review the documentation.

1. Deploying Microcks with Asynchronous Options on GKE

I worked on improving the Microcks GKE deployment by adding support for asynchronous protocols and securing the Microcks endpoint with TLS.

Enabled Kafka-based async protocols with Helm and installed Strimzi for Kafka management.
Secured the endpoint using cert-manager and Let's Encrypt for automatic SSL certificate provisioning.

2. Troubleshooting Guide for Microcks & Keycloak

Deploying complex systems like Microcks with external Keycloak and MongoDB can sometimes lead to roadblocks. To address this, I created a TROUBLESHOOTING.md file in the repository. This document provides a set of common issues and solutions that developers may encounter when deploying Microcks on GKE, especially when integrating with Keycloak for authentication and MongoDB for data storage.
Troubleshooting Guide

3. Creating Common Guidelines for Cloud Providers

I developed a GUIDELINES.md document that outlines the deployment process for Microcks across multiple cloud providers. The guidelines cover setting up infrastructure, deploying Keycloak, provisioning databases, and configuring Microcks with Helm.
Common Guidelines

🙌 Looking Ahead

Next month, I plan to:

Deploy Microcks on Azure AKS and document the process.
Add a Troubleshooting Guide for Azure deployment.

Conclusion

Month two has been an exciting journey, contributing to Microcks with improvements in deployment, security, and cloud-specific guidelines. I’m excited to continue supporting the Microcks community and look forward to the next steps!

Feel free to check out my contributions on the Microcks community repository - feedback and contributions are always welcome!

See you in the next update! 👋

My First Month as an LFX Mentee

Md Khurshid — Wed, 09 Apr 2025 07:10:19 +0000

About the CNCF Microcks Project

Microcks is a cloud-native tool for mocking and testing APIs (REST, SOAP, and more). As part of the LFX Mentorship program under CNCF, my project aims to build a centralized repository of real-world, production-grade deployment strategies for Microcks across various cloud platforms including AWS, GCP, Azure, OVH, Oracle and Scaleway. The goal is to help adopters confidently deploy Microcks in production environments by learning from shared experiences and expertise.

Understanding Microcks and Exploring Documentation

In the first week, most of my time was spent exploring Microcks documentation and understanding the internal architecture of Microcks. This foundational phase was essential to gain a solid grasp of the project and identify key areas for improvement. Understanding how MongoDB, Keycloak, and Kafka work within the Microcks ecosystem allowed me to dive into deployment options and optimize the setup for cloud environments.
Checkout Documentation

My Contributions

1. Organizing Cloud Deployments
One of my early contributions was creating a centralized folder structure under the installation/ directory of the documentation. This new structure categorizes deployment guides for each cloud provider, making it easy for users to find platform-specific instructions. Whether you're deploying on AWS, GCP, or Azure, everything is now neatly organized and easily accessible.
View folder structure

2. Deploying External Keycloak on GKE Using Google Cloud SQL
Microcks uses Keycloak for authentication, and I was tasked with setting up an external Keycloak instance on Google Kubernetes Engine (GKE). I integrated Cloud SQL (PostgreSQL) as the backend for Keycloak to provide a robust, scalable, production-ready authentication system.
The process involved setting up GCP authentication, service accounts, IAM roles, and VPC peering for secure connectivity between GKE and Cloud SQL. I used Helm to deploy Keycloak and configured DNS via nip.io to expose it securely. I documented the entire process to make it easier for others to follow.
External Keycloak on GKE guide

3. Deploying Microcks on GKE with External Keycloak
Once Keycloak was deployed, the next step was to deploy Microcks on GKE. Instead of using MongoDB, I connected Microcks to Firestore, Google Cloud's managed NoSQL database, to align with GCP-native services. I used Helm to deploy Microcks, integrated it with the external Keycloak for authentication, and configured it to use External MangoDB for data storage. This deployment setup ensures scalability and simplifies management, showcasing a production-grade configuration using GCP services. I also documented this deployment to guide others in setting up similar environments.
Microcks on GKE guide

Challenges Faced

Permission Configuration: One of the main hurdles was ensuring that the IAM user/service account had the correct permissions for deploying Microcks and related services on GKE. It was essential to grant the minimum required permissions for security and functionality, which required careful attention.

Overriding Helm Chart Values: Another challenge was customizing the Helm chart to integrate external Keycloak and Cloud SQL instead of Microcks’ default MongoDB and internal Keycloak. This required modifying the chart values and ensuring everything worked smoothly with the GCP-native services.

🙌 Looking Ahead

Deploy Microcks with asynchronous options on GKE
Add a Troubleshooting Guide for Microcks & Keycloak
Create comman GUIDELINES.md for all cloud providers

Conclusion

It's been an exciting first month contributing to the Microcks community, and I'm eager to continue helping develop cloud deployment strategies. My goal is to empower users to confidently deploy Microcks in various cloud environments using best practices. Feel free to check out my contributions on the Microcks community repository - feedback and contributions are always welcome!

That's all for my first month as an LFX Mentee. See you in the next update! 👋