Why Google’s Celebrating at KubeCon

It's hard to believe it was just five years ago Googlers decided to open up Kubernetes to the world, partnering with Red Hat, and eventually many others, to build a community that would reshape the world of infrastructure. Kubernetes' impact has been accelerated by an incredible 35,000 contributors, who give their time to make the project a cornerstone of cloud native computing, and the center of three huge events a year around the world.

No surprise then that we're excited to be at KubeCon + CloudNativeCon North America 2019 in San Diego: to celebrate Kubernetes, plus a constellation of other open source projects. You can meet leaders from these projects at the Google Cloud Community Lounge, part of Google's numerous activities at KubeCon + CloudNativeCon.

Happy Birthday, Go!

First of all, let's take a moment to celebrate the project that started it all, and wish the Go programming language a happy 10th birthday! As Kubernetes co-founder Joe Beda pointed out in 2014, Go is "Goldilocks for system software", and has been foundational to Kubernetes' success.

How about this: "Kubernetes' success is in part due to Go and the Go community. Go hits the sweet spot for distributed systems software. It is low enough to do the job but high level enough to attract a thriving community."

— Joe Beda (@jbeda) June 29, 2018

Since Kubernetes' adoption of Go, it has become known as the language of the cloud. Most of the projects you'll see this year at KubeCon are built with, or are compatible with, Go. And the Go community is a vibrant ecosystem in its own right: over the last ten years it has grown to see over 20 conferences a year, as well as 2,100 contributors. Read more about the history and evolution of Go in these 10th birthday blog posts from Russ Cox and Steve Francia.

Come join us in celebrating Go's birthday during the booth crawl, from 6.40pm to close on Tuesday November 19! Sweet treats will be served, meet with some of the Go team and other enthusiasts.

Google Open Source At KubeCon

KubeCon is a great chance to learn about the many open source projects that Google has founded or contributes to, and meet face-to-face with our engineers and community leaders. We want to hear about your use cases, meet with contributors (aspiring or experienced!), and connect with the whole community. Google's participation in the conference is not limited to technical talks. In fact, we sponsor and participate in many important community gatherings like the Diversity Lunch+Hack, and project governance like the Steering Committee and Technical Oversight Committee. We recognize and care about fostering a healthy, inclusive environment that extends far beyond just technology concerns.

Of course, Kubernetes is at the center of the conference. And, Google is deeply committed to the Kubernetes ecosystem, including creating and contributing to sub-projects such as kubebuilder, kustomize, KIND, and krew, as well as building testing infrastructure and fostering a community that inspires the whole world of open source. We're still here and still trailblazing. Come and talk with us at the community lounge, attend our talks and tutorials throughout the week, and drop in on hallway discussions galore!

gRPC, developed at Google and donated to CNCF, is a modern, open source, high-performance RPC framework that can run in any environment. Use gRPC to efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. Meet some of the gRPC maintainers, connect with the community, and pick up the latest limited edition PanCakes sticker at the Community Lounge on Wednesday!

Knative is an open source serverless platform hosted on Kubernetes. It abstracts away much of the complexity, allowing developers to focus on their code and build highly scalable, secure stateless applications. Knative codifies the best practices shared by successful real-world implementations, and solves the "boring but difficult" parts of deploying and managing cloud native services on Kubernetes.

Knative recently cut their 10th release of the project, providing a stable v1 API for the serving project, and additional work to enable production-readiness. Meet some of the maintainers and learn more about Knative in a hands-on workshop on the Monday November 18.

Istio is an open source service mesh, providing observability, control and security over communication in a distributed application -- running on Kubernetes or on VMs. Started in 2017 by Google and IBM, and reaching 1.0 in 2018, Istio has developed a vibrant community. Over the last 12 months, more than 600 developers from across 125+ companies have committed PRs! GitHub acknowledged this recently, reporting that Istio is in the top 4 of all projects across GitHub for contributor growth for committed PRs! The most recent quarterly release was Istio 1.4, which featured scalability and performance improvements as well as greatly improved experience for getting started.

