KubeCon Seattle 2018 - Key Takeaways

Since its inception in 2016, KubeCon has become the definitive Kubernetes conference that many developers look forward to. The first KubeCon hosted in 2016 witnessed under 200 participants. Within just two years, the number of attendees at KubeCon 2018 rose to 8,000 demonstrating an intense interest in open source technology.
Kubernetes has gained significant ground in the last two years and the excitement around it is very understandable. Rising enterprise adoption is a testament to its success with more than 71% of interviewed respondents stated that they use Kubernetes for container management.
For the uninitiated, Kubernetes manages a large number of containers required for complex monolithic apps. Containerized applications break down into smaller manageable apps giving rise to the complexity of deploying and managing containers at scale. Kubernetes rose in popularity in 2017 and has since become the defacto tool to manage, track and deploy containers.

Here are a few key KubeCon 2018 highlights.

Keynote Highlight

The highlight of the event was the keynote by Kelsey Hightower who also presented a  on Serverless technologies.
He demonstrated that Serverless computing is not limited by technologies, frameworks or vendor offerings but is governed by the need of Serverless frameworks in the technology world. Kelsey wrote the function code in Fortran ran the code locally on a container which was then divided into two parts:

1. Executing Engine

2. Executing Code

He then packaged and deployed these two components, first, on AWS Lambda and then on GCE. This was truly impressive and I would consider this as the highlight among all the other sessions.

Other KubeCon session highlights

New in the Kubernetes 1.13 Release

• CoreDNS replaces Kube-DNS as the default DNS service in Kubernetes

• Kubectl diff is in beta, however, you can use it to alter the differences between deployed and local object (Part of CLI)

• A dry-run feature for API server changes that are in beta (Part of CLI)

• Container Storage Interface (CSI) is GA i.e. Storage providers can now directly use interfaces instead of going deep within K8S internals

Cluster Security – “Every system has undiscovered vulnerabilities”

Kubernetes simplifies application deployment as packaged containers. However, it carries with it certain security risks that can be mitigated by doing the following:

• Avoid granting cluster-admin access to anyone who may not need it

• Use Image scanning and Registry checks – using tools such as JFrog x-ray and Aqua Security

• Use Admission Controllers

• Avoid running code simply because it originates from a known GitHub repository. A trusted code can still be bad code.

CNCF Graduation and Upcoming Projects

Kubernetes, Prometheus, and Envoy joined CNCF projects in 2016, initially as incubator projects but now with major releases. Fluentd, Jaeger, gRPC, rkt, and Helm are some of the other exciting nascent projects.
Other projects that are currently incubating that deserve special mentions are,

Vitess

Vitess is a horizontal scaling system for MySQL databases on Clusters. It merges MySQL and NoSQL features with the ability to handle and process thousands of connections that are currently lacking in MySQL.

Rook

Rook is a cloud-native container storage service that provides file, block, and object storage and is easy to scale with your existing cluster. At present, Rook supports a limited number of storage providers however the team plans to add more in the near future.

Helm

Helm is a package manager for Kubernetes that can distribute applications by packaging them as Charts. The Helm Hub enables anyone to search for Charts and get more information on its installation and configuration.
The yet to be released Helm v3 has features such as:

• Client-side architecture

• Lua webhooks

• Developer SDK for integration

Serverless on Kubernetes

Serverless computing has been around for some time now and most Cloud infrastructure vendors provide Serverless a.k.a Functions As A Service (FAAS) under various offerings such as AWS Lambda, Azure Function, and Google Cloud Functions.
With the evolution of Kubernetes, a few noted open source projects have emerged for running Serverless code on Kubernetes. These include Kubeless, Knative, Fission, OpenFaaS, OpenFisk, and Fn. Knative, supported by Google, is supported on GCE and can be easily installed on an existing cluster.
This minimizes effort significantly for developers, who now have to code only once and deploy it on any K8S cluster running anywhere in the world, be it in the cloud, a private data center, or on an on-premise server. This also helps maximize resource utilization. For e.g. running batch jobs in the K8S cluster within the unused capacity.

Telepresence

Though Kubernetes and Containers have made application packaging and deployment very easy, it is still tough for a developer to develop, test and debug against a K8S cluster. In the past, developers have tried to solve this using Docker Compose and Log Statements, however, these add plenty of overheads such has maintenance of two YAML scripts, different environments, code cleanup, etc. Along with this, certain features are still not available on locally running Docker Compose systems such as Ingress, Scheduled jobs, and CRDS.
Telepresence by Datawire solves this problem. Telepresence launches a local client that is connected to the Telepresence proxy running in the Kubernetes cluster which routes requests to your local application. A developer can now easily develop, debug, and test, and even use advanced debugging methods.
After starting the proxy and client, the developer gets access to the cluster, services, volumes, and secrets from the local machine.

Microservices specific languages

More companies and developers are adopting microservices today. However, there is a realization that either the language is not completely equipped with the right constructs or there are frameworks (stable or under development) that can be utilized to move towards a coherent microservices design.
To solve this, a new programming language, ‘Ballerina’ built by WSO2, is being presented to develop microservices. Ballerina focuses on things that are crucial in a distributed microservices architecture – one that developers are unaware of – such as network awareness, services, service-to-service interaction, etc. These are all first call citizens in Ballerina.
To elaborate further, Ballerina is,

• Based on ‘Sequence diagram’ models

• Static and Strongly typed

• Supports concurrency natively

• Is DevOps Ready

• Is secure by default

• And much more…

Give Ballerina a spin for your next PoC!

Front-end Application Deployments Patterns on Kubernetes

Deployment of services, jobs, API or other backend code on Kubernetes is often talked about. However, rarely does anyone mention the deployment of UI code on Kubernetes. The best strategy is to have scheduled downtime which may not be possible all the time.
This session by Ross Kukulinski explored various frontend deployment patterns such as:

1. Rolling Update – There is hardly any change in computing resource needs but there are chances that during the upgrade the client may see broken pages or weird responses for HTML, CSS, and/or JavaScript.

2. Blue-Green – This is the best strategy to roll out all front-end upgrades, however, this comes at the expense of double the resources. The switch is instantaneous and the client sees the minimal impact.

3. Canary – This works best for experiments carried out in smaller groups. However, few users may see broken pages, links, etc.

Kubernetes Operators

RedHat manages Kubernetes Operator projects which the community uses for various types of deployment/services such as Prometheus, Postgres, Redis, and Confluent.
Kubernetes Operator –

• Is a pattern for building Kubernetes native applications

• Utilizes and extends the Kubernetes API. This enables you to use this with Kubectl

• Runs on Kubernetes as containers

• You build an operator for a specific application and avoid loading a single operator with multiple action items.

• Takes responsibility for Tool/Service operation and upgrade

• Gracefully handles application recovery on failure. For e.g., if an application needs three master pods and one of them fails, the operator will launch a new pod, configure it and allocate it back to the application. It can also dynamically scale the application based on configuration demands.

• Best suited for complex and stateful services such as Prometheus, Redis cluster, Kafka cluster, etc.

The Operator framework has 3 parts –

1. SDK – to build, package and test an operator

2. Lifecycle Manager – install, update, recover and manage the installed application lifecycle

3. Metering – Usage reporting of Operators and resources

More from the official KubeCon sources:

If these Kubecon 2018 highlights intrigue you, make sure to watch all the breakouts and keynote sessions on Youtube. Find all the presentation slides from KubeCon here. If you missed this KubeCon, the next session will be in Barcelona, Spain from May 10-13, 2019.