KubeCon + CloudNativeCon North America 2019

This session will provide an overview of the testing infrastructure and automation used by the kubernetes project. We manage over 180 GitHub repos, generate test results from over 10,000 jobs per day. We'll walk through some of the improvements we've made to enable contributor self-service since last KubeCon.

SPIRE, the community-supported implementation of SPIFFE, enables users to take advantage of workload identity primitives like X.509s and JWTs without needing a deep understanding of complex topics like trust bootstrap, secure introduction, and credential provisioning/rotation.

But implementing the SPIFFE standard is not without its difficulties. SPIRE must scale to meet the needs of hundreds of thousands of workloads in today's hybrid cloud architectures. And, despite a requirement for high, efficient throughout, the system must remain resilient in the face of failure.

In this deep dive, we will study the challenges encountered during the implementation of SPIRE, design considerations and philosophy, and production use cases.

The Kubernetes SIG Release is chartered with producing project releases on a reliable schedule. A key component of this is release automation and build tooling. The process/procedures and tools used to create and maintain Kubernetes release artifacts are the responsibility of SIG Release’s recently created Release Engineering subproject. In the early days of the project this code was heavily dependent on a Google presence and is one of (if not _the_) final remnants of that historical connection to the project’s origination. As SIG Release work to shift these last pieces into a community led process and community maintained code, we need your assistance. This deep dive will present an overview of the major moving pieces in the release pipeline, detail the code/process enhancements and improvements currently underway, and share opportunities where you can join in the Release Engineering subproject to assist in making its code more robust and community sustainable.

Join us for a deep dive into how Kubernetes Service Catalog works behind the scenes. Starting with a quick overview of the architecture of Service Catalog, we'll also cover the operation of the Open Service Broker API that underpins Service Catalog. We'll cover some of the challenges we faced while bridging the different processing models between Kubernetes and the Open Service Broker API, and we will then look at more advanced scenarios and new features from the perspective of cluster operators, application developers and helm chart authors. You’ll come away with a solid understanding of how Service Catalog works and recommended workflows and practices for using it. Finally, if you're interested in contributing or using Service Catalog, come meet the maintainers and learn how!

The long-term goal of SIG Cloud Provider is to promote a vendor-neutral ecosystem for our community. New vendors providing support for Kubernetes should feel equally empowered to do so as any of today’s existing cloud providers. More importantly, SIG Cloud Provider is focused on ensuring a consistent and high-quality user experience across providers. This deep dive will focus on the efforts to finalize the removal of cloud-specific code from the Kubernetes code base and develop a migration strategy for in-tree to external providers. This session will also cover the evolving SIG governance structure following from the merging of individual cloud provider SIGs as working groups under SIG Cloud Provider, as well as any other major topics raised by the cloud provider community.

“Cloud Native” is open source cloud computing for applications — a complete trusted toolkit for modern architectures (CNCF presentation). There are multiple proposed projects which address key parts of the problem of providing access controls and addressing safety concerns. Each of these adds value, yet for these technical solutions to be capable of working well together and manageable to operate they will need a minimal shared context of what defines a secure system architecture.