Kubeflow is dedicated to making deployments of machine learning (ML) workflows on Kubernetes simple, portable and scalable. The community is building a powerful development experience for data scientists to build, train and deploy from notebooks, as well as the enterprise capabilities ML operations teams rely on to deploy and scale advanced workflows in a variety of infrastructures. The Kubeflow project is supported by 180+ contributors from 25+ organizations.

Kubeflow just released v0.7, featuring beta functionality for the Kubeflow 1.0 release, expected in early 2020. Learn how Kubeflow is being used and built in the 17+ talks featuring the project in the Machine Learning + Data track. If you're getting started, attend our Kubeflow OSS Hands-On Workshop on November 18, 1-3pm. Connect with the Kubeflow maintainers attending KubeCon by following @kubeflow.

Agones is an open source, multiplayer-dedicated, game server scaling and orchestration platform built for Kubernetes. Google founded the project in early 2018, along with Ubisoft, and recently Agones reached its 1.0 release milestone. It is being used in production for several games, with more to come!

If you're a game developer or just interested in non-traditional Kubernetes workloads, please join us for a workshop on Monday November 18, where we'll combine forces with our sibling project Open Match to turn a Kubernetes cluster into a game services backend. We're very excited about the future of open source and game development, and invite you to join us Tuesday morning in the Google Cloud Community Lounge for an open source in gaming meetup!

Krew makes it easy to discover and install kubectl plugins. Initially developed at Google, and now a Kubernetes subproject, over 60 open source kubectl plugins are distributed through Krew, and can be installed with a single command. Learn more in our breakout session, and come and talk about Krew in a Community Lounge Q&A session.

KIND makes it easy and cheap to test Kubernetes locally with Docker container "nodes". Started in the Kubernetes SIG-Testing group, this project has flourished and is now used for testing Kubernetes Pull Requests and many subprojects in the ecosystem including kubeadm, CSI, Istio, and Cluster API. KIND v0.6.0 will release before KubeCon, and the team will be presenting a deep dive and running a workshop on contributing to Kubernetes using KIND.

Envoy is a fundamental building block of service mesh architectures, providing a programmable data plane for services. Service mesh helps deploy multi-cloud applications and microservices at scale, by decoupling applications from networking, and service development from operations. Google is a lead contributor to the Envoy project, a critical part of Google Cloud's enterprise-grade service mesh products such as Anthos Service Mesh, Traffic Director and L7 ILB. We are excited to be a sponsor for EnvoyCon on Monday November 18, and would love for you to join us for an intro to Envoy on Thursday November 21.

OpenTelemetry provides the best way to capture metrics and distributed traces from your applications. Google is one of the founders of OpenTelemetry, and the community has grown to include most major monitoring, APM, and cloud vendors. OpenTelemetry is fully supported by the Google Cloud Platform and Stackdriver. Hear more about OpenTelemetry in the KubeCon keynotes, and go deeper in the overview and advanced breakout sessions.

Tekton defines reusable building blocks on Kubernetes for Cloud Native CI/CD. In March Tekton was donated to the CDF (the Continuous Delivery Foundation), and is being developed in collaboration with companies such as Red Hat, IBM, Cloudbees and other friends.

With the first release of Tekton Triggers and Tekton Pipelines, it's now possible to create an entire bespoke CI/CD system from scratch! Hear more about Tekton at the Continuous Delivery Summit on Monday, and catch the breakout sessions Mario's Adventures in Tekton Land and Russian Doll: Extending Containers with Nested Processes. Meet the Tekton maintainers at the Google Cloud Community Lounge on Thursday November 21 from 12.30-2.25pm, and follow @tektoncd for updates during the conference!

