Last couple of days I was playing with Istio and I couldn’t find a working upto date tutorial that can teach me how to run a basic hello world application with Istio in Kubernetes.
Istio is an open source service mesh that provides a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies, and aggregate telemetry data.
In this quick tutorial you will learn how to install Istio on Minikube and then deploy a helloworld sample application on it.
Recently I discovered an interesting project called Kata Containers. It is an open source project hosted by OpenStack foundation. Kata Containers is the merger of Hyper.sh runV and Intel’s Clear Containers.
Kata Containers provide the isolations guarantee of a virtual machine and speed and ease of use of containers. As shown in the image below, virtual machines in the top left provide the strictest form of isolation but they are slow to boot up and their size on disk range from 500MB to GBs. On the other hand, containers in the bottom right are fast and nimble but they don’t provide the strictest form of isolation. Kata Containers are best of both worlds. They provide the speed of containers and security and isolation guarantees of virtual machine.
Containers face shared kernel problem, where if on a single host you have multiple containers, if one of those containers gets exploited, you can potentially have access to all the other containers on that host.
Kata Containers are highly optimised virtual machines that run the end user application in a container. So in essence, there is a one-to-one mapping between container and virtual machine as shown below. These virtual machines are lightweight and optimised so you don’t pay the huge cost of running traditional virtual Machines.
The main difference between containers and kata containers is that containers rely on software virtualisation provided by kernel where as Kata containers rely on hardware virtualisation. Containers for different workloads share the same OS kernel which leads to security and privacy concerns. Kata Containers are addressing this need of securely running disparate workloads. They are fast to boot as the virtual machines use a trimmed down version of OS that’s only responsible for booting the VM and handling over the control to the container.
Kata containers are OCI compatible runtime which means you can use them with container orchestration platforms like Kubernetes. The below image shows how Kata Containers will work with Kubernetes.
Today, I faced a requirement where a running container need to access Pod’s metadata. For my usecase, the running container need to know the namespace it belonged to. After spending time on Google, I learnt about Kubernetes Downward API that exposes Pod information to running container in the form of environment variables.
Continue reading “Kubernetes Tip: How to access Pod metadata in containers running inside the pod?”
This is the guide I wish I had when I was starting my Kubernetes journey. Kubernetes is a complex technology with many new concepts that takes time to get your head around. In this guide, we will take an incremental approach to deploying applications on Kubernetes. We will cover what and why of Kubernetes and then we will learn how to deploy a real-world application on Kubernetes. We will first run application locally, then using Docker containers, and finally on Kubernetes. The guide will also cover Kubernetes architecture and important Kubernetes concepts like Pods, Services, Deployment.
In this guide, we will cover following topics:
Kubernetes is a platform for managing application containers across multiple hosts. It abstracts away the underlying hardware infrastructure and acts as a distributed operating system for your cluster.
Kubernetes is a greek for Helmsman or Pilot (the person holding the ship’s steering wheels)
Kubernetes play three important roles:
I learnt about the three roles – Referee, Illusionist, and Glue from the book Operating Systems Principles and Practices by Thomas Anderson and Michael Dahlin
In Kubernetes, one way to pass configurable data to containers is using environment variable. Below is a pod definition that uses two environment variables.
apiVersion: v1
kind: Pod
metadata:
name: api
spec:
containers:
- image: com.shekhargulati/api
name: api
env:
- name: DATABASE_NAME
value: "mydb"
- name: DATASOURCE_URL
value: jdbc:mysql://mysql:3306/mydb
ports:
- containerPort: 8080
As you can see in the above Pod definition, we are using database name mydb twice. Isn’t it will be awesome if we can use DATABASE_NAME in the DATASOURCE_URL?
Kubernetes supports this use case by providing $(VAR) syntax as shown below.
apiVersion: v1
kind: Pod
metadata:
name: api
spec:
containers:
- image: com.shekhargulati/api
name: api
env:
- name: DATABASE_NAME
value: "mydb"
- name: DATASOURCE_URL
value: "jdbc:mysql://mysql:3306/$(DATABASE_NAME)"
ports:
- containerPort: 8080
Ambassador is three things:
It builds on top of strong shoulders of Envoy proxy.
Continue reading “The 2 minute guide to running Ambassador on Minikube”
Shekhar Gulati 