At Google Cloud, we talk a lot about our belief in open source and open cloud. But what does that actually mean?Usually, when you’re a leader in an open-source community like Kubernetes and there’s a big event (like this week’s KubeCon North America), that means launching a brand new project. Launches are exciting, but maintaining a successful project like Kubernetes requires sustained investment and maintenance. We find that what really distinguishes a successful open-source project is the day-in day-out nurturing that happens behind the scenes. And it’s more than coding—it’s things like keeping the project safe and inclusive, writing documentation, managing test infrastructure, responding to issues, working in project governance, creating mentoring programs, reviewing pull requests, and participating in release teams. So today, we thought we’d take this opportunity not to announce a project, but rather reflect on some examples of what it means to us to be a part of the open-source cloud-native community.“Open-source software is not free like sunshine, it’s free like a puppy.” – Sarah Novotny, Head of Open Source Strategy for GCPSupporting communities and thinking differentlyFirst and foremost, with Kubernetes, we fully support the core values of the project, as well as provide technical and non-technical contributions in ways that reinforce positive results for the entire community. Since its inception, we’ve remained the top contributor to the project. This is something we’re incredibly proud of, and we hope that our work helps make the entire cloud-native landscape richer.Our commitment to open source also extends to making more impactful events. For example, this year, rather than produce new KubeCon conference swag, we donated diversity scholarships for 2019 to the CNCF instead. This aligns with our desire for inclusivity, and helps cultivate a stronger community. We also co-organized the Kubernetes Contributor Summit, so our community can have critical in-person interactions ahead of the full event.Supporting the existing cloud-native ecosystem: etcdAnother example of our commitment to open source is supporting the etcd distributed key value store, which has now joined the roster of CNCF projects. As the Kubernetes ecosystem matured, we saw the need for more support in this critical component. We dedicated full-time engineers to the project, including an etcd maintainer, and two of the top five code committers in 2018. We led improvements to the etcd release process, expanding release branch support from just the latest minor version to the latest three minor versions. We also dedicated staff to patch management duties and automating the release workflow, and actively helped stabilize etcd, hunting down and fixing issues including a critical boltdb data corruption issue. More recently, we contributed to the rewrite of the etcd client-side load balancer and led efforts to expand the metrics exposed by etcd for monitoring system health and performance.We’re committed to the quality and production readiness of etcd. Our plans include making upgrades safer by adding zero-downtime downgrade support, and expanding test coverage over more version pairings of etcd with Kubernetes. Finally, we’re continually making coordinated improvements to both etcd and the Kubernetes storage layer that interfaces with it to optimize scalability, performance, and ease of operability.Enriching the cloud-native landscapeOur commitment to open source isn’t just limited to supporting communities and existing projects. We also hope to share many of the valuable lessons we have learned while building scalable, secure, and reliable systems, Kubernetes being a prime example.A recent example is gVisor, based on technology Google uses to isolate and secure containerized workloads. As organizations run more heterogenous and less trusted workloads, there’s new interest in containers that provide a secure isolation boundary, and we wanted to share how we’ve been tackling the problem internally with the community. This in turn opened up broader discussions about the security challenges inherent in cloud-native architecture.In an effort to make gVisor more accessible, we integrated it with Minikube, so you can try out gVisor locally, in a VM on your laptop. We’re also actively working to open more of the project’s support infrastructure, plans, and processes, starting with a substantial system call compatibility test suite with more than 1500 tests.Releasing gVisor as an open-source project underscores the many different ways communities can form and contribute across the cloud-native landscape. Sometimes those contributions aren’t explicitly code, but instead feedback or ways to do things better. Being open helps build communities of practice across all technology groups and stakeholders.Improving the cloud-native developer experienceWe understand that the day-to-day life of an application developer can be challenging in the cloud-native world due to multiple points of divergence between how you run your application locally and in a production Kubernetes cluster. Our goal is to reduce these differences so all developers can have a positive experience in the Kubernetes ecosystem.In March we released an important open-source tool for cloud-native development called Skaffold, which allows you to define the build, test and deployment phases of your Kubernetes application with a single yaml file. In the skaffold dev command, this local pipeline is combined with an automated file watcher based on the build definition, creating a fast feedback loop—you can see your source file changes in your deployed app in seconds. This works both locally and in Google Kubernetes Engine (GKE), helping to provide a cohesive workflow.Learn and share: How we cross-pollinate communitiesAnother effort within Google open source is to create templates and other starter materials for emerging projects to use for things like governance and contributions. Our hope is to eventually provide everything necessary to bootstrap a successful open-source project, as well as offer guidance at key inflection points in the project lifecycle. These are distilled from our experience working on projects like Kubernetes, Istio, Knative, and Tensorflow. To further improve these materials, we regularly bring community managers together across projects to discuss shared struggles, opportunities, and lessons learned to avoid repeating antipatterns across projects. Scaling open-source contributions is important, especially if the goal is to ensure consistently positive and inclusive interactions across every project we support.So, as we all celebrate the continued success of Kubernetes, remember to take the time and thank someone you see helping make the community better. It’s up to all of us to foster a cloud-native ecosystem that prizes the efforts of everyone who helps maintain and nurture the work we do together.To stay up to date on what’s going on in the cloud-native community, both from Google and beyond, we urge you to subscribe to the Kubernetes Podcast. And, if you’re interested in getting involved, please visit the links provided below.Kubernetes for container scheduling and management [ Google Cloud | GitHub ]Istio to connect, monitor, and secure microservices [ Google Cloud | GitHub ]Knative to build, deploy, and manage modern serverless workloads [ Google Cloud | GitHub ]Container tools to help entire life-cycle of containerized applications [ Google Cloud | GitHub ]KubeFlow Pipeline to compose, deploy, and manage end-to-end machine learning workflows [ Google Cloud | GitHub ]
Quelle: Google Cloud Platform
Published by