• really good conference
• hot topics:
  • security
  • service mesh
  • custom controllers and operators
• cool afterparty!
• watch all videos on this youtube channel

KubeCon 2018

Yes, I should have written this post 3 weeks ago, but because of the conference itself, I was busy doing some learn&code in my “free” time. So, because there are already multiple good summaries of KubeCon EU 2018 on the Internet, let me just give you a summary of my personal opinions, notes, and learnings from the conference.

General impressions

In short: it was totally worth going there. This conference was really all about tech. In general, all sessions that I attended, including keynotes, were strictly technical and well prepared. Also, the “hallway track” is really great: you can learn a lot talking with other people and learning from their experience. Also, you can talk – and learn from – some of the community “stars”. I myself had an opportunity to talk to Kelsy Hightower and Tim Hockin.

The conference was also kind of crazy. There were over 4000 people and sometimes there were as many as 8 parallel tracks during breakout sessions. I highly recommend to just check the youtube channel, where all the videos – over 350 of them! – are available. One last thing: the afterparty was really cool! It was held in Tivoli Gardens, an amusement park in the center of Copenhagen. There was plenty of space, time and food to have a good time and talk with different people.

Hot Kubernetes topics

Some of the main topics were really recurring during the conference and it was easy to spot that there is a lot of work going in these areas. Here are the “hottest” ones:

Service mesh

Yes, service mesh is the “next big thing” and Istio project is really hot now.  In general, you could have an impression that Istio is the new Kubernetes: everyone has it, everyone runs it and it’s time to move past that, bring integration with other tools and see how you can exploit further the concept. But it’s not that fast. A few companies already admitted to run Istio in production, but the majority is only testing and evaluating it. I think this matches a common sense. The idea of service mesh is to have a separate layer built on top of the “normal” network stack, which is dedicated to managing traffic between different services running in your cluster and/or for your application. This management can include things like:

• request routing (canary deployments: please route 5% of my traffic to pods with label v2 and the rest to the stable deployment that has label v1)
• monitoring and visibility (gather traffic and request detail with per-service granularity; like Istio and Grafana)
• improved security (only services A and B are allowed to direct traffic to service C )
• automated dependency discovery (like Istio and Servicegraph)
• request tracing (like Istio and Jaeger)

All these possibilities are great, for me especially the area of monitoring and tracing, which can almost instantly improve your understanding of how services are behaving on their own and in relation to others. Still, let’s remember the idea is pretty fresh. It is wise to check and evaluate it on your own but later you have to decide if the increased complexity of your tech stack is worth the benefits you’re expecting. I highly recommend going through Istio’s getting started tutorial. Also, keep in mind that Istio is now the leading implementation of the service mesh idea, but it’s not the only one. There are already new projects like Conduit.

Security

Another hot topic: a lot of effort is going into the security area.  A lot is going in the area of better containers isolation and providing cloud-native identification for services. Projects worth mentioning that I’ve heard about during the conference are:

• SPIFFY/SPIRE: a specification and its implementation for providing strong identities to microservices
• gVisor: this sounded somehow incredible to me: a team from Google implemented a lightweight microkernel in userspace using golang. This microkernel is compatible (to some extent) with normal Linux kernel, but offers isolation layer for system calls, that exists between a container and operating system’s kernel. This has its own drawbacks (compatibility, performance cost), but sounds like a great way to improve container security.
• kata containers, which just released version 1.0. It’s another approach to strong container isolation, this time by implementing very lightweight virtual machines and a runtime to run them. Every container is running in a single lightweight virtual machine and the whole runtime is OCI compatible, so the isolation is transparent for a user.

Custom controllers and operators

This topic caught my personal attention. I thought that Kubernetes’ controller mechanisms are somewhat monolithic and highly integrated parts if the orchestrator. I was wrong. Basically, every object you can create through Kubernetes API has its own controller, that is responsible for handling this particular type of resource and making sure that the state of resources in the cluster matches what is configured. As an example, think about ReplicaSet controller. ReplicaSet defines a number of pods that are required to run in the cluster and a label selector that allows checking how many of them are running in the cluster right now. The whole point of ReplicaSet controller is to check how many pods matching a selector are now available in the system and compare it to the value defined in the ReplicaSet object. If there are too many pods, some of them are stopped; if there’s not enough, new ones are created using Pod Template from the ReplicaSet definition.

The idea is, that you can easily provide your own controllers. They are just a process, that needs access to Kubernetes API and monitors the state of some API objects. They can either control some already defined API objects (like Pods or Deployments) or you can define your own resource types, called Custom Resource Definitions. This second approach leads to a new pattern in creating controllers called operators. This idea was mainly started by the CoreOS team. The operator is an application specific controller, which can create and manage an application in a way, that is tuned for that particular operation. This can include functions like being able to define a backup policy in the same way as any other object in the cluster, like Pod. Be sure to check etcd, Prometheus or Vault operators as examples of this approach. The cool thing is that CoreOS created a library called Operator SDK, which makes implementing Operators easier.

