Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix STACKIT spelling #9

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/blog/2021/02.01-happy-anniversary-gardener/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -154,7 +154,7 @@
environments (as a service) for all teams within the company. Later that same year, SAP also joined the <a href=https://www.cncf.io/>CNCF</a> as a platinum member.</p><p>We first deliberated intensively on the BUY options (including acquisitions, due to the size and estimated volume needed at SAP). There were some early products from commercial vendors and startups available that did not bind exclusively to one of the hyperscalers, but these products did not cover many of our crucial and immediate requirements for a multi-cloud environment.</p><p>Ultimately, we opted to BUILD ourselves. This decision was not made lightly, because right from the start, we knew that we would have to cover thousands of clusters, across the globe, on all kinds of infrastructures. We would have to be able to create them at scale as well as manage them 24x7. And thus, we predicted the need to invest into automation of all aspects, to keep the service TCO at a minimum, and to offer an enterprise worthy SLA early on. This particular endeavor grew into launching the project Gardener, first internally, and ultimately fulfilling all checks, externally based on open source.
Its mission statement, in a nutshell, is “Universal Kubernetes at scale”.
Now, that’s quite bold. But we also had a nifty innovation that helped us tremendously along the way. And we can openly reveal the secret here: Gardener was built, not only for creating Kubernetes at scale, but it was built (recursively) in Kubernetes itself.</p><h2 id=what-do-you-get-with-gardener>What Do You Get with Gardener?</h2><p>Gardener offers managed and homogenous Kubernetes clusters on IaaS providers like <em>AWS, Azure, GCP, AliCloud, Open Telekom Cloud, SCS, OVH</em> and more, but also covers versatile infrastructures like <em>OpenStack, VMware</em> or <em>bare metal</em>. Day-1 and Day-2 operations are an integral part of a cluster’s feature set. This means that Gardener is not only capable of provisioning or de-provisioning thousands of clusters, but also of monitoring your cluster’s health state, upgrading components in a rolling fashion, or scaling the control plane as well as worker nodes up and down depending on the current resource demand.</p><p>Some features mentioned above might sound familiar to you, simply because they’re squarely derived from Kubernetes. Concretely, if you explore a Gardener managed end-user cluster, you’ll never see the so-called “control plane components” (<em>Kube-Apiserver, Kube-Controller-Manager, Kube-Scheduler, etc.</em>) The reason is that they run as Pods inside another, hosting/seeding Kubernetes cluster. Speaking in Gardener terms, the latter is called a <em>Seed</em> cluster, and the end-user cluster is called a <em>Shoot</em> cluster; and thus the botanical naming scheme for Gardener was born. Further assets like infrastructure components or worker machines are modelled as managed Kubernetes objects too. This allows Gardener to leverage all the great and production proven features of Kubernetes for managing Kubernetes clusters. Our <a href=https://kubernetes.io/blog/2019/12/02/gardener-project-update/>blog post</a> on Kubernetes.io reveals more details about the architectural refinements.</p><img title="Figure 1: Gardener architecture overview" src=/__resources/gardener-01_dedaf9.png style=width:90%;height:auto><figcaption style=text-align:center;margin-top:0;margin-bottom:30px;font-size:90%>Figure 1: Gardener architecture overview</figcaption><p>End-users directly benefit from Gardener’s recursive architecture. Many of the requirements that we identified for the Gardener service turned out to be highly convenient for shoot owners. For instance, Seed clusters are usually equipped with <em>DNS</em> and <em>x509</em> services. At the same time, these service offerings can be extended to requests coming from the Shoot clusters i.e., end-users get domain names and certificates for their applications out of the box.</p><h2 id=recognizing-the-power-of-open-source>Recognizing the Power of Open Source</h2><p>The Gardener team immediately profited from open source: from Kubernetes obviously, and all its ecosystem projects. That all facilitated our project’s very fast and robust development. But it does not answer:</p><p>“Why would SAP open source a tool that clearly solves a monetizable enterprise requirement?"_</p><p>Short spoiler alert: it initially involved a leap of faith. If we just look at our own decision path, it is undeniable that developers, and with them entire industries, gravitate towards open source. We chose Linux, Containers, and Kubernetes exactly because they are open, and we could bet on network effects, especially around skills. The same decision process is currently replicated in thousands of companies, with the same results. Why? Because all companies are digitally transforming. They are becoming software companies as well to a certain extent. Many of them are also our customers and in many discussions, we recognized that they have the same challenges that we are solving with Gardener. This, in essence, was a key eye opener. We were confident that if we developed Gardener as open source, we’d not only seize the opportunity to shape a Kubernetes management tool that finds broad interest and adoption outside of our use case at SAP, but we could solve common challenges faster with the help of a community, and that in consequence would sustain continuous feature development.</p><p>Coincidently, that was also when the <em>SAP Open Source Program Office (OSPO)</em> was launched. It supported us making a case to develop Gardener completely as open source.
Today, we can witness that this strategy has unfolded. It opened the gates not only for adoption, but for co-innovation, investment security, and user feedback directly in code. Below you can see an example of how the Gardener project benefits from this external community power as contributions are submitted right away.</p><img title="Figure 2: Example immediate community contribution" src=/__resources/gardener-02_f71c73.png style=width:90%;height:auto><figcaption style=text-align:center;margin-top:0;margin-bottom:30px;font-size:90%>Figure 2: Example immediate community contribution</figcaption><h2 id=differentiating-gardener-from-other-kubernetes-management-solutions>Differentiating Gardener from Other Kubernetes Management Solutions</h2><p>Imagine that you have created a modern solid cloud native app or service, fully scalable, in containers. And the business case requires you to run the service on multiple clouds, like <em>AWS, AliCloud, Azure</em>, &mldr; maybe even on-premises like <em>OpenStack</em> or <em>VMware</em>. Your development team has done everything to ensure that the workload is highly portable. But they would need to qualify each providers’ managed Kubernetes offering and their custom <em>Bill-of-Material (BoM)</em>, their versions, their deprecation plan, roadmap etc. Your TCD would explode and this is exactly what teams at SAP experienced. Now, with Gardener you can, instead, roll out homogeneous clusters and stay in control of your versions and a single roadmap. Across all supported providers!</p><p>Also, teams that have serious, or say, more demanding workloads running on Kubernetes will come to the same conclusion: They require the full management control of the Kubernetes underlay. Not only that, they need access, visibility, and all the tuning options for the control plane to safeguard their service. This is a conclusion not only from teams at SAP, but also from our community members, like <em>PingCap</em>, who use Gardener to serve <em>TiDB Cloud service</em>. Whenever you need to get serious and need more than one or two clusters, Gardener is your friend.</p><h2 id=who-is-using-gardener>Who Is Using Gardener?</h2><p>Well, there is SAP itself of course, but also the number of Gardener adopters and companies interested in Gardener is growing (~1700 GitHub stars), as more are challenged by multi-cluster and multi-cloud requirements.</p><p><em>Flant, PingCap, StackIT, T-Systems, Sky</em>, or <em>b’nerd</em> are among these companies, to name a few. They use Gardener to either run products they sell on top or offer managed Kubernetes clusters directly to their clients, or even only components that are re-usable from Gardener.</p><p>An interesting journey in the open source space started with <em>Finanz Informatik Technologie Service (FI-TS)</em>, an European Central Bank regulated and certified hoster for banks. They operate in very restricted environments, as you can imagine, and as such, they re-designed their datacenter for cloud native workloads from scratch, that is from cabling, racking and stacking to an API that serves bare metal servers.
Today, we can witness that this strategy has unfolded. It opened the gates not only for adoption, but for co-innovation, investment security, and user feedback directly in code. Below you can see an example of how the Gardener project benefits from this external community power as contributions are submitted right away.</p><img title="Figure 2: Example immediate community contribution" src=/__resources/gardener-02_f71c73.png style=width:90%;height:auto><figcaption style=text-align:center;margin-top:0;margin-bottom:30px;font-size:90%>Figure 2: Example immediate community contribution</figcaption><h2 id=differentiating-gardener-from-other-kubernetes-management-solutions>Differentiating Gardener from Other Kubernetes Management Solutions</h2><p>Imagine that you have created a modern solid cloud native app or service, fully scalable, in containers. And the business case requires you to run the service on multiple clouds, like <em>AWS, AliCloud, Azure</em>, &mldr; maybe even on-premises like <em>OpenStack</em> or <em>VMware</em>. Your development team has done everything to ensure that the workload is highly portable. But they would need to qualify each providers’ managed Kubernetes offering and their custom <em>Bill-of-Material (BoM)</em>, their versions, their deprecation plan, roadmap etc. Your TCD would explode and this is exactly what teams at SAP experienced. Now, with Gardener you can, instead, roll out homogeneous clusters and stay in control of your versions and a single roadmap. Across all supported providers!</p><p>Also, teams that have serious, or say, more demanding workloads running on Kubernetes will come to the same conclusion: They require the full management control of the Kubernetes underlay. Not only that, they need access, visibility, and all the tuning options for the control plane to safeguard their service. This is a conclusion not only from teams at SAP, but also from our community members, like <em>PingCap</em>, who use Gardener to serve <em>TiDB Cloud service</em>. Whenever you need to get serious and need more than one or two clusters, Gardener is your friend.</p><h2 id=who-is-using-gardener>Who Is Using Gardener?</h2><p>Well, there is SAP itself of course, but also the number of Gardener adopters and companies interested in Gardener is growing (~1700 GitHub stars), as more are challenged by multi-cluster and multi-cloud requirements.</p><p><em>Flant, PingCap, STACKIT, T-Systems, Sky</em>, or <em>b’nerd</em> are among these companies, to name a few. They use Gardener to either run products they sell on top or offer managed Kubernetes clusters directly to their clients, or even only components that are re-usable from Gardener.</p><p>An interesting journey in the open source space started with <em>Finanz Informatik Technologie Service (FI-TS)</em>, an European Central Bank regulated and certified hoster for banks. They operate in very restricted environments, as you can imagine, and as such, they re-designed their datacenter for cloud native workloads from scratch, that is from cabling, racking and stacking to an API that serves bare metal servers.
For Kubernetes-as-a-Service, they evaluated and chose Gardener because it was open and a perfect candidate. With Gardener’s extension capabilities, it was possible to bring managed Kubernetes clusters to their very own bare metal stack, <a href=https://metal-stack.io/>metal-stack.io</a>.
Of course, this meant implementation effort. But by reusing the Gardener project, <em>FI-TS</em> was able to leverage our standard with minimal adjustments for their special use-case. Subsequently, with their contributions, SAP was able to make Gardener more open for the community.</p><h2 id=full-speed-ahead-with-the-community-in-2021>Full Speed Ahead with the Community in 2021</h2><p>Some of the current and most active topics are about the installer (<a href=https://github.com/gardener/landscaper>Landscaper</a>),
<a href=https://github.com/gardener/gardener/blob/master/docs/proposals/07-shoot-control-plane-migration.md>control plane migration</a>,
Expand Down
Loading