Istio 101 (0.8.0) on GKE

In one of my previous posts, I showed how to install Istio on minikube and deploy the sample BookInfo app. A new Istio version is out (0.8.0) with a lot of changes, especially changes on traffic management, which made my steps in the previous post a little obsolete.

In this post, I want to show how to install Istio 0.8.0 on Google Kubernetes Engine (GKE), deploy the sample BookInfo app and show some of the add-ons and traffic routing.

Create Kubernetes cluster

First, we need a Kubernetes cluster to install Istio. On GKE, this is a single command:

gcloud container clusters create hello-istio \
 --cluster-version=latest \
 --zone europe-west1-b \
 --num-nodes 4

I’m using 4 worker nodes. That’s the recommended number of nodes for BookInfo sample.

Once the cluster is created, we also need to create a clusterrolebinding for Istio to be able to manage the cluster:

kubectl create clusterrolebinding cluster-admin-binding \
 --clusterrole=cluster-admin \
 --user=$(gcloud config get-value core/account)

Download & Setup Istio

Now that we have a cluster, let’s download the latest Istio (0.8.0 as of today):

curl -L https://git.io/getLatestIstio | ISTIO_VERSION=0.8.0 sh -

Add Istio’s command line tool istioctl to your PATH. We’ll need it later:

export PATH="$PATH:./istio-0.8.0/bin"

Install Istio

It’s time to install Istio with mutual authentication between sidecars:

kubectl apply -f install/kubernetes/istio-demo-auth.yaml

Once it’s done, you can check that pods are running under istio-system namespace:

kubectl get pods -n istio-system

You’ll realize that in addition to Istio base components (eg. pilot, mixer, ingress, egress), a number of add-ons are also installed (eg. prometheus, servicegraph, grafana). This is different from the previous versions of Istio.

Enable sidecar injection

When we configure and run the services, Envoy sidecars can be automatically injected into each pod for the service. For that to work, we need to enable sidecar injection for the namespace (‘default’) that we will use for our microservices. We do that by applying a label:

kubectl label namespace default istio-injection=enabled

And verify that label was successfully applied:

kubectl get namespace -L istio-injection

Deploy BookInfo app

Let’s deploy the BookInfo sample app now:

kubectl apply -f samples/bookinfo/kube/bookinfo.yaml

And make sure all the pods are running. Notice that there are 2 pods for each service (1 the actual service and 1 sidecar):

kubectl get pods

Deploy BookInfo Gateway

In Istio 0.8.0, traffic management completely changed and one of those changes is that you need to create a gateway for ingress traffic. Let’s go ahead and create a gateway for BookInfo app:

istioctl create -f samples/bookinfo/routing/bookinfo-gateway.yaml

Use BookInfo app

We can finally take a look at the app. We need to find ingress gateway IP and port:

kubectl get svc istio-ingressgateway -n istio-system

To make it easier for us, let’s define a GATEWAY_URL variable:

export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http")].port}')
export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT

Let’s see if the app is working. You should get 200 with curl:

curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/productpage

You can also open a browser and see the web frontend for product page. At this point, we got the app deployed and managed by a basic installation of Istio.

Next, we’ll take a look at some of the add-ons. Unlike previous versions, add-ons are automatically installed already. Let’s start sending some traffic first:

for i in {1..100}; do curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/productpage; done

Grafana dashboard

There’s Grafana for dashboarding. Let’s setup port forwarding first:

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 8080:3000

Navigate to http://localhost:8080 to see the dashboard:

Istio Dashboard in Grafana

Prometheus metrics

Next, let’s take a look at Prometheus for metrics. Set port forwarding:

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 8083:9090

Navigate to http://localhost:8083/graph to see Prometheus:

Prometheus in Istio

ServiceGraph

For dependency visualization, we can take a look at ServiceGraph:

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=servicegraph -o jsonpath='{.items[0].metadata.name}') 8082:8088

Navigate to http://localhost:8082/dotviz:

Screen Shot 2018-06-07 at 10.02.38 AM.png

Tracing

For HTTP tracing, there is Jaegar and Zipkin. Let’s take a look at Jaeger. Setup port forwarding as usual:

kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 8084:16686

Navigate to http://localhost:8084

