<?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 Blog · Muhammad Fauzi Islami</title><link>https://fauzislami.github.io/tags/kubernetes/</link><description>Recent content in Kubernetes on Blog · Muhammad Fauzi Islami</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 27 Feb 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://fauzislami.github.io/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>K8S-thing: How Linux Namespace Plays a Role in Kubernetes</title><link>https://fauzislami.github.io/blog/k8s-thing-how-linux-namespace-Plays-a-role-in-Kubernetes/</link><pubDate>Mon, 27 Feb 2023 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/k8s-thing-how-linux-namespace-Plays-a-role-in-Kubernetes/</guid><description>&lt;h1 id="linux-network-namespace"&gt;Linux Network Namespace&lt;/h1&gt;
&lt;p&gt;Before we look into how Linux Network Namespace works in Kubernetes Pod, we need to know from the basic what it is and what the purpose of it. Network namespace in linux provides an isolated system resources associated with networking-related stuff within a single host such as IP (Internet Protocol) either it is IPv4 or IPv6, NAT rules, firewall rules, and routing table.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://fauzislami.github.io/images/k8s-thing-how-namespace-work-in-pod/host.png" alt="main picture" title="main picture"&gt;&lt;/p&gt;
&lt;p&gt;Let’s imagine you are a parent who have children and live in a house. Take the computer host as a house and namespaces are rooms within that house. You assign those rooms to each of your children. They have their own privacy, so each child can only see what’s within his or her room and they can’t see what happens outside their room. However, as a parent you have a visibility to all rooms in the house. If you wish, you can visit each room.&lt;/p&gt;</description></item><item><title>K8S-thing: How Linux Namespace Works in a Pod</title><link>https://fauzislami.github.io/blog/k8s-thing-how-linux-namespace-works-in-a-pod/</link><pubDate>Mon, 27 Feb 2023 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/k8s-thing-how-linux-namespace-works-in-a-pod/</guid><description>&lt;h1 id="linux-network-namespace"&gt;Linux Network Namespace&lt;/h1&gt;
&lt;p&gt;Before we look into how Linux Network Namespace works in Kubernetes Pod, we need to know from the basic what it is and what the purpose of it. Network namespace in linux provides an isolated system resources associated with networking-related stuff within a single host such as IP (Internet Protocol) either it is IPv4 or IPv6, NAT rules, firewall rules, and routing table.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://fauzislami.github.io/images/k8s-thing-how-namespace-work-in-pod/host.png" alt="main picture" title="main picture"&gt;&lt;/p&gt;
&lt;p&gt;Let’s imagine you are a parent who have children and live in a house. Take the computer host as a house and namespaces are rooms within that house. You assign those rooms to each of your children. They have their own privacy, so each child can only see what’s within his or her room and they can’t see what happens outside their room. However, as a parent you have a visibility to all rooms in the house. If you wish, you can visit each room.&lt;/p&gt;</description></item><item><title>FluxCD: Image Watcher</title><link>https://fauzislami.github.io/blog/flux-image-watcher/</link><pubDate>Wed, 01 Feb 2023 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/flux-image-watcher/</guid><description>&lt;p&gt;This time I want to bring up a cool GitOps tool beside ArgoCD named &lt;a href="https://fluxcd.io/"&gt;&lt;strong&gt;FluxCD&lt;/strong&gt;&lt;/a&gt;. But I won’t discuss about what it is and the comparison between ArgoCD and FluxCD just yet. Instead, I find FluxCD has a cool feature of many features it provides which I don’t find this in ArgoCD (at least as the time as I write this topic). Probably, the introduction topic of FluxCD itself is worth having later on and it’s generally similar to ArgoCD as both work in the same area for Continous Deployment. But yet again, now let’s have a go with one of its sophisticated feature 😄&lt;/p&gt;</description></item><item><title>FluxCD: Image Watcher</title><link>https://fauzislami.github.io/blog/fluxcd-image-watcher/</link><pubDate>Wed, 01 Feb 2023 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/fluxcd-image-watcher/</guid><description>&lt;p&gt;This time I want to bring up a cool GitOps tool beside ArgoCD named &lt;a href="https://fluxcd.io/"&gt;&lt;strong&gt;FluxCD&lt;/strong&gt;&lt;/a&gt;. But I won’t discuss about what it is and the comparison between ArgoCD and FluxCD just yet. Instead, I find FluxCD has a cool feature of many features it provides which I don’t find this in ArgoCD (at least as the time as I write this topic). Probably, the introduction topic of FluxCD itself is worth having later on and it’s generally similar to ArgoCD as both work in the same area for Continuous Deployment. But yet again, now let’s have a go with one of its sophisticated feature 😄&lt;/p&gt;</description></item><item><title>Distribute Pods Across Nodes With topologySpreadConstraints</title><link>https://fauzislami.github.io/blog/pod-topology-spread-constraints/</link><pubDate>Tue, 01 Nov 2022 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/pod-topology-spread-constraints/</guid><description>&lt;p&gt;&lt;img src="https://fauzislami.github.io/images/podTopologySpreadConstraints/main.png" alt="main picture" title="main picture"&gt;&lt;/p&gt;
&lt;h1 id="intro"&gt;Intro&lt;/h1&gt;
&lt;p&gt;I had several works related to evenly spreading out pods across nodes in order to prevent potentially Kubernetes schedule the replicas of pods on the same node which will lead to a problem if that particular node falls over. I comprehended the case because there are some ways to schedule pods and the solution must be suitable to the environment in my case. As we might already know, Kubernetes has its own built-in mechanism to schedule a pod into a node named &lt;strong&gt;scheduler&lt;/strong&gt;. But Kubernetes gives us flexibility on how and where a pod is scheduled on which node, it depends on our needs. Let’s take an example such as &lt;strong&gt;taints &amp;amp; tolerations&lt;/strong&gt;, &lt;strong&gt;nodeSelector&lt;/strong&gt;, and even a more advanced way like &lt;strong&gt;podAntiAffinity&lt;/strong&gt;. Basically, it allows us to dictate the scheduler on where pods should be put on.&lt;/p&gt;</description></item><item><title>Securing K8S Secret Object Using SealedSecret</title><link>https://fauzislami.github.io/blog/2021/09/26/secure-k8s-secret-object-using-sealedsecret/</link><pubDate>Sun, 26 Sep 2021 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/2021/09/26/secure-k8s-secret-object-using-sealedsecret/</guid><description>&lt;p&gt;&lt;img src="https://fauzislami.github.io/images/sealed-secret/1.png" alt="Scratchpad" title="Scratchpad"&gt;&lt;/p&gt;
&lt;p&gt;Managing kubernetes manifest on Git or any other SCM is a common task nowadays. It makes life easier if we talk about continuous deployment. However, there is a manifest that should not be stored on SCM, it’s secret object. Secret object on Kubernetes was made to hide any sensitive data including user credentials and key. Unfortunately, secret object is not completely secure, it does not encrypt but only uses base64 encoding scheme to hide the data and it can be easily decoded. Therefore, Sealed Secret is one of the solution to make the secret more secure and can be securely stored on SCM.&lt;/p&gt;</description></item><item><title>Service Mesh : Istio and Kiali Setup</title><link>https://fauzislami.github.io/blog/2021/08/01/service-mesh-istio-and-kiali-setup/</link><pubDate>Sun, 01 Aug 2021 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/2021/08/01/service-mesh-istio-and-kiali-setup/</guid><description>&lt;p&gt;&lt;img src="https://fauzislami.github.io/images/service-mesh-istio-kiali-setup/1.png" alt="Scratchpad" title="Scratchpad"&gt;&lt;/p&gt;
&lt;p&gt;It’s the first time for me to learn what service mesh is, how it works, and how to start the lab to deep dive on this stuff. In this article, there will be some of my notes about how to install Istio and see the visualization of some microservices that will have been monitored by Istio and I’m going to write it up now.&lt;/p&gt;
&lt;p&gt;As usual, it would be better if we have good comprehension on what we’re going to learn.&lt;/p&gt;</description></item><item><title>Automating K8S Cluster Installation with Kubespray</title><link>https://fauzislami.github.io/blog/2021/01/18/automating-k8s-cluster-installation-with-kubespray/</link><pubDate>Mon, 18 Jan 2021 00:00:00 +0000</pubDate><guid>https://fauzislami.github.io/blog/2021/01/18/automating-k8s-cluster-installation-with-kubespray/</guid><description>&lt;p&gt;&lt;img src="https://fauzislami.github.io/images/automating-k8s-cluster-kubespray/pic-1.png" alt="kubespray" title="kubespray"&gt;&lt;/p&gt;
&lt;p&gt;There are various ways to perform a kubernetes installation. If you look at the environment in which kubernetes will be installed on, you have options that can be done, namely:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Learning purposes :&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;em&gt;Kind&lt;/em&gt; tools ( Kubernetes In Docker )&lt;/li&gt;
&lt;li&gt;&lt;em&gt;Minikube&lt;/em&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Production purposes :&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Bootstrapping K8S with &lt;em&gt;kubeadm&lt;/em&gt;&lt;/li&gt;
&lt;li&gt;Installing K8S with &lt;em&gt;kubespray&lt;/em&gt;&lt;/li&gt;
&lt;li&gt;Installing K8S with &lt;em&gt;kops&lt;/em&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In this opportunity, I will do the installation of a kubernetes cluster using kubespray. Kubespray itself is a way to install Kubernetes cluster by automating it using ansible playbook.&lt;/p&gt;</description></item></channel></rss>