Application Access in Kubernetes


Kubernetes Networking
In Kubernetes, networking happens at different levels:

    • Between containers: implemented as IPC
    • Between Pods: implemented by network plugins
    • Between Pods and Services: implemented by Service resources
    • Between external users and Services: implemented by Services, with the help of Ingress

Network Plugins

  • Network plugins are required to implement network traffic between Pods
  • Network plugins are provided by the Kubernetes Ecosystem
  • Vanilla Kubernetes does not come with a default network plugin, and you’ll have to install it while installing a cluster
  • Different plugins provide different features
  • Currently, the Calico plugin is commonly used because of its support for features like NetworkPolicy


  • Service resources are used to provide access to Pods
  • If multiple Pods are used as Service endpoint, the Service will load balance traffic to the Pods
  • Different types of Service can be configured:
    • ClusterIP: the Service is internally exposed and is reachable only from within the cluster
    • NodePort: the Service is exposed at each node’s IP address as a port. The
      Service can be reached from outside the cluster at nodeip:nodeport
    • LoadBalancer: the cloud provider offers a load balancer that routes traffic to
      either NodePort- or ClusterIP-based Services
    • ExternalName: the Service is mapped to an external name that is implemented as a DNS CNAME record

Configuring Services

  • Use kubectl expose to expose applications through their Pods, ReplicaSet or Deployment (recommended)
  • Use kubectl create service as an alternative

Demo: Creating Services

  • kubectl create deploy webshop --image=nginx --replicas=3
  • kubectl get pods --selector app=webshop -o wide
  • kubectl expose deploy webshop --type NodePort --port=80
  • kubectl describe svc webshop
  • kubectl get svc
  • curl nodeip:nodeport

Let’s demonstrate creating services:



  • Ingress is an API object that manages external access to services in a cluster
  • Ingress works with external DNS to provide URL-based access to Kubernetes applications
  • Ingress consists of two parts
    • A load balancer available on the external network
    • An API resource that contacts the Service resources to find out about available back-end Pods
  • Ingress load balancers are provided by the Kubernetes ecosystem, different load balancers are available
  • Ingress exposes HTTP and HTTPS routes from outside the cluster to Services within the cluster
  • Ingress uses the selectorlabel in Services to connect to the Pod endpoints
  • Traffic routing is controlled by rules defined on the Ingress resource
  • Ingress can be configured to do the following, according to functionality
    provided by the load balancer

    • Give Services externally-reachable URLs
    • Load balance traffic
    • Terminate SSL/TLS
    • Offer name based virtual hosting
      based virtual hosting.


Installing the Nginx Ingress Controller

  • helm upgrade --install ingress-nginx ingress-nginx --repo --namespace ingress-nginx --create-namespace
  • kubectl get pods -n ingress-nginx
  • kubectl create deploy nginxsvc --image=nginx --port=80
  • kubectl expose deploy nginxsvc

Before we can use the ingress we must ensure that ingress controler is installed. In minikube there is no ingress controller so we must install it using helm.


Installing the Nginx Ingress Controller – part 2

  • kubectl create ingress nginxsvc --class=nginx*=nginxsvc:80
  • kubectl port-forward -n ingress-nginx svc/ingress-nginx-controller 8080:80 & (run in background)
  • Fake DNS (in the real world it won’t be necessary because there were be DNS server.): echo "" >> /etc/hosts
  • curl

Now, let’s edit ngninx svc

and disturb the selector label

We see that the service is unavailable now:

So, if you have ever problem in ingress you might have investigate what is going on in the service to fix your problem.

Managing Ingress Rules

  • ingress rules catch incoming traffic that matches a specific path and optional hostname and connects that to a Service and port
  • Use kubectl create ingress to create rules
  • Different paths can be defined on the same host
    • kubectl create ingress mygress --rule="/mygress=mygress:80" --rule="yourgress=yourgress:80"
  • Different virtual hosts can be defined in the same Ingress
    • kubectl create ingress nginxsvc --class=nginx*=nginxsvc:80*=otherserver:80


  • In one cluster, different Ingress controllers can be hosted, each with its own
  • Controllers can be included in an IngressClass
  • While defining Ingress rules, the --class option should be used to implement the role on a specific Ingress controller
    • If this option is not used, a default IngressClass must be defined
    • Set true as an annotation on the IngressClass to make it the default
  • After creating the Ingress controller as described before, an IngressClass API resource has been created
  • Use kubectl get ingressclass -o yaml to investigate its content


Configuring Ingress Rules

  • kubectl get deployment
  • kubectl get svc webshop
  • kubectl create ingress webshop-ingress --rule="/=webshop:80" --rule="/hello=newdep:8080"
  • sudo vim /etc/hosts
  • kubectl get ingress
  • kubectl describe ingress webshop-ingress

As we see the endpoint “newdep” not fount and we must fix it:

Configuring Ingress Rules  – part 2

  • kubectl create deployment newdep
  • kubectl expose deployment newdep --port=8080
  • kubectl describe ingress webshop-ingress

Now everything works. Thats how you can use rules.

Lots of useful creating ingress examples you can see when you type:

Using Port Forwarding

  • kubectl port-forward can be used to connect to applications for analyzing and troubleshooting
  • It forwards traffic coming in to a local port on the kubectl client machine to a port that is available in a Pod
  • Using port forwarding allows you to test application access without the need to configure Services and Ingress
  • Use kubectl port-forward mypod 1235:80 to forward local port 1235 to Pod port 80
  • To run in the background, use Ctrl-z or start with a & at the end of the kubectl port-forward command

It was a siple example of port-forwarding.


Lab: Managing Networking

  • Run a deployment with the name apples, using 3 replicas and the Nginx image
  • Expose this deployment in such a way that it is accessible on my.fruit
  • Use port fowarding to test

We get Welcome to nginx because we do have a default ingressClass. If you don’t have a default IngressClass this doesn’t work.