Screen Shot 2018-06-07 at 10.05.11 AM

Traffic Management

Traffic Management changed dramatically in 0.8.0. You can read more about it here but basically instead of routing rules, we now have VirtualServices and DestinationRules.

You can see the existing VirtualServices and DestinationRules like this:

istioctl get virtualservices -o yaml
istioctl get destinationrules -o yaml

When you go to the product page of BookInfo application and do a browser refresh a few times, you will see that the reviews section on the right keeps changing (the stars change color). This is because there are 3 different reviews microservices and everytime, a different microservice is invoked. Let’s pin all microservices to version1:

istioctl create -f samples/bookinfo/routing/route-rule-all-v1-mtls.yaml

This creates VirtualServices and DestinationRules needed to pin all microservices to version1. Now, if you back to the product page and do a browser refresh, nothing changes because reviews microservice is pinned to version1 now.

To pin a specific user (eg. Jason) to a specific version (v2), we can do the following:

istioctl replace -f samples/bookinfo/routing/route-rule-reviews-test-v2.yaml

With this rule, if you login to the product page with username “Jason”, you should see the v2 version of reviews microservice.

To clean up all destination rules, run the following and now we’re back to the beginning with 3 different versions of the microservices:

istioctl delete -f samples/bookinfo/routing/route-rule-all-v1.yaml

Cleanup

This wraps up all the basic functionality of Istio 0.8.0 that I wanted to show on GKE. To cleanup, let’s first delete the BookInfo app:

samples/bookinfo/kube/cleanup.sh

Confirm that BookInfo app is gone:

istioctl get gateway
istioctl get virtualservices
kubectl get pods

Finally, cleanup Istio:

kubectl delete -f install/kubernetes/istio-demo.yaml

Confirm that Istio is gone:

kubectl get pods -n istio-system
Advertisements

Codemotion in Amsterdam, Devoxx in London

After my trip in Istanbul, I visited my parents in Nicosia, Cyprus for a long weekend. Then, I stopped by in Amsterdam for Codemotion before coming back to London for Devoxx. 4 cities in 4 countries in 1 week was exhausting but also a lot of fun in many ways.

Codemotion Amsterdam

Amsterdam is almost a second home to me nowadays. There’s a great tech scene and a lot of tech events throughout the year, as a result, I end up visiting Amsterdam at least 2-3 times a year.

Codemotion is a European tech conference that happens in many locations. As you might remember, I spoke at Codemotion Rome earlier this year (trip report). This was my second time speaking at Codemotion Amsterdam. Last year, I spoke about gRPC and this year about Istio, both open source projects .

Codemotion Amsterdam is a mid-size conference, my guess is about 1000/1500 developers. I love the venue of Codemotion Amsterdam. It’s in an old factory kind of place, right next to the river. They did a great job with the venue decoration, lighting both last year and this year as well.

Talk & Questions

I did my usual Istio 101 talk to a group of about 100 developers. After my talk, I got the following questions:

  • How does Istio compare to Conduit? (apparently, Conduit is an Istio like project but I didn’t know much about it).
  • How can we have sticky sessions with Istio? (i.e. make sure certain users always go to the same pod).
  • Is it possible to have a message queue between services? This is a common pattern in microservices and a couple of people were wondering if this is possible in Istio.

Devoxx London

After Amsterdam, I arrived back to London for Devoxx UK. Even though I’m based in London, I don’t get to speak as much as I’d like in London, mainly due to my travels, so I was happy to be part of Devoxx UK.

Devoxx is another European conference that happens in places like Brussels, Krakow, Casablanca and London. It started as a Java conference but nowadays, it’s much more than just Java. I got to speak at Devoxx Brussels, Krakow and Casablanca in previous years but this was my first time speaking in Devoxx London.

As a side note, Devoxx Brussels is one of the best tech conferences I ever attended with great technical content, huge cinema like screens for previous and awesome attendees and speakers. In comparison, London is smaller but still a nice conference.

Talk & Questions

In Devoxx London, I did my Istio 101 talk again. It’s great to see so much interest in Istio from the community. The talk of the video is already online, so you can watch it here if you like:

