<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes on Nandaja.</title><link>https://nandaja.com/tags/kubernetes/</link><description>Recent content in Kubernetes on Nandaja.</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sat, 17 Apr 2021 19:58:42 +0530</lastBuildDate><atom:link href="https://nandaja.com/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Using KubeIP to have static IP in GKE</title><link>https://nandaja.com/post/2021-04-17-using-kubeip-to-have-statis-ips-in-a-kubernetes-cluster/</link><pubDate>Sat, 17 Apr 2021 19:58:42 +0530</pubDate><guid>https://nandaja.com/post/2021-04-17-using-kubeip-to-have-statis-ips-in-a-kubernetes-cluster/</guid><description>&lt;p>This is a small rant about a library I discovered some time ago at work to use
with our Kubernetes cluster manged by Google Cloud. The library is called &lt;a href="https://kubeip.com/" title="Kube IP">&lt;em>Kube
IP&lt;/em>&lt;/a> and I absolutely love it!&lt;/p>
&lt;h2 id="infrastructure-on-aws">Infrastructure on AWS&lt;/h2>
&lt;p>At my current work(which I will be leaving in 2 weeks to be exact), I started
maintaining a cloud managed Kubernetes cluster(GKE) some 6 months ago. Kubenetes
felt like the right kind of tool for our infrastructure needs and so far it has
been a really thrilling experience. Before this we used to use AWS exclusively
and used to have containarized apps deployed in separate EC2 instances. This
turned out slightly more expensive and resulted in a lot of resource waste. All
of these machines were inside a public subnet in a VPC. We had a big PostgreSQL
database to which all of the aforementioned apps communicated with. The design
decision I took was to use AWS RDS for the database server and keep it in a
private subnet under the same VPC. I added inbound rules on the security group
to allow connections to the EC2 instances in the VPC.&lt;/p>
&lt;h2 id="kubernetes-migrationalso-aws-to-gcp-migration">Kubernetes migration(also AWS to GCP migration)&lt;/h2>
&lt;p>Once I decided to move all the above containerized apps to Kubernetes(which was
a long process), the next design choice was to decide what to do about the
database. Migrating the database to Cloud SQL(the managed database service of
GCP) felt like a lot of work especially since we were majorly short staffed. Instead I decided
to keep the DB over at AWS. Opening the DB to the Internet so the K8s cluster
can communicate with it felt like a death wish. So instead I decided to keep it
private and whitelist the IP addresses of the Source IP of the requests from the
Kubernetes Cluster. I expose each deployment on the cluster with a ClusterIP
Service type and used an nginx-ingress controller to open up the services to the
Internet.&lt;/p>
&lt;h3 id="the-sad-story-of-ephemeral-node-ips">The sad story of ephemeral node IPs&lt;/h3>
&lt;p>I noticed that the Source IP of the requests from the pod was
the IP address of the node it was deployed in. My mind went -
&amp;ldquo;Easy! Just whitelist those IPs!&amp;rdquo;. Oh boy, was I wrong! I understood that the IP
addresses of the nodes kept changing since they were ephemeral in nature. I
thought that the best way to solve this problem was to reserve static IPs for the
nodes in the cluster. I painfully realized that the nodes of the cluster kept
changing(auto-scaling,etc. like it should), along which changes the IP address.
A lot of looking up time later I found this wonderful library called &lt;em>Kube IP&lt;/em>.&lt;/p>
&lt;h3 id="kube-ip-to-the-rescue">Kube IP to the rescue&lt;/h3>
&lt;p>The idea was quite simple. I deploy KubeIP in a separate nodepool in the
cluster, and configure it to monitor another nodepool which I expect to have
staic IP addresses. I have to reserve n-number of static IP addresses first on
Google Cloud and give them a label that I configure KubeIP with. KubeIP pod will
monitor for any event on the Kubernetes API that signals a removal or addition of
nodes to the nodepool it is monitoring. Once it records am addition to the
nodepool, it forces the node to have an IP address from the reserved static IP
list which is not used by any of the nodes. So far this has been working out
great for me.&lt;/p>
&lt;p>One thing that was kind of going wrong for me at the beginning was that the pods
gets scheduled in the KubeIP nodepool (I guess this was my lack of understanding
of kubernetes). The way I solved it was I tainted the nodes in the
KubeIP node pool with a NoExecute taint accompanied with a specific Key Value. I made
the KubeIP pod tolerant to this taint value and everything worked smoothly. The
documentation for &lt;a href="https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/">taints and
tolerations&lt;/a>
is very descriptive.&lt;/p>
&lt;p>The documentaion of KubeIP tool is very well done and I am starting to look into
the codebase of the tool. I am counting this as part of my Go explorations. I
will document how my first impression of reading Go code was in another post. I
know that I have so much more to learn about Kubernetes and may be there is a
better/cleaner/cheaper way to deal with the problem I was having. I hope to keep
learning a bit each day. But in the meantime, here is to small victories! :-)&lt;/p>
&lt;p>Fin.&lt;/p></description></item></channel></rss>