gVisor is a container-native sandbox for defense-in-depth anywhere. It provides a per-sandbox user-space kernel to improve isolation and mitigate privilege escalation vulnerabilities. gVisor integrates with Kubernetes and other container orchestration systems, while preserving the portability and resource efficiency of containers. Connect with the gVisor team in the Google Cloud Community Lounge during the Cloud Native Security meetup from 3.55-4.25pm on Thursday November 21.

Skaffold is a tool from Google that speeds up the feedback loop (build, tag, push, deploy) when developing applications on Kubernetes. Using Skaffold, you create a configuration for your project, and on every source code change Skaffold builds the images, deploys the app, abd starts tailing logs from pods and forwarding ports. For continuous delivery pipelines Skaffold provides a one-off deployment, with the ability to wait for health-checks. Skaffold is now GA, and Patrick Flynn and Balint Pato are available to chat about Skaffold and the Kubernetes Developer Experience from 4-5pm on Tuesday November 19, at the Google Cloud Community Lounge.

Additionally, join us for a breakout session on Binary Authorization in Kubernetes, which brings together Grafeas, an artifact metadata API for software supply chains, and Kritis, a deploy-time policy enforcer for Kubernetes applications.

We're excited to meet with so many users, friends, and fellow contributors at KubeCon, and hope you can join us in our talks and the Google Cloud Community Lounge.

Still can't get enough?

If you're interested in keeping up with the Kubernetes ecosystem, including all the news from KubeCon, subscribe to the Kubernetes Podcast from Google. Every week we release an episode covering news from the community, and in-depth interviews with leaders from the Kubernetes and cloud native ecosystem. Subscribe via your favorite podcast platform.

Knative governance update from the steering committee

Open source collaboration exemplifies the best aspects of contributors and companies uniting to solve difficult technical problems. And, at Google, we support thousands of projects, each with their own unique communities and challenges. Recently, the Knative Steering Committee came together to write a letter that distills this ethos, and we wanted to share it with you here.

***

Dear Knative Community,

Since the previous announcement on Knative ownership and stewardship, we’ve heard a lot of feedback from you, and the ecosystem at large. As a Steering Committee, our primary job is guiding the long-term success of the project, and this really means your success building great things with Knative. 

In order to accomplish that important goal, it requires everyone involved to be aligned on our values, what it means to be an active contributor, how you build progressive trust and responsibility, and fundamentally how we work together to build that success. The Kubernetes project explicitly defined these, and for us as a governing body, they strongly resonate. We will work to construct similar values and vet them across our community.

Trust is the heart of open source. And, clear governance is a means of building and maintaining that trust. It also provides clear signal to future contributors that joining the community is a good bet, and that everyone is visibly working toward the same goals. While there are always differences in approaches and ideas, the power of the community is its ability to collectively reconcile for the benefit of our user community first and foremost. This project is bigger than any one company or individual.

These aspirations are not enough. They will require rethinking how we structure project governance. The overarching goals of the project's governance will be:

• Create a clear and documented contributor ladder that recognizes both code and non-code contributions as valuable, and provides a means to obtain membership in governance bodies like the Technical Oversight Committee and Steering Committee based on those contributions.
• Allow the Steering Committee to oversee the usage and implementation of the Knative trademark, with the intent of limiting confusion for adopters, and providing assurances of implementation consistency. Google will provide the Steering Committee with a legal escalation path for enforcement when needed.
• Widen the contributor community to include additional vendors, end-users, and ecosystem stakeholders such that fair, representational governance organically prevents any one vendor from having a majority in any part of the project. To be clear, no one company should aspire to control outcomes, as that is inherently in conflict with the goal of community stewardship. Committee representation must be a reflection of the diversity of contributors, and also allocated fairly based on the people doing the work. This is of course a delicate balance, but one we intend to solve with community input.
• Develop the governance documents, community feedback, required tooling for metrics collection, and whatever else is necessary to enact these changes. Because the community we have now is ideally a small subset of the community we aspire to see in a year, we will target a one-year transition period to the new governance we define, similar to how the Kubernetes project moved from a bootstrap committee and charter to the new community-driven model. Building consensus is a painstaking process, so it is important to allocate enough time for all voices to be heard.

