Merge remote-tracking branch 'origin' into release-1.12
This commit is contained in:
Zach Arnold
@@ -0,0 +1,36 @@
|
||||
---
|
||||
layout: blog
|
||||
title: '2018 Steering Committee Election Cycle Kicks Off'
|
||||
date: 2018-09-06
|
||||
---
|
||||
|
||||
**Author**: Paris Pittman (Google), Jorge Castro (Heptio), Ihor Dvoretskyi (CNCF)
|
||||
|
||||
Having a clear, definable governance model is crucial for the health of open source projects. For one of the highest velocity projects in the open source world, governance is critical especially for one as large and active as Kubernetes, which is one of the most high-velocity projects in the open source world. A clear structure helps users trust that the project will be nurtured and progress forward. Initially, this structure was laid by the former 7 member bootstrap committee composed of founders and senior contributors with a goal to create the foundational governance building blocks.
|
||||
|
||||
The [initial charter](https://git.k8s.io/steering/charter.md) and establishment of an election process to seat a full Steering Committee was a part of those first building blocks. Last year, the bootstrap committee [kicked off](https://groups.google.com/d/msg/kubernetes-dev/piPuoqFkJwA/mCjwLH81BgAJ) the first Kubernetes Steering Committee election which brought forth 6 new members from the community as voted on by contributors. These new members plus the bootstrap committee formed the [Steering Committee that we know today](https://github.com/kubernetes/steering). This yearly election cycle will continue to ensure that new representatives get cycled through to add different voices and thoughts on the Kubernetes project strategy.
|
||||
|
||||
The committee has worked hard on topics that will streamline the project and how we operate. SIG (Special Interest Group) governance was an overarching recurring theme this year: Kubernetes community is not a monolithic organization, but a huge, distributed community, where [Special Interest Groups (SIGs) and Working Groups (WGs)](https://github.com/kubernetes/community/blob/master/sig-list.md) are the atomic community units, that are making Kubernetes so successful from the ground.
|
||||
|
||||
### Contributors - this is where you come in.
|
||||
|
||||
There are three seats up for election this year. The [voters guide](https://git.k8s.io/community/events/elections/2018) will get you up to speed on the specifics of this years election including candidate bios as they are updated in real time. The [elections process doc](https://github.com/kubernetes/steering/blob/master/elections.md) will steer you towards eligibility, operations, and the fine print.
|
||||
|
||||
1) Nominate yourself, someone else, and/or put your support to others.
|
||||
|
||||
Want to help chart our course? Interested in governance and community topics? Add your name! _The nomination process is optional_.
|
||||
|
||||
2) Vote.
|
||||
|
||||
On September 19th, eligible voters will receive an email poll invite conducted by [CIVS](https://civs.cs.cornell.edu). The newly elected will be announced at the [weekly community meeting](https://github.com/kubernetes/community/tree/master/communication#weekly-meeting) on Thursday, October 4th at 5pm UTC.
|
||||
|
||||
To those who are running:
|
||||
|
||||
<img src="/images/blog/2018-09-06-2018-steering-committee-election-cycle-kicks-off/sc-elections.png" width="400">
|
||||
|
||||
### Helpful resources
|
||||
|
||||
* [Steering Committee](https://github.com/kubernetes/steering) - who sits on the committee and terms, their projects and meetings info
|
||||
* [Steering Committee Charter](https://git.k8s.io/steering/charter.md) - this is a great read if you’re interested in running (or assessing for the best candidates!)
|
||||
* [Election Process](https://git.k8s.io/steering/elections.md)
|
||||
* [Voters Guide!](https://git.k8s.io/community/events/elections/2018) - Updated on a rolling basis. This guide will always have the latest information throughout the election cycle. The complete schedule of events and candidate bios will be housed here.
|
||||
@@ -5,9 +5,9 @@ case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: adform_featured_logo.png
|
||||
draft: true
|
||||
draft: false
|
||||
featured: true
|
||||
weight: 1
|
||||
weight: 47
|
||||
quote: >
|
||||
Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
|
||||
---
|
||||
@@ -35,15 +35,15 @@ quote: >
|
||||
|
||||
<h2>Solution</h2>
|
||||
The team, which had already been using <a href="https://prometheus.io/">Prometheus</a> for monitoring, embraced <a href="https://kubernetes.io/">Kubernetes</a> and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."
|
||||
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
|
||||
<h2>Impact</h2>
|
||||
"Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in <a href="https://grafana.com/">Grafana</a> dashboards provides great insight on your systems."
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
@@ -73,9 +73,9 @@ The company has a large infrastructure: <a href="https://www.openstack.org/">Ope
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
|
||||
|
||||
The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."<br><br>
|
||||
A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.
|
||||
A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.
|
||||
Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they’re still doing it."
|
||||
<br><br>
|
||||
The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."
|
||||
@@ -106,7 +106,7 @@ Prometheus has also had a positive impact: "It provides high availability for me
|
||||
</div>
|
||||
|
||||
<div class="fullcol">
|
||||
All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they’re happy because they can easily inspect the containers."
|
||||
All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they’re happy because they can easily inspect the containers."
|
||||
The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it’s cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we’re interested in is the <a href="https://github.com/virtual-kubelet/virtual-kubelet">Virtual Kubelet</a> that lets you spin up the working nodes on different clouds to do some computing."
|
||||
<br><br>
|
||||
Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we’re really happy that we joined it."
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: UK Home Office
|
||||
title: Home Office UK
|
||||
content_url: https://www.youtube.com/watch?v=F3iMkz_NSvU
|
||||
---
|
||||
---
|
||||
|
||||
@@ -3,7 +3,7 @@ title: ING Case Study
|
||||
linkTitle: ING
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
weight: 20
|
||||
weight: 50
|
||||
featured: true
|
||||
css: /css/style_case_studies.css
|
||||
quote: >
|
||||
|
||||
@@ -4,7 +4,7 @@ linkTitle: Pearson
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
featured: true
|
||||
featured: false
|
||||
quote: >
|
||||
We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online.
|
||||
---
|
||||
@@ -84,4 +84,4 @@ quote: >
|
||||
So far, about 15 production products are running on the new platform, including Pearson’s new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley. <br><br>
|
||||
But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven’t started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."
|
||||
</div>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@@ -4,7 +4,7 @@ linkTitle: Pinterest
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
featured: true
|
||||
featured: false
|
||||
weight: 30
|
||||
quote: >
|
||||
We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do.
|
||||
@@ -32,15 +32,15 @@ quote: >
|
||||
<br>
|
||||
|
||||
<h2>Solution</h2>
|
||||
The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.
|
||||
|
||||
The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.
|
||||
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
|
||||
<h2>Impact</h2>
|
||||
"By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
@@ -55,7 +55,7 @@ quote: >
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h2></h2>Pinterest was born on the cloud—running on <a href="https://aws.amazon.com/">AWS</a> since day one in 2010—but even cloud native companies can experience some growing pains.</h2> Since its launch, Pinterest has become a household name, with more than 200 million active monthly users and 100 billion objects saved. Underneath the hood, there are 1,000 microservices running and hundreds of thousands of data jobs.<br><br>
|
||||
With such growth came layers of infrastructure and diverse set-up tools and platforms for the different workloads, resulting in an inconsistent and complex end-to-end developer experience, and ultimately less velocity to get to production.
|
||||
With such growth came layers of infrastructure and diverse set-up tools and platforms for the different workloads, resulting in an inconsistent and complex end-to-end developer experience, and ultimately less velocity to get to production.
|
||||
So in 2016, the company launched a roadmap toward a new compute platform, led by the vision of having the fastest path from an idea to production, without making engineers worry about the underlying infrastructure. <br><br>
|
||||
The first phase involved moving to Docker. "Pinterest has been heavily running on virtual machines, on EC2 instances directly, for the longest time," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group. "To solve the problem around packaging software and not make engineers own portions of the fleet and those kinds of challenges, we standardized the packaging mechanism and then moved that to the container on top of the VM. Not many drastic changes. We didn’t want to boil the ocean at that point."
|
||||
|
||||
@@ -68,7 +68,7 @@ The first phase involved moving to Docker. "Pinterest has been heavily running o
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
|
||||
|
||||
The first service that was migrated was the monolith API fleet that powers most of Pinterest. At the same time, Benedict’s infrastructure governance team built chargeback and capacity planning systems to analyze how the company uses its virtual machines on AWS. "It became clear that running on VMs is just not sustainable with what we’re doing," says Benedict. "A lot of resources were underutilized. There were efficiency efforts, which worked fine at a certain scale, but now you have to move to a more decentralized way of managing that. So orchestration was something we thought could help solve that piece."<br><br>
|
||||
That led to the second phase of the roadmap. In July 2017, after an eight-week evaluation period, the team chose Kubernetes over other orchestration platforms. "Kubernetes lacked certain things at the time—for example, we wanted Spark on Kubernetes," says Benedict. "But we realized that the dev cycles we would put in to even try building that is well worth the outcome, both for Pinterest as well as the community. We’ve been in those conversations in the Big Data SIG. We realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing."<br><br>
|
||||
At the beginning of 2018, the team began onboarding its first use case into the Kubernetes system: Jenkins workloads. "Although we have builds happening during a certain period of the day, we always need to allocate peak capacity," says Benedict. "They don’t have any auto-scaling capabilities, so that capacity stays constant. It is difficult to speed up builds because ramping up takes more time. So given those kind of concerns, we thought that would be a perfect use case for us to work on."
|
||||
@@ -86,7 +86,7 @@ At the beginning of 2018, the team began onboarding its first use case into the
|
||||
<div class="fullcol">
|
||||
They ramped up the cluster, and working with a team of four people, got the Jenkins Kubernetes cluster ready for production. "We still have our static Jenkins cluster," says Benedict, "but on Kubernetes, we are doing similar builds, testing the entire pipeline, getting the artifact ready and just doing the comparison to see, how much time did it take to build over here. Is the SLA okay, is the artifact generated correct, are there issues there?" <br><br>
|
||||
"So far it’s been good," he adds, "especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."<br><br>
|
||||
By the end of Q1 2018, the team successfully migrated Jenkins Master to run natively on Kubernetes and also collaborated on the <a href="https://github.com/jenkinsci/kubernetes-plugin">Jenkins Kubernetes Plugin</a> to manage the lifecycle of workers. "We’re currently building the entire Pinterest JVM stack (one of the larger monorepos at Pinterest which was recently bazelized) on this new cluster," says Benedict. "At peak, we run thousands of pods on a few hundred nodes. Overall, by moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins. We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
|
||||
By the end of Q1 2018, the team successfully migrated Jenkins Master to run natively on Kubernetes and also collaborated on the <a href="https://github.com/jenkinsci/kubernetes-plugin">Jenkins Kubernetes Plugin</a> to manage the lifecycle of workers. "We’re currently building the entire Pinterest JVM stack (one of the larger monorepos at Pinterest which was recently bazelized) on this new cluster," says Benedict. "At peak, we run thousands of pods on a few hundred nodes. Overall, by moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins. We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
@@ -5,7 +5,7 @@ case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
featured: true
|
||||
weight: 10
|
||||
weight: 49
|
||||
quote: >
|
||||
I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.
|
||||
---
|
||||
@@ -33,14 +33,14 @@ quote: >
|
||||
|
||||
<h2>Solution</h2>
|
||||
Led by the belief that “the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of that sort of customer base,” Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build Sling TV’s next-generation platform around Kubernetes. “We are going to need to enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business at some point, so getting that sort of abstraction was a real goal,” he says. “That is one of the biggest reasons why we picked Kubernetes.” The team launched its first applications on Kubernetes in Sling TV’s two internal data centers. The push to enable AWS as a data center option is underway and should be available by the end of 2018. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company’s existing tool sets: Zenoss, New Relic and ELK.
|
||||
|
||||
|
||||
</div>
|
||||
<br><br>
|
||||
<div class="col2" style="width:95% !important;padding-left:5%;padding-top:2% !important">
|
||||
|
||||
<h2>Impact</h2>
|
||||
“We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps,” says Linder. “We have really enabled a platform thinking based approach to allowing applications to consume common tools. A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy. That does not consider the training of our operations staff to manage this new application. It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale.”
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
@@ -69,7 +69,7 @@ Led by the belief that “the cloud native architectures and patterns really giv
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
|
||||
|
||||
One big reason he chose Kubernetes was getting a level of abstraction that would enable the company to “enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business,” he says. Another factor was how much the Kubernetes ecosystem has matured over the past couple of years. “We have spent a lot of time and energy around making logging, monitoring and alerting production ready to give us insights into applications’ well-being,” says Linder. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company’s existing tool sets: Zenoss, New Relic and ELK.<br><br>
|
||||
With the emphasis on common tooling, “We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps,” says Linder. “We have really enabled a platform thinking based approach to allowing applications to consume common tools and services. A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy. That does not consider the training of our operations staff to manage this new application. It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale.”<br><br>
|
||||
|
||||
@@ -86,7 +86,7 @@ With the emphasis on common tooling, “We are getting to the place where we can
|
||||
<div class="fullcol">
|
||||
The team launched its first applications on Kubernetes in Sling TV’s two internal data centers in the early part of Q1 2018 and began to enable AWS as a data center option. The company plans to expand into other public clouds in the future.
|
||||
The first application that went into production is a web socket-based back-end notification service. “It allows back-end changes to trigger messages to our clients in the field without the polling,” says Linder. “We are talking about very high volumes of messages with this application. Without something like Kubernetes to be able to scale up and down, as well as just support that overall workload, that is pretty hard to do. I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.”<br><br>
|
||||
Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. “We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer. That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly,” says Linder.
|
||||
Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. “We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer. That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly,” says Linder.
|
||||
|
||||
|
||||
</div>
|
||||
@@ -100,7 +100,7 @@ The first application that went into production is a web socket-based back-end n
|
||||
<div class="fullcol">
|
||||
Ultimately, this undertaking is about “trying to marry Kubernetes with AI to enable web scale that just works,” he adds. “We want the artificial agents and the big data platform using the actual logs and events coming out of the applications, Kubernetes, the infrastructure, backing services and changes to the environment to make decisions like, ‘Hey we need more capacity for this service so please add more nodes.’ From a platform perspective, if you are truly doing web scale stuff and you are not using AI and big data, in my opinion, you are going to implode under your own weight. It is not a question of if, it is when. If you are in a ‘millions of users’ sort of environment, that implosion is going to be catastrophic. We are on our way to this goal and have learned a lot along the way.”<br><br>
|
||||
For Sling TV, moving to cloud native has been exactly what they needed. “We have to be able to react to changes and hiccups in the matrix,” says Linder. “It is the foundation for our ability to deliver a high-quality service for our customers. Building intelligent platforms, tools and clients in the field consuming those services has got to be part of all of this. In my eyes that is a big part of what cloud native is all about. It is taking these distributed, potentially unreliable entities and enabling a robust customer experience they expect.”
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: ygrene_featured_logo.png
|
||||
featured: true
|
||||
weight: 2
|
||||
weight: 48
|
||||
quote: >
|
||||
We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company.
|
||||
---
|
||||
@@ -34,14 +34,14 @@ quote: >
|
||||
|
||||
<h2>Solution</h2>
|
||||
Moving from an Engine Yard platform and Amazon Elastic Beanstalk, the Ygrene team embraced cloud native technologies and practices: <a href="https://kubernetes.io/">Kubernetes</a> to help scale out vertically and distribute workloads, <a href="https://github.com/theupdateframework/notary">Notary</a> to put in build-time controls and get trust on the Docker images being used with third-party dependencies, and <a href="https://www.fluentd.org/">Fluentd</a> for "observing every part of our stack," all running on <a href="https://aws.amazon.com/ec2/spot/">Amazon EC2 Spot</a>.
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
|
||||
<h2>Impact</h2>
|
||||
Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on."
|
||||
|
||||
Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on."
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
@@ -57,7 +57,7 @@ quote: >
|
||||
<div class="fullcol">
|
||||
<h2>In less than a decade, <a href="https://ygrene.com/index.html" style="text-decoration:underline">Ygrene</a> has funded more than $1 billion in loans for renewable energy projects.</h2> A <a href="https://www.energy.gov/eere/slsc/property-assessed-clean-energy-programs">PACE</a> (Property Assessed Clean Energy) financing company, "We take the equity in a home or a commercial building, and use it to finance property improvements for anything that saves electricity, produces electricity, saves water, or reduces carbon emissions," says Development Manager Austin Adams. <br><br>
|
||||
In order to approve those loans, the company processes an enormous amount of underwriting data. "We have tons of different points that we have to validate about the property, about the company, or about the person," Adams says. "So we have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data in real time." <br><br>
|
||||
By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn’t solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn’t handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."
|
||||
By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn’t solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn’t handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."
|
||||
|
||||
</div>
|
||||
</section>
|
||||
@@ -68,7 +68,7 @@ By 2017, deployments and scalability had become pain points. The company was uti
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
|
||||
|
||||
Adams along with the rest of the team set out to find a solution that would be transformational, but "wouldn’t require us to make huge refactors to the code base," he says. And as a finance company, Ygrene needed security as much as scalability. They found the answer by embracing cloud native technologies: Kubernetes to help scale out vertically and distribute workloads, Notary to achieve reliable security at every level, and Fluentd for observability. "Kubernetes was where the community was going, and we wanted to be future proof," says Adams. <br><br>
|
||||
With Kubernetes, the team was able to quickly containerize the Ygrene application with Docker. "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."<br><br>
|
||||
How? Cloud native has "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on." <br><br>
|
||||
|
||||
@@ -320,3 +320,18 @@ Note that the Kubernetes Node name must match the Photon VM name (or if `overrid
|
||||
### Node Name
|
||||
|
||||
The VSphere cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
|
||||
## IBM Cloud Kubernetes Service
|
||||
|
||||
### Compute nodes
|
||||
By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://console.bluemix.net/docs/containers/cs_clusters_planning.html#plan_clusters).
|
||||
|
||||
The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.
|
||||
|
||||
### Networking
|
||||
The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning in-cluster and private networking](https://console.bluemix.net/docs/containers/cs_network_cluster.html#planning).
|
||||
|
||||
To expose apps to the public or within the cluster, you can leverage NodePort, LoadBalancer, or Ingress services. You can also customize the Ingress application load balancer with annotations. For more information, see [Planning to expose your apps with external networking](https://console.bluemix.net/docs/containers/cs_network_planning.html#planning).
|
||||
|
||||
### Storage
|
||||
The IBM Cloud Kubernetes Service provider leverages Kubernetes-native persistent volumes to enable users to mount file, block, and cloud object storage to their apps. You can also use database-as-a-service and third-party add-ons for persistent storage of your data. For more information, see [Planning highly available persistent storage](https://console.bluemix.net/docs/containers/cs_storage_planning.html#storage_planning).
|
||||
|
||||
@@ -161,7 +161,7 @@ cluster when they should use this PriorityClass.
|
||||
### Example PriorityClass
|
||||
|
||||
```yaml
|
||||
apiVersion: scheduling.k8s.io/v1alpha1
|
||||
apiVersion: scheduling.k8s.io/v1beta1
|
||||
kind: PriorityClass
|
||||
metadata:
|
||||
name: high-priority
|
||||
|
||||
@@ -47,6 +47,7 @@ Credentials can be provided in several ways:
|
||||
- use IAM roles and policies to control access to ECR repositories
|
||||
- automatically refreshes ECR login credentials
|
||||
- Using Azure Container Registry (ACR)
|
||||
- Using IBM Cloud Container Registry
|
||||
- Configuring Nodes to Authenticate to a Private Registry
|
||||
- all pods can read any configured private registries
|
||||
- requires node configuration by cluster administrator
|
||||
@@ -55,6 +56,7 @@ Credentials can be provided in several ways:
|
||||
- requires root access to all nodes to setup
|
||||
- Specifying ImagePullSecrets on a Pod
|
||||
- only pods which provide own keys can access the private registry
|
||||
|
||||
Each option is described in more detail below.
|
||||
|
||||
|
||||
@@ -127,6 +129,12 @@ Once you have created your container registry, you will use the following creden
|
||||
Once you have those variables filled in you can
|
||||
[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
|
||||
### Using IBM Cloud Container Registry
|
||||
IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your Docker images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can create a token to grant access to registry namespaces.
|
||||
|
||||
To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://console.bluemix.net/docs/services/Registry/index.html#index).
|
||||
|
||||
You can use the IBM Cloud Container Registry to deploy containers from [IBM Cloud public images](https://console.bluemix.net/docs/services/RegistryImages/index.html#ibm_images) and your private images into the `default` namespace of your IBM Cloud Kubernetes Service cluster. To deploy a container into other namespaces, or to use an image from a different IBM Cloud Container Registry region or IBM Cloud account, create a Kubernetes `imagePullSecret`. For more information, see [Building containers from images](https://console.bluemix.net/docs/containers/cs_images.html#images).
|
||||
|
||||
### Configuring Nodes to Authenticate to a Private Registry
|
||||
|
||||
@@ -347,5 +355,3 @@ common use cases and suggested solutions.
|
||||
- The tenant adds that secret to imagePullSecrets of each namespace.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -148,7 +148,7 @@ For examples of device plugin implementations, see:
|
||||
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
|
||||
* The [SRIOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
|
||||
* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for GPU and FPGA devices
|
||||
* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for GPU, FPGA and QuickAssist devices
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -65,11 +65,12 @@ volumes for the node. For example:
|
||||
|
||||
* On
|
||||
<a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
|
||||
up to 128 volumes could be attached to a node, depending on the node type.
|
||||
up to 128 volumes can be attached to a node, [depending on the node
|
||||
type](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).
|
||||
|
||||
* For Amazon EBS disks on M5/C5 instance types, Kubernetes would permit only 25
|
||||
* For Amazon EBS disks on M5/C5 instance types, Kubernetes allows only 25
|
||||
volumes to be attached to a node. For other instance types on
|
||||
<a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>,
|
||||
Kubernetes would permit 39 volumes to be attached.
|
||||
Kubernetes allows 39 volumes to be attached to a node.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -21,7 +21,7 @@ Some typical uses of a DaemonSet are:
|
||||
- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
|
||||
- running a logs collection daemon on every node, such as `fluentd` or `logstash`.
|
||||
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
|
||||
https://github.com/prometheus/node_exporter), `collectd`, Datadog agent, New Relic agent, or Ganglia `gmond`.
|
||||
https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, or Ganglia `gmond`.
|
||||
|
||||
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
|
||||
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
|
||||
|
||||
@@ -548,7 +548,8 @@ extra:
|
||||
|
||||
In order to prevent header spoofing, the authenticating proxy is required to present a valid client
|
||||
certificate to the API server for validation against the specified CA before the request headers are
|
||||
checked.
|
||||
checked. WARNING: do **not** reuse a CA that is used in a different context unless you understand
|
||||
the risks and the mechanisms to protect the CA's usage.
|
||||
|
||||
* `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names.
|
||||
* `--requestheader-allowed-names` Optional. List of common names (cn). If set, a valid client certificate with a Common Name (cn) in the specified list must be presented before the request headers are checked for user names. If empty, any Common Name is allowed.
|
||||
|
||||
@@ -452,6 +452,16 @@ Auto-reconciliation is enabled in Kubernetes version 1.6+ when the RBAC authoriz
|
||||
|
||||
### Discovery Roles
|
||||
|
||||
Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible. To disable anonymous unauthenticated access add `--anonymous-auth=false` to the API server configuration.
|
||||
|
||||
To view the configuration of these roles via `kubectl` run:
|
||||
|
||||
```
|
||||
kubectl get clusterroles system:discovery -o yaml
|
||||
```
|
||||
|
||||
NOTE: editing the role is not recommended as changes will be overwritten on API server restart via auto-reconciliation (see above).
|
||||
|
||||
<table>
|
||||
<colgroup><col width="25%"><col width="25%"><col></colgroup>
|
||||
<tr>
|
||||
|
||||
@@ -759,7 +759,7 @@ kube-apiserver [flags]
|
||||
<td colspan="2">--requestheader-client-ca-file string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: do **not** reuse a CA that is used in a different context (for example with --client-ca-file) unless you understand the risks and the mechanisms to protect the CA's usage. Generally it is recommended to not depend on authorization being already done for incoming requests.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
@@ -216,6 +216,7 @@ any | RKE | multi-support | flannel or canal
|
||||
any | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/)
|
||||
Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial
|
||||
Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial
|
||||
IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://console.bluemix.net/docs/containers/container_index.html) | Commercial
|
||||
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -1,120 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- davidopp
|
||||
title: Configuring Kubernetes with Salt
|
||||
weight: 70
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
The Kubernetes cluster can be configured using Salt.
|
||||
|
||||
The Salt scripts are shared across multiple hosting providers and depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations. As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Salt cluster setup
|
||||
|
||||
The **salt-master** service runs on the kubernetes-master [(except on the default GCE and OpenStack-Heat setup)](#standalone-salt-configuration-on-gce-and-others).
|
||||
|
||||
The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster.
|
||||
|
||||
Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE and OpenStack-Heat)](#standalone-salt-configuration-on-gce-and-others).
|
||||
|
||||
```shell
|
||||
cat /etc/salt/minion.d/master.conf
|
||||
```
|
||||
|
||||
```none
|
||||
master: kubernetes-master
|
||||
```
|
||||
|
||||
The salt-master is contacted by each salt-minion and depending upon the machine information presented, the salt-master will provision the machine as either a kubernetes-master or kubernetes-node with all the required capabilities needed to run Kubernetes.
|
||||
|
||||
If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master. It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API.
|
||||
|
||||
## Standalone Salt Configuration on GCE and others
|
||||
|
||||
On GCE and OpenStack, using the Openstack-Heat provider, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state.
|
||||
|
||||
All remaining sections that refer to master/minion setups should be ignored for GCE and OpenStack. One fallout of this setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes.
|
||||
|
||||
## Salt security
|
||||
|
||||
*(Not applicable on default GCE and OpenStack-Heat setup.)*
|
||||
|
||||
Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.)
|
||||
|
||||
```shell
|
||||
cat /etc/salt/master.d/auto-accept.conf
|
||||
```
|
||||
|
||||
```shell
|
||||
open_mode: True
|
||||
auto_accept: True
|
||||
```
|
||||
|
||||
## Salt minion configuration
|
||||
|
||||
Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine.
|
||||
|
||||
An example file is presented below using the Vagrant based environment.
|
||||
|
||||
```shell
|
||||
cat /etc/salt/minion.d/grains.conf
|
||||
```
|
||||
|
||||
```yaml
|
||||
grains:
|
||||
etcd_servers: $MASTER_IP
|
||||
cloud: vagrant
|
||||
roles:
|
||||
- kubernetes-master
|
||||
```
|
||||
|
||||
Each hosting environment has a slightly different grains.conf file that is used to build conditional logic where required in the Salt files.
|
||||
|
||||
The following enumerates the set of defined key/value pairs that are supported today. If you add new ones, please make sure to update this list.
|
||||
|
||||
Key | Value
|
||||
-----------------------------------|----------------------------------------------------------------
|
||||
`api_servers` | (Optional) The IP address / host name where a kubelet can get read-only access to kube-apiserver
|
||||
`cbr-cidr` | (Optional) The minion IP address range used for the docker container bridge.
|
||||
`cloud` | (Optional) Which IaaS platform is used to host Kubernetes, *gce*, *azure*, *aws*, *vagrant*
|
||||
`etcd_servers` | (Optional) Comma-delimited list of IP addresses the kube-apiserver and kubelet use to reach etcd. Uses the IP of the first machine in the kubernetes_master role, or 127.0.0.1 on GCE.
|
||||
`hostnamef` | (Optional) The full host name of the machine, i.e. uname -n
|
||||
`node_ip` | (Optional) The IP address to use to address this node
|
||||
`hostname_override` | (Optional) Mapped to the kubelet hostname-override
|
||||
`network_mode` | (Optional) Networking model to use among nodes: *openvswitch*
|
||||
`networkInterfaceName` | (Optional) Networking interface to use to bind addresses, default value *eth0*
|
||||
`publicAddressOverride` | (Optional) The IP address the kube-apiserver should use to bind against for external read-only access
|
||||
`roles` | (Required) 1. `kubernetes-master` means this machine is the master in the Kubernetes cluster. 2. `kubernetes-pool` means this machine is a kubernetes-node. Depending on the role, the Salt scripts will provision different resources on the machine.
|
||||
|
||||
These keys may be leveraged by the Salt sls files to branch behavior.
|
||||
|
||||
In addition, a cluster may be running a Debian based operating system or Red Hat based operating system (Centos, Fedora, RHEL, etc.). As a result, it's important to sometimes distinguish behavior based on operating system using if branches like the following.
|
||||
|
||||
```liquid
|
||||
|
||||
{% if grains['os_family'] == 'RedHat' %}
|
||||
// something specific to a RedHat environment (Centos, Fedora, RHEL) where you may use yum, systemd, etc.
|
||||
{% else %}
|
||||
// something specific to Debian environment (apt-get, initd)
|
||||
{% endif %}
|
||||
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments. This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution.
|
||||
|
||||
## Future enhancements (Networking)
|
||||
|
||||
Per pod IP configuration is provider-specific, so when making networking changes, it's important to sandbox these as all providers may not use the same mechanisms (iptables, openvswitch, etc.)
|
||||
|
||||
We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -38,6 +38,8 @@ Enable the aggregation layer via the following kube-apiserver flags. They may ha
|
||||
--proxy-client-cert-file=<path to aggregator proxy cert>
|
||||
--proxy-client-key-file=<path to aggregator proxy key>
|
||||
|
||||
WARNING: do **not** reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage.
|
||||
|
||||
If you are not running kube-proxy on a host running the API server, then you must make sure that the system is enabled with the following apiserver flag:
|
||||
|
||||
--enable-aggregator-routing=true
|
||||
|
||||
@@ -46,9 +46,9 @@ for details about addon manager and how to disable individual addons.
|
||||
The output is similar to this:
|
||||
|
||||
```bash
|
||||
NAME TYPE
|
||||
standard (default) kubernetes.io/gce-pd
|
||||
gold kubernetes.io/gce-pd
|
||||
NAME PROVISIONER AGE
|
||||
standard (default) kubernetes.io/gce-pd 1d
|
||||
gold kubernetes.io/gce-pd 1d
|
||||
```
|
||||
|
||||
The default StorageClass is marked by `(default)`.
|
||||
@@ -77,8 +77,7 @@ for details about addon manager and how to disable individual addons.
|
||||
```
|
||||
|
||||
Please note that at most one StorageClass can be marked as default. If two
|
||||
or more of them are marked as default, Kubernetes ignores the annotation,
|
||||
i.e. it behaves as if there is no default StorageClass.
|
||||
or more of them are marked as default, a `PersistentVolumeClaim` without `storageClassName` explicitly specified cannot be created.
|
||||
|
||||
1. Verify that your chosen StorageClass is default:
|
||||
|
||||
@@ -89,9 +88,9 @@ for details about addon manager and how to disable individual addons.
|
||||
The output is similar to this:
|
||||
|
||||
```bash
|
||||
NAME TYPE
|
||||
standard kubernetes.io/gce-pd
|
||||
gold (default) kubernetes.io/gce-pd
|
||||
NAME PROVISIONER AGE
|
||||
standard kubernetes.io/gce-pd 1d
|
||||
gold (default) kubernetes.io/gce-pd 1d
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -36,10 +36,10 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 10s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 6s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 3s
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
|
||||
|
||||
This list also includes the name of the claims that are bound to each volume
|
||||
for easier identification of dynamically provisioned volumes.
|
||||
@@ -56,10 +56,10 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 40s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 36s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 33s
|
||||
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
|
||||
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
|
||||
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
|
||||
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
|
||||
|
||||
In the preceding output, you can see that the volume bound to claim
|
||||
`default/claim3` has reclaim policy `Retain`. It will not be automatically
|
||||
|
||||
@@ -30,7 +30,7 @@ it simplifies node deployment and configuration management.
|
||||
|
||||
The subset of the Kubelet's configuration that can be configured via a file
|
||||
is defined by the `KubeletConfiguration` struct
|
||||
[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
|
||||
[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
|
||||
|
||||
The configuration file must be a JSON or YAML representation of the parameters
|
||||
in this struct. Make sure the Kubelet has read permissions on the file.
|
||||
|
||||
@@ -119,7 +119,7 @@ exist. Kubelet will fail if an invalid cgroup is specified.
|
||||
|
||||
### System Reserved
|
||||
|
||||
- **Kubelet Flag**: `--system-reserved=[cpu=100mi][,][memory=100Mi][,][ephemeral-storage=1Gi]`
|
||||
- **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi]`
|
||||
- **Kubelet Flag**: `--system-reserved-cgroup=`
|
||||
|
||||
|
||||
|
||||
@@ -122,7 +122,7 @@ Recall that by setting `-cpu "2"`, you configured the Container to attempt to us
|
||||
{{< note >}}
|
||||
**Note:** Another possible explanation for the CPU throttling is that the Node might not have
|
||||
enough CPU resources available. Recall that the prerequisites for this exercise require each of
|
||||
your Nodes ot have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container
|
||||
your Nodes to have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container
|
||||
cannot use more than 1 CPU regardless of the CPU limit specified for the Container.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -190,10 +190,13 @@ kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
The output shows that the Container is killed, restarted, killed again, restarted again, and so on:
|
||||
|
||||
```
|
||||
stevepe@sperry-1:~/steveperry-53.github.io$ kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 0/1 OOMKilled 1 37s
|
||||
stevepe@sperry-1:~/steveperry-53.github.io$ kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
```
|
||||
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 1/1 Running 2 40s
|
||||
```
|
||||
|
||||
@@ -831,7 +831,7 @@
|
||||
name: 'IBM',
|
||||
logo: 'ibm',
|
||||
link: 'https://www.ibm.com/cloud/container-service',
|
||||
blurb: 'IBM - IBM Cloud Container Service'
|
||||
blurb: 'IBM - IBM Cloud Kubernetes Service'
|
||||
},
|
||||
{
|
||||
type: 2,
|
||||
|
||||
+1
-1
@@ -38,7 +38,7 @@ toc:
|
||||
path: https://cloud.google.com/kubernetes-engine/docs/before-you-begin/
|
||||
- title: Running Kubernetes on Azure Container Service
|
||||
path: https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough
|
||||
- title: Running Kubernetes on IBM Cloud Container Service
|
||||
- title: Running Kubernetes on IBM Cloud Kubernetes Service
|
||||
path: https://console.bluemix.net/docs/containers/container_index.html
|
||||
|
||||
- title: Turn-key Cloud Solutions
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
# Allow CSS/SASS updates from blog and case studies owners
|
||||
options:
|
||||
no_parent_owners: false
|
||||
reviewers:
|
||||
- alexcontini
|
||||
approvers:
|
||||
- alexcontini
|
||||
|
||||
+1937
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1 @@
|
||||
{"Target":"css/styles.css","MediaType":"text/css","Data":{}}
|
||||
@@ -0,0 +1 @@
|
||||
google-site-verification: google2a9463bd6a902e34.html
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 713 KiB |
Reference in New Issue
Block a user