Services running in Kubernetes are not accessible on a public or private cloud. This is how Kubernetes is designed considering service security in mind.

Securely allowing access to a service outside the cluster requires some understanding of how networking is setup and the different requirements driving the networking choices.

We briefly start by exploring what is expected from a Kubernetes cluster when it comes to service isolation, service scaling, and service delivery. Once the high-level requirements are laid out, it is easier to understand the significance of different constructs and abstractions.

We conclude by contrasting the advantages of using and Ingress to run a layer of L7 policy (or proxies) in front of a service running inside Kubernetes.

Understanding the scheme of Kubernetes Networking

Understanding Kubernetes Ingress is key to running microservices and securely accessing those services. This article is an attempt to demystify how Kubernetes networking is setup.

We look at networking when a service is created, the different Kubernetes artifacts created, the networking machinery required to meet different requirements.

We also describe the significance of different types of IPs like External-IP, Node-IP, Cluster-IP, Pod-IP and describe how traffic passes through each one of them.

Starting with cluster networking requirements provides us an opportunity of why networking is setup the way it is.

#cloud #kubernetes #api