After the talk, I got the following questions:

  • Kafka or some message queue between services: Again, people are curious about how to have an async architecture with message queues between services.
  • Zipkin add-on: Where does it save its data? If Istio is restarted, does the data persist?
  • Zipkin: Can we have it to look at our custom headers for tracing?
  • Pilot stability: What happens if Pilot does? Does the service mesh still work? Does Pilot’s state persist somewhere?

Deploying ASP.NET Core apps on Kubernetes/Container Engine

In my previous post, I talked about how to deploy a containerised ASP.NET Core app to App Engine (flex) on Google Cloud. App Engine (flex) is an easy way to run containers in production: Just send your container and let Google Cloud figure out how to run it at scale. It comes with some nice default features such as versioning, traffic splitting, dashboards and autoscaling. However, it doesn’t give you much control.

Sometimes, you need to create a cluster of containers and control how each container is deployed and scaled. That’s when Kubernetes come into play. Kubernetes is an open source container management platform that helps you to manage a cluster of containers and Container Engine is Kubernetes managed by Google Cloud.

In this cloud minute, I show how to deploy an ASP.NET Core app to Kubernetes running on Container Engine.

If you want to go through these steps yourself, we also have a codelab for you that you can access here.

Deploying ASP.NET Core apps on App Engine

I love how easy it is to deploy and run containerized ASP.NET Core apps on App Engine (flex). So much so that, I created a Cloud Minute recently to show you how, here it is.

It basically involves 3 steps:

  1. Create your ASP.NET Core app using dotnet command line tool inside Cloud Shell and publish your app to get a self-contained DLL.
  2. Containerize your app by creating a Dockerfile, relying on the official App Engine image and pointing to the self-contained DLL of your app.
  3. Create an app.yaml file for App Engine and use gcloud to deploy to App Engine.

That’s it! If you want to go through these steps yourself, we also have a codelab for you that you can access here.

Capture

Windows and .NET on Google Cloud Platform

 

Originally published in SDN Magazine 131 in February 2017.

Introduction

Until recently, there were two distinct camps in the software world: the Windows (A.K.A. closed) world and the Linux (A.K.A. open) world. In the Linux world, we had tools like the bash shell, Java programming language, Eclipse IDE, MySQL database, and many other open-source projects by Apache. In the Windows world, we had similar, yet distinct tools mainly developed by Microsoft, such as the C# programming language, Visual Studio IDE, SQL Server and PowerShell.

picture0

These two worlds existed side-by-side for many years with minimal interaction. You had to pick your side and stick with it. If you had to switch sides, you had to go through a slow process of readjusting your existing tools with similar-yet-quite-different counterparts and it was painful.

In the last few years, the tech world has gone through a gradual revolution. In 2014, Microsoft open-sourced the .NET framework to everyone’s surprise. This was followed by OpenSSH running on Windows in 2015. 2016 was probably the most exciting year with SQL Server and PowerShell running on Linux, Bash running on Windows, and most imporantly ASP.NET Core, the new cross-platform version of ASP.NET, running on Linux, Mac and Windows.

As Microsoft opened up its technology to the world, we were very busy at Google ensuring that .NET has first-class support on Google Cloud Platform (GCP). In 2016, we added support for deploying traditional ASP.NET apps to Windows Servers on Compute Engine. We introduced a Visual Studio plugin and PowerShell cmdlets to manage GCP resources. We made Microsoft SQL Server available on Compute Engine. Last but not least, we started supporting containerised ASP.NET Core apps on App Engine and on Kubernetes running on Container Engine. I cover both in detail later in the article. As a result of our work, Google joined the .NET foundation in November 2016. It was a busy year!

It is very exciting that the Windows and Linux worlds are coming together, and opening up many opportunities for .NET developers. In the rest of the article, I want to talk specifically about what GCP is doing for .NET.

Google Cloud Platform

GCP provides a number of services and tools for developers to build on top of Google’s infrastructure. Java, Python, Go, Node.js, Ruby, PHP and of course C# are some of the supported languages. Let’s take a look at the options you have when it comes to application development.

picture1

At top of the chain is Cloud Functions. This is the serverless platform for event-driven microservices. It currently supports Node.js functions. The beauty of Cloud Functions is that you only need to worry about writing and deploying your function and Google takes care of running that function at scale. This is perfect for simple apps with a limited number of specialised microservices.