The most important takeaway here is that we are working together on this, and will do so with community input, in an inclusive way. This is the beginning of the process, and we want to go back to our roots and focus on the problems we are trying to solve for adopters of our work. Let's take this moment and rejoin our efforts to do great things together.

Respectfully yours,

Michael Behrendt (IBM), Brenda Chan (Pivotal), Paul Morie (Red Hat), Jaice Singer DuMars (Google), Ryan Gregg (Google), Donna Malayeri (Google), Tomas Isdal (Google)

Members, Knative Steering Committee

Improving Developer Experience for Writing Structured Data

Though we’re still waiting on the full materialization of the promise of the Semantic Web, search engines—including Google—are heavy consumers of structured data on the web through Schema.org. In 2015, pages with Schema.org markup accounted for 31.3% of the web. Among SEO communities, interest in Schema.org and structured data has been on the rise in recent years.

Yet, as the use of structured data continues to grow, the developer experience in authoring pieces of structured data remains spotty. I ran into this as I was trying to write my own snippets of JSON-LD. It turns out, the state-of-the-art way of writing JSON-LD is to: read the Schema.org reference; try writing a JSON literal on your own; when you think you’re done, paste the JSON into a validator (like Google’s structured data testing tool); see what’s wrong, fix; and repeat, as needed.

If it’s your first time writing JSON-LD, you might spend a few minutes figuring out how to represent an enum or boolean, looking for examples as needed.

Enter schema-dts

My experience left me with a feeling that things could be improved; writing JSON-LD should be no harder than any JSON that is constrained by a certain schema. This led me to create schema-dts (npm, github) a TypeScript-based library (and an optional codegen tool) with type definitions of the latest Schema.org JSON-LD spec.

The thinking was this: Just as IDEs (and, later, language server protocols for lightweight code editors) supercharge our developer experience with as-you-type error highlighting and code completions, we can supercharge the experience of writing those JSON-LD literals.

With IDEs and language server protocols, the write-test-debug loop was made much tighter. Developers get immediate feedback on the basic correctness of the code they write, rather than having to save sporadically and feed their code to a compiler for that feedback. With schema-dts, we try to take validators like the structured data testing tool out of the critical path of write-test-debug. Instead, you can use a library to type-check your JSON, reporting errors as you type, and offering completions for `@type`s, property names, and their values.


Thanks to TypeScript’s structural typing and discriminated unions, the general shape of Schema.org’s JSON-LD can be well-represented in TypeScript typings. I have previously described the type theory behind creating a TypeScript structure that expresses the Schema.org class structure, enumerations, `DataType`s, and properties.

Schema-dts includes two related pieces: the ‘default’ schema-dts NPM package which includes the latest Schema.org definitions, and the schema-dts-gen CLI which allows you to create your own typing definitions from Schema.org-like .nt N-Triple files. The CLI also has flags to control whether deprecated classes, properties, and enums should be included, what `@context` should be assumed by objects you write, etc.

Goals and Non-Goals

The goal of schema-dts isn’t to make type definitions that accept all legal Schema.org JSON literals. Rather, it is to make sure we provide typings that always (or almost always) result in legal Schema.org JSON-LD literals that search engines would accept. In the process, we’d like to make sure it’s as general as possible, without sacrificing type checking and useful completions.

For instance, RDF’s perspective is that structured data is property-centric, and the Schema.org reference of the domains and ranges of properties is only a suggestion for what values are inferred as. RDF actually permits values of any type to be assigned to a property. Instead, schema-dts will actually constrain you by the Schema.org values.

***

If you’re passionate about structured data, try schema-dts and join the conversation on GitHub!

By: Eyas Sharaiha, Geo Engineering & Open Source scheme-dts Project