July 5th, 2019 | by Dawid Marniok

Kubernetes and Istio | Cloud Developer Days 2019

Table of contents

    As you can imagine, everything that has ‘cloud’ in it, is a hot topic among IT professionals. It’s 34C (about 93F) when I write this and no cloud as the eye can see. Unlike the weather outside, Cloud Developer Days 2019 brought us a lot of information and shared experiences about popular tools we use in our daily work. Unlike outside, it was raining. Knowledge, that is.

    Kubernetes and Istio – ServiceMesh

    I would like to focus on Kubernetes and Istio – ServiceMesh. I assume that most of you know what Kubernetes is. For those of you who are not familiar with it, I attached a short definition from official documentation below.

    Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications.

    CSHARK
    CSHARK

    This technology becomes more popular and this is standard for application based on microservices. K8s is flexible and reliable. It has a lot of features which ensures safety and proper operations. We don’t have to know exactly how the Kubernetes works because we can create a cluster by using popular public cloud providers. Currently, the largest public cloud providers (Azure, AWS, GCP) implement K8s as service in their offers. This doesn’t mean that developers shouldn’t know even few Kubernetes’ basic objects. We can define many objects that are useful during deployment application. I’m presenting basic features from the developer’s side, the whole list would take many lines of text. Sorry, after writing advanced code for 8 hours straight any more lines would cause overload, especially under these weather conditions 😉

    • Pod. Kubernetes wraps one or more containers into a high-level structure called a Pod. Containers in a pod can share the same resources and local network. Pods can be replicate if your application has a problem with performance. K8s can run multiple containers in one Pod, but there should be established limit because Pods should be easy scaled during failure.
    • Deployments. It’s a layer of abstraction which is responsible for the which is responsible to create a plan of deployment application. We can declare how many replicas of Pods should be running. K8s will create new instance Pod after failure – automatically. We have the possibility to set health-check for check statuses for our services. Additionally, we can declare persistent volumes, expose ports and a lot more.
    • Services. This is an abstraction which defines a logical set of Pods and a policy on how to access them. We have the possibility to choose a few kinds of services, like: ClusterIP(default), NodePort, LoadBalancer, ExternalName, etc. There are very important things during projecting applications.
    • Ingress. Using the objects described above, we can launch the application on K8s cluster. There is one problem with allowing external traffic to your application. By default, K8s has blocked the connection between pods and the outside world. However, we can configure additional object like Ingress. There are multiple ways to configure Ingress to your K8s cluster, but the most common option is LoadBalancer.

    We have a way to define a lot of additional objects in K8s, like: Secrets, ConfigMaps, Jobs but using abovementioned will allow you to start simple application on K8s cluster.

    However, the challenges during projecting application are more and more complex and K8s can’t resolve all of them. One of these tools is Istio – service mesh, the official definition below:

    CSHARK
    CSHARK

    Istio – At a high level, Istio helps reduce the complexity of these deployments, and eases the strain on your development teams. It is a completely open source service mesh that layers transparently onto existing distributed applications.

    This open-source project also becomes very popular. Currently, Istio has been developed even by Google and IBM. In the near future, Istio will be available as a service in Google Cloud Public (GCP).

    A service mesh provides traffic monitoring, access control, discovery, security, resiliency, and other useful things to a group of services. Below you’ll find a list with the most important challenges during projecting application based on microservices. Istio is able to solve most of them:

    Connectivity

    • Traffic management
    • A-B testing
    • Content-based traffic steering
    • Incomig and outcoming traffic
    • Failure handling
    • Fault injection for E2E testing

    Security

    • ‘Man-in-the-middle’ attacks
    • Traffic encryption
    • Mutual TLS
    • Access polices
    • Audits

    Observability

    • Telemetry
    • Logs
    • Service graph
    • Traces

    Istio is a complex tool and I won’t describe the whole infrastructure. That’s why I will focus on basic. Below you can see basic architecture. You can find more information on the project’s website.

    CSHARK
    CSHARK

    Istio works as a service mesh by providing two basic pieces of architecture for your cluster, a data plane, and a control plane. All network traffic based on Istio proxy (Envoy). Envoy is implemented as a “sidecar” in all pods in K8s cluster. Control Plane (Mixer, Pilot, Citadel) is responsible for whole management. Below you can find a short description of Istio Components:

    • Envoys – high-performance proxy which mediate all inbound and outbound traffic for all services
    • Mixer – enforces access control and policies across the service mesh and collects telemetry
    • Pilot – service discovery for Envoys, traffic management capabilities for intelligent routing
    • Citadel – provides serivce-to-serivce authentication with identity and credential management, handless certificates
    • Galley – configs for Istio

    There are a lot of features and I won’t fully describe each of them. As a starting point, network traffic management which we can use a lot of interesting functions. Another one – Security which we can set TLS certificates or we can secure application before man-in-the-middle attacks. Is also worth to mention, that tools for monitoring are very helpful – possible to collect logs and trace traffic.

    Below I would like to focus on one of the very interesting features – Traffic Management.

    CSHARK
    CSHARK

    Traffic management gives us the possibility to use a few interesting functions: Request Routing, Fault Injection, Traffic Shifting, Mirroring, Request Timeouts, Ingress, Egress, etc. Above we see examples for using TrafficShifting. It’s a very useful and important option. We can set intelligent routing between our services. We can deploy “Canary version” our service by using this feature. These are irreplaceable tests because they can be run on the production environment. Additionally, there are possibilities for routing traffic by using specific users e.g. Android or iPhone user. Istio is a big tool and I mentioned only some of the features. I encourage you to read the Istio documentation where you can find great examples with Sample App for testing.

    Kubernetes and Istio are very popular and valuable tools, and they appear very often at the Cloud Developer Days conference. More interestingly, Istio is implemented in our MAKO platform for rapid software development. This is another direct proof that we have secure and modern solutions for startups and big companies alike.

    Graphics credits: Kubernetes.io, Istio.io

    Our first post about Cloud Developer Days 2019: Cloud Developer Days 2019 – A Lot To Benefit ‘Street Smart’

    Our second post about Cloud Developer Days 2019: Cloud Developer Days 2019 – An Automation Tool for Azure

    Dawid Marniok

    Head of DevOps

    A DevOps Engineer at CSHARK. With experience in containers, public cloud and middleware technologies. Responsible for the design and development of the CD/CI area. Interested in new open-source technologies and IoT.