Sometimes, you need more than a function. You need an application with frontend and backend talking to different services. For those kind of apps, GCP offers App Engine. The idea behind App Engine is similar to Cloud Functions, in that you write your app and let Google manage and auto-scale it as required. The underlying infrastructure is abstracted away from you which means you don’t have to deal with DevOps.

If you already made the switch to containerised apps using Docker and need more control in how your app is structured and run, there’s Kubernetes and Container Engine (GKE). You can very easily get a Kubernetes cluster running on GKE with a single command and deploy your containers in any configuration you like.

Finally, if you want full control, GCP has Linux and Windows Server virtual machines (VM) running on Compute Engine. Since they are VMs, you have full control on what gets installed however, you also have full responsibility which means that you need to manually configure auto-scaling, patch software, and so on.

GCP provides a number of ways to support your app development. Let’s take a look at how GCP specifically supports .NET apps.

Windows Server, SQL Server, traditional ASP.NET on Compute Engine

If you have a traditional ASP.NET app running on Windows, you can easily take that app and migrate it to Compute Engine on GCP.

First, you need a Windows Server with the ASP.NET framework installed. Thankfully, GCP has Cloud Launcher which makes it really easy to explore, launch, and manage production-grade solutions. It is literally a couple of clicks to get a Windows Server with ASP.NET framework installed in a Compute Engine VM.  

picture2.png

If your app uses SQL Server, there are pre-configured SQL Server images that you can install on Compute Engine VMs and you can use Visual Studio to publish your ASP.NET app to your Compute Engine VMs.

picture3

ASP.NET Core on App Engine and Container Engine

ASP.NET Core is the next generation, multi-platform version of ASP.NET. It is the leaner version of traditional ASP.NET framework and runs on Linux, Mac and Windows.

picture4

App Engine has been around as a PaaS offering from Google for a while but it wasn’t available to .NET developers until ASP.NET Core came along. It is now possible to wrap an ASP.NET Core app into a Docker container and deploy that container to App Engine to run. The main advantage of App Engine is that it abstracts away the infrastructure, so developers simply deploy their app and the day-to-day running and scaling of that app is done by Google.

If you want more fine-grained control on how your containers are structured and deployed, you can always create a Kubernetes cluster on Container Engine (GKE). GKE makes it trivial to create a cluster and Kubernetes makes running containers easier by providing a high level API to automate deployment, scaling and running of containers in production.

.NET libraries for Google Cloud services

Once you have your app running in Google Cloud, many services automatically become available to your app through native .NET client libraries.

picture5

You can integrate with services like Cloud Storage for binary storage, Pub/Sub for messaging, BigQuery for incredibly fast queries, Vision API to detect images, and many other machine learning APIs such as the Natural Language Processing API, Speech API, and Translate API.

By running on Google Cloud, you will automatically gain access to these new capabilities as new services are added, and that’s the beauty of the cloud.

Cloud Tools for Visual Studio

GCP has a Visual Studio plugin to manage cloud resources directly from Visual Studio. It is available from the Visual Studio Gallery and can be installed directly within Visual Studio. It provides some ASP.NET MVC and Web API templates to work with GCP projects. It also has a Google Cloud Explorer where you manage see and manage Compute Engine and Cloud SQL instances, as well as Cloud Storage resources.

picture6

Cloud Tools for PowerShell

PowerShell is a command-line shell and associated scripting language built on the .NET Framework. It’s the default task automation and configuration management tool used in the Windows world.


Cloud Tools for PowerShell is a collection of cmdlets for accessing and manipulating Google Cloud resources such as Google Compute Engine, Google Cloud Storage, Google Cloud SQL and Google Cloud DNS —with more to come!

picture7.png

Conclusion

We’re going through some exciting times. With Windows ecosystem opening up and ASP.NET Core’s multi-platform story, there are a lot of new opportunities for .NET world. At Google, we’re serious about supporting Windows and .NET workloads on Google Cloud Platform. It’s a great time to be a .NET developer for sure!

Links

https://cloud.google.com

https://cloud.google.com/dotnet

https://cloud.google.com/windows

https://codelabs.developers.google.com/windows