After getting back from KubeCon, I really wanted to check how it works in practice. I started with trying to understand what are the basic elements and control logic of a controller. You can read about my findings in this previous article. But recently I also spent some time trying to implement Netperf Operator using the Operator SDK. My aim is to create an operator, that runs pod-to-pod network performance test for you. I’m really close to completing that, so stay tuned, a new blog entry about what I learned in the process is on the way.

Other interesting stuff

• I had no idea how much useful and interesting open source projects related to Kubernetes the team from Zalando has! Be sure to check them out! On the conference, they showed how they manage over 160 kubernetes clusters with their tools.
• If you want to learn about all projects currently under CNCF and what maturity level they are, check this CNCF Landscape page.

The post KubeCon and CloudNativeCon 2018 EU – short and delayed summary appeared first on Tailored Cloud.

• the conference was really good, from both organization and content perspectives
• watch the videos: all sessions were recorded and videos are available online
• the biggest news of the conference was Docker EE introducing full native support for Kubernetes, using the native API
• hallway tracks and talks are really interesting, I met a lot of interesting people – never skip this part of a conference
• what’s the point of very loud music on the IT party, where majority just wants to talk?

Intro

How do they say it? “Better late than never”? I hope that’s true, at least in this case. DockerCon EU 2017 ended well over a month ago. I had a pleasure to be one of the speakers at the conference and I was taking part in many other sessions and discussions in the hall and dining area too. This post is to share my general impressions of the conference and also to share the most important technical learnings I have from the conference. Of course, this entry doesn’t cover the whole conference. You have to remember that except general sessions, for the most part of the main two days, there were 8 session tracks running in parallel. So if you want to learn more, you have to take a look at all of them.

Overall impression

Just before getting to sessions details and some takeaways, I have to say I was surprised by the quality of DockerCon EU 2017. The organization was really good, everything moved forward smoothly and on schedule. Most importantly, the technical side of the presentations was really good as well. Going there, I was a little bit afraid, that the conference will be “100% docker… and nothing else”. So, I expected to hear nothing about Kubernetes, as it was a clear competition to Docker’s Swarm. To my surprise, the first general session on the first day changed my point of view completely when Docker announced integration with Kubernetes. Also, there were many talks about projects and solutions that do things with docker “differently than the recommended way”. Well, Docker was always saying that  “batteries are included, but replaceable”. It seems that after all, they keep the promise.

Also, one specific idea about the conference really caught my attention – it was called “Hallway Track”. Its aim is to help you meet other people you want to talk with during breaks or in the hallway in general. There’s an additional option in the DockerCon app, where you can add topics you want to chat about or see what others have added. Then, you ask the other person to meet and to agree on the time. That’s really cool! Such hallway talks are frequently the best part of any conference. Still, in a big event, it’s impossible to just walk randomly and ask every person met about what he or she is interested in. Personally, I tried to schedule two hallway track sessions. One of them worked pretty nice and we had a talk about using and deploying Kubernetes in production. The second one didn’t work out during the DockerCon, but we exchanged a few emails after the conference. They were really useful, as I got some first-hand experience about using Kubespray to deploy Kubernetes. I really enjoyed that Hallway Track and support included in the mobile app for it.

One more remark: conference’s location. Copenhagen is really a very nice city, expensive, rainy and worth seeing. Check just this single photo of one of the most famous streets in the city – Nyhavn. Also, they have fully automated metro trains, with no human driver. That really shows how far automation has reached, even outside our IT world

DockerCon EU 2017 – Day 1

The first day started with a general session and was focused on two main topics: the MTA program and the big announcement about integration with Kubernetes.

Let’s start with MTA: it’s Docker’s TLA (the most important stuff in naming: Three Letter Acronym) for “Modernize Traditional Applications”. This is also a clear and welcome shift in Docker’s attitude. A year back, maybe a little bit more, Docker was like “solution for the new stuff”. Microservices, lightweight containers, that can easily be plugged into CI/CD pipeline – that was the main target. If I remember correctly, there was not a single word about them in the general session now. Docker stresses the support for a transition from legacy applications to heavy containers shaped after old deployments to finally more lightweight ones. As a result of the process, you should get some advantages immediately, while moving closer to microservices architecture in the process. They have now four big official partners that provide consultancy and support for starting this transition.

In my opinion, this is definitely a good move, as it’s where money is – for both Docker and their clients. For Docker, because they can sell Docker Enterprise Edition and consultancy services to enterprises and for the customers as even the first transition from bare metal or even virtual machines to containers gives a very realistic chance of cutting roughly 50% in operational cost. That number was confirmed by Finnish Railways during the general session, but also by us (Aurea team) during our session.

