Kiwi.com Summer Camp from a Cloud Platform Perspective

6 min readAug 1, 2019

In July 2019, I have been 1 of the 26 lucky attendees for Kiwi.com Summer Camp in Barcelona. Looking back, the event provided an insightful overview of Kiwi.com’s infrastructure and operational tools. As a cloud platform engineer, I found this event crucial for widening my scope and expertise in cloud platform technologies.

Throughout the week, it was exciting to work closely with the developer teams, while enabling the deployment of gRPC based applications onto the Kubernetes clusters and deep-diving into service mesh tools. In this blog post, I would like to give an overview of my experience at Kiwi.com summer camp and share the top takeaways from a cloud platform standpoint.

About the Summer Camp

The summer camp is a one-week long event, that offers a choice of 3 different technical tracks: frontend, backend and cloud. Attendees were assigned to a specific track based on the technical challenge they solved prior to the event. For example, the cloud challenge was composed of multiple tasks:

Create a Python, Node or JavaScript application, with a health check endpoint
Push the dockerized version of the application to a public image registry (e.g. Docker Hub)
Create a GKE cluster using Terraform
Deploy the application to the cluster, while using liveness and readiness probes and services to expose the application to external traffic

After a meticulous introduction of the Kiwi.com stack from the mentors, attendees would form a cross skilled team targeting to build microservice-based applications. Development teams used Python and GraphQL for the project implementation, while the infrastructure team provisioned the Kubernetes clusters in GCP (Google Cloud Platform).

The Cloud Platform Track

The focal point of the cloud track was to enable development initiatives from an infrastructure spectrum. This includes the provisioning of Gitlab CI pipelines and Kubernetes manifests using Kustomize, in addition to the usage of service mesh tools such as Istio and Linkerd. We have explored advanced features of the GKE clusters and the benefits of adopting a managed Kubernetes solution.

Kubernetes Clusters and Service Mesh

Overall, throughout the summer camp, the infrastructure team deployed two GKE clusters, one with Istio and one with Linkerd service mesh. Every development team would be allocated with a namespace in each cluster for the application deployment.

The usage of service mesh tools was eminent for all summer camp projects that use gRPC. Load balancing of gRPC requests is not supported natively in Kubernetes, hence it is required to use a lightweight proxy to send the gRPC requests to all available pods (for more details see this blog post ). Both Istio and Linkerd offer a service sidecar that would watch the Kubernetes API, open HTTP/2 connection to each pod and load balance all incoming requests using the open connections.

Note: In the subsequent sections I will refer to the Kubernetes clusters having Istio configured as a service mesh.

Traffic Routing

With Istio, traffic routing can be managed by utilizing virtual services. Virtual services are a set of rules that will instruct Envoy proxies to route the traffic to a specified service. This is configurable with routing rules that define the journey of HTTP and TCP requests entering the mesh. However, to allow the traffic to/from the mesh a gateway must be configured in combination with a virtual service.

For example, we configured any requests for https://nomad.summer.cloudweekend.kiwi/ to be redirected to the frontend servicenomad.nomad.svc.cluster.local through the gateway.istio-system.svc.cluster.localgateway. Using YAML, the virtual service and gateway can be configured as follows:

# virtual service configuration
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nomad
spec:
  hosts:
  - nomad.summer.cloudweekend.kiwi
  gateways:
  - gateway.istio-system.svc.cluster.local
  http:
  - route:
    - destination:
        host: nomad.nomad.svc.cluster.local---
# where the gateway is configured to expose traffic on port 80 (http) and 443 (https)apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway
  namespace: istio-system
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - hosts:
    - '*.summer.cloudweekend.kiwi'
    port:
      name: http-80
      number: 80
      protocol: HTTP
    tls:
      httpsRedirect: true
  - hosts:
    - '*.summer.cloudweekend.kiwi'
    port:
      name: https-443
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      privateKey: /etc/istio/ingressgateway-certs/tls.key
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt

Service Mesh Visualization and Metrics

To visualize the Istio service mesh we used Kiali. It is a great tool for graphical representation of the services within a cluster and the inter-connection between available services. For example, Nomad, the application that my team developed, is composed of 4 different microservices (2 gRPC services, 1 HTTP server and a frontend service). With Kiali it is easy to visualize that the HTTP service will intercept all the requests and forward them to one of the gRPC servers.

Service mesh visualisation for Nomad application

Moreover, with Istio service mesh, service entries can be configured. These are added to the internal service registry and are needed for traffic routing externally. In the above use case, 3 service entries are available: api.sygictravelapi.com, api.predicthq.com and api.skypicker.com.

Additionally, Kiali offers a predefined metrics dashboard for each available service. The metrics will be stored with Prometheus when telemetry is enabled for the mesh. Kiali will query Prometheus directly and showcase basic request and response metrics (e.g. request volume, duration, size etc). However, for a more native metric visualisation solution, a Grafana dashboard is available as an add-on to Istio.

Grafana metrics for the frontend service

CI/CD pipelines

For the automatic application deployment to the Kubernetes clusters, Kiwi.com uses Gitlab CI and Kustomize.

With Gitlab CI, it is possible to set up a testing pipeline for feature branches. As such, the changes are deployed to the Kubernetes clusters and can be reviewed without impacting the production environment. Once the branch is merged to master, all the deployed changes during the review phase are reverted.

For the generation of Kubernetes manifests, Kiwi.com utilizes Kustomize. Kustomize offers a base YAML configuration for Kubernetes resources, which in its turn can be referenced by an overlay for the application deployment.

A typical structure for Kustomize would be a base template for each service and an overlay for each cluster deployment. In the example showcased below, an overlay for Istio (alpha), Linkerd(alpha-linkerd) and review are configured:

├── base
│   ├── istio
│   │   ├── kustomization.yaml
│   │   ├── serviceentry.yaml
│   │   └── virtualservice.yaml
│   ├── linkerd
│   │   ├── ingress.yaml
│   │   └── kustomization.yaml
│   ├── nomad-frontend
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── svc.yaml
│   ├── nomad-grpc-crank
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── svc.yaml
│   ├── nomad-grpc-nff
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── svc.yaml
│   └── nomad-http
│       ├── deployment.yaml
│       ├── kustomization.yaml
│       └── svc.yaml
└── overlays
    ├── alpha
    │   └── kustomization.yaml
    ├── alpha-linkerd
    │   └── kustomization.yaml
    └── review
        └── kustomization.yaml

The End of the Journey

It was a marvellous and exciting experience to attend the Kiwi.com summer camp! The event provided a solid platform to benchmark ones technical skills against the latest technology on the market while immersing into Kiwi.com’s working culture.

I was thrilled to explore Istio and Linkerd service mesh, while deep-diving into the methods for application deployment at Kiwi.com. Looking back, having expertise and experience with such tools is highly valuable. My aim is to utilize the accumulated knowledge, further investigate these tools and integrate them into future projects.