Kubernetes Forum Sydney 2019

Nearmap captures terabytes of aerial imagery daily. With the introduction of artificial intelligence (AI) capabilities, Nearmap has leveraged Kubernetes to generate AI content based on tens of petabytes of images effectively and efficiently.

This talk covers how using Kubernetes as the backbone of our AI infrastructure, allowed us to build a fully automated deep-learning inferential pipeline that despite not being embarrassingly parallel is actually massively parallel. This talk explains the architecture of this auto-scalable solution that has exhausted all K80 spot GPUs across all US data centres of AWS for weeks. This system has already produced semantic content on over a million km2 area at resolution as high as 5cm/pixel in just 2 weeks. In this talk, you will learn about the joys of building and running this system at scale, challenges encountered, their resolution, & future work.

Are the Kubernetes behaviors your applications actually require well tested and guaranteed to be available on all cloud providers?

In this session, you will learn how to ensure your Kubernetes API surface area usage is exercised by tests all Kubernetes Certified Service Providers must pass.

We will cover:
- the e2e test suite
- automation that runs the suite before code is merged into Kubernetes.
- the API surface area covered by these tests
- the API surface area required by several popular applications.
- Identifying the untested API surface area your applications require
- Contributing tests that increase API surface coverage
- Promoting tests to Conformance

Whilst containers have allowed for quick and easy deployment and execution of workloads, they come with their drawbacks in terms of security and isolation. This is evident when running untrusted workloads, where isolation and separation of customer workloads is paramount in a multi-tenanted environment.

With years of experience running the Bitbucket Pipelines infrastructure, Atlassian engineers David Angot and Alex Price will explore the challenges faced, such as kernel vulnerabilities, providing access to Docker in Docker (DinD) and “privileged” containers when managing a platform that executes untrusted code.

With security in mind, they will explore Kata Containers, a runtime for Containerd and CRI-O that provisions Kubernetes pods as Virtual Machines, each with their own kernel and resources and most importantly isolation.

One of the distinguishing features of Vitess is its support for flexible sharding schemes. In this talk Deepthi and Jiten will show how this can be used to build a custom sharding scheme that respects geo-partitioning requirements. They will then demonstrate a database cluster built using this scheme that solves data residency at the database layer obviating the need for any changes at the application layer.

Ever since its inception and acceptance into CNCF, OPA has been widely regarded as the default policy evaluation tool in the Cloud Native landscape. Due to the functionality that OPA provides, it was quickly adopted as a control point but did not scale as expected. This talk discusses the significant role OPA plays in a large banking context, and how we went about productionising the deployment across a number of use-cases.

You've probably heard about the OCI—a standardization effort to share a common definition for container runtime, image, and image distribution. Add to that the CRI (container runtime interface) in Kubernetes—designed to abstract the container runtime from the kubelet—and you may start to wonder what all these standards and interfaces mean for you in a Kubernetes world.

As of this year, a long list of runtimes, including CNCF projects containerd and cri-o, all implement the CRI. But did you know there are quite a few others? The unique number of CRI combinations is growing, all of which use the common OCI definitions for runtime and image interoperability.

But how would you decide which container runtime is right for you? Clearly each one has tradeoffs. This talk will help describe the current landscape and give you details on the why and how of each CRI implementation available today.

If you’ve deployed your own Kubernetes cluster, care and feeding of an etcd cluster is a necessary evil. At the end of the day, etcd is the place where your cluster’s buck stops, and despite the marketing hype, operating an etcd cluster at scale is not a set and forget experience.

This talk tells a story of how my team grew from etcd novices to delivering a well-monitored, reasonably resilient, etcd system that could be upgraded in less than half an hour per cluster, online, with no downtime.

After this talk, you will have:
- a better understanding of etcd's sharp edges, and what you can do to avoid catching yourself on them
- some insights on key etcd metrics to keep an eye on and why
- what we tried with upgrades, what worked, and what didn't, and how you can avoid stepping in our potholes
- some war stories, like when we accidentally made 80k namespaces in Kube and filled our etcd.

In the past years, Kubernetes has been the nucleus of container orchestration frameworks. With the growing number of microservices in a cluster, scalability is one of the core pillars for a fault-tolerant application. Additionally, from a technological landscape standpoint, the cloud platform teams are highly focused on delivering scalable, reliable and highly available platforms. Scalability on the Kubernetes clusters can be approached on the application level and cluster level. While the application level scaling techniques (e.g. HPA and VPA) are widely used, Federation v2 and Cluster API are emerging tools that still prove their worth in a production setup.