After the MTA talk came the actual big announcement. Just a few days back I was wondering what will be a Docker’s response after all the big players, including now AWS, Microsoft and Oracle joined the CNCF and de facto the Kubernetes project. I missed the traffic by Docker employees in Kubernetes’ repo on GitHub, so the announcement about Docker EE supporting Kubernetes took me by surprise. Instead of fighting Kubernetes with Docker Swarm, which already seemed to be a “lost battle”, they just decided to support what the community has chosen. There’s a saying that if you can’t beat your enemy, you should join him. And I think it’s a smart move for Docker. Docker EE will be still “the driving wheel”, just letting users select between creating Swarm and Kubernetes clusters.

It was not very clear from the announcement how it will be done technically. Because of differences between Swarm and Kubernetes, I was expecting some form of wrapper or translation layer included in Docker EE and forwarding requests between users and Kubernetes. Fortunately, during one of the breaks, I had a super interesting talk with Daniel Hiltgen (@dhiltgen) from Docker. He is one of the engineers working directly on Kubernetes integration and he was answering patiently to a bunch of my questions (thanks, @dhiltgen!). The most important thing is this is pure API integration: there will be no magic glue to keep Swarm and Kubernetes together. Docker was working on adjusting both Swarm and Kubernetes APIs to make them somewhat “compatible”. The end state is that the user interface and/or main API for creating and managing clusters will be still in Docker EE. From there, it will be possible to create both Swarm and Kubernetes clusters, but you won’t be able to mix them. It was still not clear if requests to Kubernetes API will be sent by clients directly to Kubernetes’ API server or proxied through some Docker component, but it is expected to deliver “pure” Kubernetes API anyway. The good thing and the selling point is that users will get a single point of management for both of them. Docker EE will provide clusters management platform and share users and credentials database across all of them, both Swarm and Kubernetes. To get more details, I guess we have to wait for the integration to at least reach the public beta stage – currently it’s not even there. But you can subscribe for early beta access and get your hands on this cool new version when the beta is released.

Out of the all other sessions of the day, I made the following choices (remember that you can watch videos of all the sessions online):

• “What Have Syscalls Done for You Lately?” by Liz Rice @lizrice from @aquasecteam. This was a pretty introductory session about what syscalls are and how can you use tools like AppArmor to restrict which syscalls can be used by different processes.
• “LinuxKit Deep Dive” by Rolf Neugebauer. I was never really sure what’s the idea behind LinuxKit, so I chose this session. It shows some interesting capabilities for building multi-arch system images, but I’m still not convinced if it’s a good fit for general system image building – probably not.
• “Container relevant upstream kernel development” by Tycho Andersen. OK, this one was in-depth and if you’re not into kernel code and internals it might be really hard to grasp.
• “Dockerizing Aurea” by Matias Lespiau (@matiaslespiau) and – well – me. I was driving the technical part of the session. I was trying to target 2 major problems we had when dockerizing legacy applications: custom networking and configuration policies compliance. Give it a try and let me know what you think!

The whole day ended with an afterparty, which was held in an old huge train workshop. It would have been very nice if not… music. I really totally don’t get the point of running very loud dance music on a party full of IT people, where I haven’t seen a single person dancing, yet everyone was trying to chat. We were hiding in the corners to be able to talk to each other.

DockerCon EU 2017 – Day 2

The second day started again with the general session. This time, there were no big surprises. The major part was again about the MTA program and IBM joining the big consultancy companies that have Docker’s blessing to provide MTA service to customers.

As for sessions I chose for myself for that day, I went to:

• “Cilium – Kernel Native Security & DDOS Mitigation for Microservices with BPF” by Cynthia Thomas. That one was really interesting! The cilium project is trying to provide an application and/or container level security definitions (as opposed to the classic L3/L4/L7) for clusterized and containerized applications. During the session, Cynthia was also showing really interesting performance comparison between different packet processing paths in the kernel and the kproxy mechanism.

• “Deeper Dive in Docker Overlay Networks” by Laurent Bernaille. This one was also very good.  Laurent showed multiple approaches to constructing overlay networks for connecting docker containers running on multiple hosts.

• “Docker EE to support Kubernetes” by Daniel Hiltgen (@dhiltgen) and Alex Mavrogiannis.  This was titled in the pre-conference agenda as “Gordon’s secret session” – they didn’t want to spoil the integration of Kubernetes into Docker EE in the agenda. Basically, it was a longer version of the talk I had personally with Daniel you can read about it above.

The post DockerCon EU 2017 – summary by me appeared first on Tailored Cloud.