Merge branch 'master' into release-1.7
This commit is contained in:
steveperry-53
+13
-1
@@ -63,7 +63,19 @@ toc:
|
||||
- docs/user-guide/jsonpath.md
|
||||
- docs/user-guide/kubectl-cheatsheet.md
|
||||
|
||||
- docs/admin/kubeadm.md
|
||||
- title: Setup Tools
|
||||
section:
|
||||
- title: Kubeadm
|
||||
path: /docs/admin/kubeadm/
|
||||
- title: Kubefed
|
||||
path: /docs/admin/kubefed/
|
||||
section:
|
||||
- docs/admin/kubefed.md
|
||||
- docs/admin/kubefed_options.md
|
||||
- docs/admin/kubefed_init.md
|
||||
- docs/admin/kubefed_join.md
|
||||
- docs/admin/kubefed_unjoin.md
|
||||
- docs/admin/kubefed_version.md
|
||||
|
||||
- title: Config Reference
|
||||
section:
|
||||
|
||||
+16
-26
@@ -1,26 +1,13 @@
|
||||
---
|
||||
title: Ancestry Case Study
|
||||
layout: none
|
||||
class: gridPage
|
||||
layout: basic
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_ancestry.css
|
||||
---
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<link href="https://fonts.googleapis.com/css?family=Roboto:300,400" rel="stylesheet">
|
||||
<link rel="stylesheet" type="text/css" href="/css/style_ancestry.css">
|
||||
|
||||
<title>Ancestry Case Study</title>
|
||||
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
||||
<div class="banner1">
|
||||
<h1> CASE STUDY:<img src="http://c.mfcreative.com/i/logo/ancestry-on-dark.svg" class="logo" width="22%" style="margin-bottom:-12px;margin-left:3px;"><br> <div class="subhead">Digging Into the Past With New Technology</div></h1>
|
||||
<h1> CASE STUDY:<img src="http://c.mfcreative.com/i/logo/ancestry-on-dark.svg" width="22%" style="margin-bottom:-12px;margin-left:3px;"><br> <div class="subhead">Digging Into the Past With New Technology</div></h1>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -30,6 +17,7 @@ cid: caseStudies
|
||||
|
||||
<hr>
|
||||
|
||||
<section class="section1">
|
||||
<div class="cols">
|
||||
<div class="col1">
|
||||
|
||||
@@ -47,10 +35,9 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
|
||||
<br>
|
||||
<h2>Impact</h2>
|
||||
"Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced a significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
@@ -58,6 +45,7 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h2>It started with a Shaky Leaf.</h2>
|
||||
|
||||
@@ -66,6 +54,7 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
|
||||
And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."<br><br>
|
||||
The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner3">
|
||||
<div class="banner3text">
|
||||
@@ -73,6 +62,7 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like <a href="https://www.java.com/en/">Java</a> and <a href="https://www.python.org">Python</a> on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.<br><br>
|
||||
His team looked at orchestration platforms offered by <a href="https://docs.docker.com/compose/">Docker Compose</a>, <a href="http://mesos.apache.org">Mesos</a> and <a href="https://www.openstack.org/software/">OpenStack</a>, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."<br><br>
|
||||
@@ -83,6 +73,7 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
|
||||
Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment.
|
||||
<br><br>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner4">
|
||||
<div class="banner4text">
|
||||
@@ -92,22 +83,24 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<section class="section4">
|
||||
<div class="fullcol">
|
||||
With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."<br><br>
|
||||
The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."<br><br>
|
||||
A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."<br><br>
|
||||
The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
<div class="banner5">
|
||||
<div class="banner5text">
|
||||
"... 'I believe in Kubernetes. I believe in containerization. I think
|
||||
if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about,
|
||||
and it'll go forward.'"
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
|
||||
|
||||
@@ -121,7 +114,4 @@ He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
</section>
|
||||
|
||||
Executable
+112
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: Buffer Case Study
|
||||
layout: basic
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_buffer.css
|
||||
---
|
||||
|
||||
<div class="banner1">
|
||||
<h1>CASE STUDY: <img src="/images/buffer.png" width="18%" style="margin-bottom:-5px;margin-left:10px;"><br>
|
||||
<div class="subhead">Making Deployments Easy for a Small, Distributed Team</div>
|
||||
</h1>
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
Company <b>Buffer</b> Location <b>Around the World</b> Industry <b>Social Media Technology</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
|
||||
<section class="section1">
|
||||
<div class="cols">
|
||||
<div class="col1">
|
||||
|
||||
<h2>Challenge</h2>
|
||||
With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary."
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
<h2>Solution</h2>
|
||||
Embracing containerization, Buffer moved its infrastructure from Amazon Web Services’ Elastic Beanstalk to Docker on AWS, orchestrated with Kubernetes.
|
||||
<br>
|
||||
<br>
|
||||
<h2>Impact</h2>
|
||||
The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it’s going to work has shortened things up a lot. Our feedback cycles are a lot faster now too."
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
"It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it’s there in the next release or it’s coming in the next few months."<br><br><span style="font-size:16px;letter-spacing:2px;">- DAN FARRELLY, BUFFER ARCHITECT</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h2>Dan Farrelly uses a carpentry analogy to explain the problem his company, <a href="https://buffer.com">Buffer</a>, began having as its team of developers grew over the past few years.</h2>
|
||||
|
||||
"If you’re building a table by yourself, it’s fine," the company’s architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you’re sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes.<br><br>
|
||||
Since around 2012, Buffer had already been using <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>, the orchestration service for deploying infrastructure offered by <a href="https://aws.amazon.com">Amazon Web Services</a>. "We were deploying a single monolithic <a href="http://php.net/manual/en/intro-whatis.php">PHP</a> application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company. It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn’t spend too much time on it. If things were getting a little bit slow, we’d maybe use a faster server or just scale up one instance, and it would be good enough. We’d move on."<br><br>
|
||||
But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer’s then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.<br><br>Some of the company’s team was already successfully using <a href="https://www.docker.com">Docker</a> in their development environment, but the only application running on Docker in production was a marketing website that didn’t see real user traffic. They wanted to go further with Docker, and the next step was looking at options for orchestration.
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner3">
|
||||
<div class="banner3text">
|
||||
And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
First they considered <a href="https://mesosphere.com">Mesosphere</a>, <a href="https://dcos.io">DC/OS</a> and <a href="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a> (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn’t need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes’ controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well."<br><br>
|
||||
And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."<br><br>
|
||||
Above all, it provided a powerful solution for one of the company’s most distinguishing characteristics: their remote team that’s spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It’s been really cool to see people moving much faster."
|
||||
<br><br>
|
||||
With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies might."
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner4">
|
||||
<div class="banner4text">
|
||||
"In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the door."
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section4">
|
||||
<div class="fullcol">
|
||||
To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a <a href="https://www.python.org">Python</a> analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a <a href="https://slack.com">Slack</a> command, ‘/deploy,’ and it goes out instantly. They don’t need to wait on these slow turnaround times. They don’t even know where it’s running; it doesn’t matter."
|
||||
<br><br>
|
||||
One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly.
|
||||
<br><br>
|
||||
To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the door."
|
||||
<br><br>
|
||||
Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."
|
||||
<br><br>
|
||||
Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reduce risk."
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="banner5">
|
||||
<div class="banner5text">
|
||||
"If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
By October 2016, 54 percent of Buffer’s traffic was going through their Kubernetes cluster. "There’s a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes."
|
||||
<br><br>
|
||||
The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they’ve pulled out of their old infrastructure, plus the new services they’re developing in Kubernetes, on another cluster. "I want to bring all the benefits that we’ve seen on our early services to everyone on the team," says Farrelly.
|
||||
<br><br>
|
||||
<h2>For Buffer’s engineers, it’s an exciting process. "Every time we’re deploying a new service, we need to figure out: OK, what’s the architecture? How do these services communicate? What’s the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It’s enabling us to experiment as we’re learning how to design a service-oriented architecture. Before, we just wouldn’t have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it."
|
||||
</h2>
|
||||
Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It’s cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We’re very deep in Amazon but it’s nice to know we could move away if we need to."
|
||||
<br><br>
|
||||
At this point, the team at Buffer can’t imagine running their infrastructure any other way—and they’re happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."
|
||||
<br><br>
|
||||
</div>
|
||||
</section>
|
||||
@@ -14,6 +14,12 @@ cid: caseStudies
|
||||
<main>
|
||||
<div class="content">
|
||||
<div class="case-studies">
|
||||
<div class="case-study">
|
||||
<img src="/images/case_studies/buffer.png" alt="Buffer">
|
||||
<p class="quote">"It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better."</p>
|
||||
<!--<p class="attrib">— Dan Farrelly, Buffer Architect</p>-->
|
||||
<a href="/case-studies/buffer/">Read about Buffer</a>
|
||||
</div>
|
||||
<div class="case-study">
|
||||
<img src="/images/case_studies/wink_logo.png" alt="Wink">
|
||||
<p class="quote">"What you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate."</p>
|
||||
@@ -28,7 +34,7 @@ cid: caseStudies
|
||||
</div>
|
||||
<div class="case-study">
|
||||
<img src="/images/case_studies/golfnow.png" alt="GolfNow">
|
||||
<p class="quote">"We can move data centers in incredible amounts of time. If you haven’t come from the Kubernetes world and I tell you this is what I’ve been doing, you wouldn’t believe me."</p>
|
||||
<p class="quote">"If you haven’t come from the Kubernetes world and I tell you this is what I’ve been doing, you wouldn’t believe me."</p>
|
||||
<!--<p class="attrib">— Josh Chandler, Lead Architect, Open Platforms at GolfNow</p>-->
|
||||
<a href="/case-studies/golfnow/">Read about GolfNow</a>
|
||||
</div>
|
||||
@@ -47,11 +53,13 @@ cid: caseStudies
|
||||
<div class="case-study">
|
||||
<img src="/images/case_studies/ebay.png" alt="eBay">
|
||||
<p class="quote">Inside eBay's shift to Kubernetes and containers atop OpenStack</p>
|
||||
<!--<p class="attrib">— None</p>-->
|
||||
<a href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">Read about eBay</a>
|
||||
</div>
|
||||
<div class="case-study">
|
||||
<img src="/images/case_studies/box.png" alt="box">
|
||||
<p class="quote">"Kubernetes has the opportunity to be the new cloud platform. Because it’s a never-before-seen level of automation and intelligence surrounding infrastructure."</p>
|
||||
<!--<p class="attrib">— Sam Ghouds, Co-Founder and Services Architect of Box/p>-->
|
||||
<a href="/case-studies/box/">Read about Box</a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
+8
-24
@@ -1,23 +1,13 @@
|
||||
---
|
||||
title: WINK Case Study
|
||||
layout: none
|
||||
class: gridPage
|
||||
title: Wink Case Study
|
||||
layout: basic
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_wink.css
|
||||
---
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<link href="https://fonts.googleapis.com/css?family=Roboto:300,400" rel="stylesheet">
|
||||
<link rel="stylesheet" type="text/css" href="/css/style_wink.css">
|
||||
<title>WINK Case Study</title>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
|
||||
<div class="banner1">
|
||||
<h1>CASE STUDY: <img src="/images/wink_logo.png" class="logo" width="13%" style="margin-bottom:-4px"><br>
|
||||
<h1>CASE STUDY: <img src="/images/wink_logo.png" width="13%" style="margin-bottom:-4px"><br>
|
||||
<div class="subhead">Cloud-Native Infrastructure Keeps Your Smart Home Connected</div>
|
||||
</h1>
|
||||
</div>
|
||||
@@ -30,14 +20,12 @@ cid: caseStudies
|
||||
<hr>
|
||||
|
||||
<section class="section1">
|
||||
|
||||
<div class="cols">
|
||||
<div class="col1">
|
||||
|
||||
<h2>Challenge</h2>
|
||||
Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company’s consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.
|
||||
<br>
|
||||
|
||||
<br><br>
|
||||
<h2>Solution</h2>
|
||||
Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.<br><br>
|
||||
</div>
|
||||
@@ -46,8 +34,8 @@ cid: caseStudies
|
||||
<h2>Impact</h2>
|
||||
"Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware,” Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink’s workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology, says Klein, "makes building on top of the infrastructure relatively easy.”
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
|
||||
@@ -59,7 +47,6 @@ cid: caseStudies
|
||||
|
||||
|
||||
<section class="section2">
|
||||
|
||||
<div class="fullcol">
|
||||
<h2>How many people does it take to turn on a light bulb?</h2>
|
||||
|
||||
@@ -69,7 +56,6 @@ cid: caseStudies
|
||||
Wink was incubated within Quirky, a company that developed crowd-sourced inventions. The Wink app was first introduced in 2013, and at the time, it controlled only a few consumer products such as the PivotPower Strip that Quirky produced in collaboration with GE. As smart-home products proliferated, Wink was launched in 2014 in Home Depot stores nationwide. Its first project: a hub that could integrate with smart products from about a dozen brands like Honeywell and Chamberlain. The biggest challenge would be to build the infrastructure to serve all those communications between the hub and the products, with a focus on maximizing reliability and minimizing latency.<br><br>
|
||||
"When we originally started out, we were moving very fast trying to get the first product to market, the minimum viable product,” says Klein. "Lots of times you go down a path and end up having to backtrack and try different things. But in this particular case, we did a lot of the work up front, which led to us making a really sound decision to deploy it on CoreOS Container Linux. And that was very early in the life of it.”
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
@@ -83,6 +69,7 @@ cid: caseStudies
|
||||
<div class="fullcol">
|
||||
Concern number one: Wink’s products need to connect to consumer devices in people’s homes, behind a firewall. "You don’t have an end point like a URL, and you don’t even know what ports are open behind that firewall,” Klein explains. "So you essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent because you want to decrease as much as possible the overhead of sending a message – you never know when someone is going to turn on the lights.”<br><br>
|
||||
With the earliest version of the Wink Hub, when you decided to turn your lights on or off, the request would be sent to the cloud and then executed. Subsequent updates to Wink’s software enabled local control, cutting latency down to about 10 milliseconds for many devices. But with the need for cloud-enabled integrations of an ever-growing ecosystem of smart home products, low-latency internet connectivity is still a critical consideration.
|
||||
<br><br>
|
||||
<h2>"You essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent...you never know when someone is going to turn on the lights.”</h2>
|
||||
In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service,” says Klein. "We’ve always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker.”<br><br>
|
||||
At the time – just over two years ago – Docker wasn’t yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn’t really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads.”<br><br>
|
||||
@@ -120,6 +107,3 @@ cid: caseStudies
|
||||
Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What’s next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware,” Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has have built.<br><br>
|
||||
Wink’s engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs,” he says. "It’s like data pipelines as microservices.” Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You’re not reinventing the wheel every time,” he says. "You can just get down to work.” </div>
|
||||
</section>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
+2
-2
@@ -56,8 +56,8 @@
|
||||
min-height: 152px;
|
||||
}
|
||||
|
||||
.case-study:nth-child(3), .case-study:nth-child(4) {
|
||||
margin-bottom: 0;
|
||||
.case-study:nth-child(7), .case-study:nth-child(8) {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.case-study img {
|
||||
|
||||
Executable
+459
@@ -0,0 +1,459 @@
|
||||
|
||||
.buffer {
|
||||
width:100%;
|
||||
}
|
||||
|
||||
p {
|
||||
font-family:"Roboto", sans-serif;
|
||||
padding:5%;
|
||||
}
|
||||
|
||||
a {
|
||||
text-decoration:none;
|
||||
color:#3366ff;
|
||||
}
|
||||
|
||||
body {
|
||||
margin:0;
|
||||
background-color:#ffffff !important;
|
||||
|
||||
}
|
||||
|
||||
footer {
|
||||
background-color:#ffffff !important;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:bold;
|
||||
letter-spacing:0.025em;
|
||||
font-size:42px;
|
||||
padding-bottom:0px;
|
||||
}
|
||||
|
||||
.subhead {
|
||||
font-size:26px;
|
||||
font-weight:100;
|
||||
line-height:40px;
|
||||
padding-bottom:1%;
|
||||
|
||||
}
|
||||
|
||||
.banner1 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:12%;
|
||||
padding-bottom:0.5%;
|
||||
padding-left:9.9%;
|
||||
font-size:32px;
|
||||
background: url('/images/CaseStudy_buffer_banner3.jpg');
|
||||
background-size:100% auto;
|
||||
background-repeat:no-repeat;
|
||||
}
|
||||
|
||||
.banner2 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:3%;
|
||||
padding-bottom:3%;
|
||||
font-size:21px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:32px;
|
||||
float:left;
|
||||
background-size:100% auto;
|
||||
background-color:#666666;
|
||||
background-repeat:no-repeat;
|
||||
|
||||
}
|
||||
|
||||
.banner3 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-left:5%;
|
||||
padding-right:5%;
|
||||
padding-top:6%;
|
||||
padding-bottom:6%;
|
||||
font-size:21px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:32px;
|
||||
float:left;
|
||||
background: url('/images/CaseStudy_buffer_banner1.jpg');
|
||||
background-size:100% auto;
|
||||
}
|
||||
|
||||
.banner4 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:5%;
|
||||
padding-bottom:5%;
|
||||
font-size:21px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:32px;
|
||||
float:left;
|
||||
background: url('/images/CaseStudy_buffer_banner4.jpg');
|
||||
background-size:100% auto;
|
||||
}
|
||||
|
||||
.banner5 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:3%;
|
||||
padding-bottom:3%;
|
||||
font-size:21px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:32px;
|
||||
float:left;
|
||||
background-size:100% auto;
|
||||
background-color:#666666;
|
||||
background-repeat:no-repeat;
|
||||
}
|
||||
|
||||
.banner2text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:60%;
|
||||
padding-left:19%;
|
||||
float:left;
|
||||
text-align:center;
|
||||
}
|
||||
|
||||
.banner3text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:70%;
|
||||
padding-left:15%;
|
||||
text-align:center;
|
||||
}
|
||||
|
||||
.banner4text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:55%;
|
||||
padding-left:21%;
|
||||
text-align:center;
|
||||
}
|
||||
|
||||
.banner5text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:60%;
|
||||
padding-left:19%;
|
||||
float:left;
|
||||
text-align:center;
|
||||
}
|
||||
|
||||
|
||||
h2 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
font-size:24px;
|
||||
line-height:34px;
|
||||
color:#3366ff;
|
||||
}
|
||||
|
||||
.quote {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
font-size:22px;
|
||||
line-height:32px;
|
||||
color:#3366ff;
|
||||
}
|
||||
|
||||
.details {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
font-size:18px;
|
||||
color:#3366ff;
|
||||
letter-spacing:0.03em;
|
||||
padding-bottom:1.5%;
|
||||
padding-top:2%;
|
||||
padding-left:10%;
|
||||
}
|
||||
|
||||
|
||||
|
||||
hr {
|
||||
border-bottom:0px solid;
|
||||
width:100%;
|
||||
opacity:0.5;
|
||||
color:#aaaaaa;
|
||||
height:1px;
|
||||
}
|
||||
|
||||
.col1 {
|
||||
|
||||
width: 38%;
|
||||
padding-left:5%;
|
||||
padding-right:8%;
|
||||
float:left;
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:100;
|
||||
color:#606060;
|
||||
line-height:20px;
|
||||
letter-spacing:0.03em;
|
||||
font-size:14px;
|
||||
|
||||
}
|
||||
|
||||
.col2 {
|
||||
|
||||
width: 44%;
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
float:left;
|
||||
line-height:20px;
|
||||
color:#606060;
|
||||
letter-spacing:0.03em;
|
||||
font-size:14px;
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
.fullcol {
|
||||
width:77%;
|
||||
margin-left:11%;
|
||||
margin-right:10%;
|
||||
margin-top:4%;
|
||||
margin-bottom:6%;
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
float:left;
|
||||
line-height:22px;
|
||||
color:#606060;
|
||||
letter-spacing:0.03em;
|
||||
font-size:14px;
|
||||
}
|
||||
|
||||
.cols {
|
||||
width:77%;
|
||||
margin-left:6%;
|
||||
margin-top:1%;
|
||||
margin-bottom:4%;
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
float:left;
|
||||
|
||||
}
|
||||
|
||||
h4 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:400;
|
||||
letter-spacing:0.9;
|
||||
font-size:20px;
|
||||
padding-bottom:0px;
|
||||
}
|
||||
|
||||
|
||||
@media screen and (max-width: 910px){
|
||||
|
||||
h1 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:bold;
|
||||
line-height:36px;
|
||||
letter-spacing:0.03em;
|
||||
font-size:30px !important;
|
||||
padding-bottom:0px;
|
||||
width:80%;
|
||||
}
|
||||
|
||||
.subhead {
|
||||
font-size:18px;
|
||||
font-weight:100;
|
||||
line-height:27px;
|
||||
}
|
||||
|
||||
.details {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
font-size:16px;
|
||||
color:#3366ff;
|
||||
letter-spacing:0.03em;
|
||||
padding-bottom:2%;
|
||||
line-height:28px;
|
||||
padding-top:4%;
|
||||
padding-left:10%;
|
||||
}
|
||||
|
||||
.logo {
|
||||
width:8%;
|
||||
}
|
||||
|
||||
.col1 {
|
||||
width: 100%;
|
||||
padding-left:5%;
|
||||
padding-right:8%;
|
||||
float:left;
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#606060;
|
||||
line-height:20px;
|
||||
letter-spacing:0.03em;
|
||||
font-size:14px;
|
||||
}
|
||||
|
||||
.col2 {
|
||||
width: 100%;
|
||||
padding-left:5%;
|
||||
padding-top:5%;
|
||||
padding-bottom:5%;
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
float:left;
|
||||
line-height:20px;
|
||||
color:#606060;
|
||||
letter-spacing:0.03em;
|
||||
font-size:14px;
|
||||
}
|
||||
|
||||
.banner1 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:15%;
|
||||
padding-bottom:2%;
|
||||
padding-left:10%;
|
||||
font-size:18px;
|
||||
background: url('/images/CaseStudy_buffer_banner3.jpg');
|
||||
background-size:100% auto;
|
||||
}
|
||||
|
||||
.banner2 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:4%;
|
||||
padding-bottom:4%;
|
||||
padding-left:0%;
|
||||
font-size:18px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:24px;
|
||||
width:100%;
|
||||
float:left;
|
||||
background:none;
|
||||
background-color:#666666;
|
||||
}
|
||||
|
||||
.banner3 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:5%;
|
||||
padding-bottom:5%;
|
||||
font-size:18px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:24px;
|
||||
width:80%;
|
||||
padding-left:15%;
|
||||
padding-right:10%;
|
||||
float:left;
|
||||
background: url('/images/CaseStudy_buffer_banner1.jpg);
|
||||
}
|
||||
|
||||
.banner4 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:5%;
|
||||
padding-bottom:5%;
|
||||
font-size:18px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:24px;
|
||||
width:100%;
|
||||
float:left;
|
||||
background: url('/images/CaseStudy_buffer_banner4.jpg');
|
||||
}
|
||||
|
||||
.banner5 {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
padding-top:4%;
|
||||
padding-bottom:4%;
|
||||
padding-left:0%;
|
||||
font-size:18px;
|
||||
letter-spacing:0.03em;
|
||||
line-height:24px;
|
||||
width:100%;
|
||||
float:left;
|
||||
background:none;
|
||||
background-color:#666666;
|
||||
}
|
||||
|
||||
.banner2text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:80%;
|
||||
padding-left:10%;
|
||||
float:left;
|
||||
text-align:center;
|
||||
color:#ffffff;
|
||||
}
|
||||
|
||||
.banner3text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:80%;
|
||||
padding-left:2%;
|
||||
padding-right:10%;
|
||||
padding-top:5%;
|
||||
padding-bottom:5%;
|
||||
text-align:center;
|
||||
}
|
||||
|
||||
.banner4text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:80%;
|
||||
padding-left:10%;
|
||||
text-align:center;
|
||||
}
|
||||
|
||||
.banner5text {
|
||||
font-family:"Roboto", sans-serif;
|
||||
font-weight:300;
|
||||
color:#ffffff;
|
||||
width:80%;
|
||||
padding-left:10%;
|
||||
float:left;
|
||||
text-align:center;
|
||||
color:#ffffff;
|
||||
}
|
||||
|
||||
.fullcol {
|
||||
margin-top:6%;
|
||||
}
|
||||
|
||||
h2 {
|
||||
line-height:26px;
|
||||
font-size:18px;
|
||||
}
|
||||
|
||||
.quote {
|
||||
font-size:18px;
|
||||
line-height:24px;
|
||||
}
|
||||
|
||||
.logo {
|
||||
width:35%;
|
||||
}
|
||||
|
||||
@media screen and (max-width: 480px){
|
||||
|
||||
.logo {
|
||||
width:50%;
|
||||
padding-bottom:5%;
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,54 @@
|
||||
## kubefed
|
||||
|
||||
kubefed controls a Kubernetes Cluster Federation
|
||||
|
||||
### Synopsis
|
||||
|
||||
|
||||
kubefed controls a Kubernetes Cluster Federation.
|
||||
|
||||
Find more information at https://github.com/kubernetes/kubernetes.
|
||||
|
||||
```
|
||||
kubefed
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--alsologtostderr log to standard error as well as files
|
||||
--as string Username to impersonate for the operation
|
||||
--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
|
||||
--certificate-authority string Path to a cert file for the certificate authority
|
||||
--client-certificate string Path to a client certificate file for TLS
|
||||
--client-key string Path to a client key file for TLS
|
||||
--cloud-provider-gce-lb-src-cidrs cidrs CIDRS opened in GCE firewall for LB traffic proxy & health checks (default 209.85.152.0/22,209.85.204.0/22,130.211.0.0/22,35.191.0.0/16)
|
||||
--cluster string The name of the kubeconfig cluster to use
|
||||
--context string The name of the kubeconfig context to use
|
||||
--insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
|
||||
--kubeconfig string Path to the kubeconfig file to use for CLI requests.
|
||||
--log-backtrace-at traceLocation when logging hits line file:N, emit a stack trace (default :0)
|
||||
--log-dir string If non-empty, write log files in this directory
|
||||
--log-flush-frequency duration Maximum number of seconds between log flushes (default 5s)
|
||||
--logtostderr log to standard error instead of files (default true)
|
||||
--match-server-version Require server version to match client version
|
||||
-n, --namespace string If present, the namespace scope for this CLI request
|
||||
--password string Password for basic authentication to the API server
|
||||
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
|
||||
-s, --server string The address and port of the Kubernetes API server
|
||||
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
|
||||
--token string Bearer token for authentication to the API server
|
||||
--user string The name of the kubeconfig user to use
|
||||
--username string Username for basic authentication to the API server
|
||||
-v, --v Level log level for V logs
|
||||
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
* [kubefed init](kubefed_init.md) - Initialize a federation control plane
|
||||
* [kubefed join](kubefed_join.md) - Join a cluster to a federation
|
||||
* [kubefed options](kubefed_options.md) - Print the list of flags inherited by all commands
|
||||
* [kubefed unjoin](kubefed_unjoin.md) - Unjoin a cluster from a federation
|
||||
* [kubefed version](kubefed_version.md) - Print the client and server version information
|
||||
|
||||
###### Auto generated by spf13/cobra on 30-Jul-2017
|
||||
@@ -0,0 +1,83 @@
|
||||
## kubefed init
|
||||
|
||||
Initialize a federation control plane
|
||||
|
||||
### Synopsis
|
||||
|
||||
|
||||
Init initializes a federation control plane.
|
||||
|
||||
Federation control plane is hosted inside a Kubernetes
|
||||
cluster. The host cluster must be specified using the
|
||||
--host-cluster-context flag.
|
||||
|
||||
```
|
||||
kubefed init FEDERATION_NAME --host-cluster-context=HOST_CONTEXT
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
# Initialize federation control plane for a federation
|
||||
# named foo in the host cluster whose local kubeconfig
|
||||
# context is bar.
|
||||
kubefed init foo --host-cluster-context=bar
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--api-server-advertise-address string Preferred address to advertise api server nodeport service. Valid only if 'api-server-service-type=NodePort'.
|
||||
--api-server-service-type string The type of service to create for federation API server. Options: 'LoadBalancer' (default), 'NodePort'. (default "LoadBalancer")
|
||||
--apiserver-arg-overrides string comma separated list of federation-apiserver arguments to override: Example "--arg1=value1,--arg2=value2..."
|
||||
--apiserver-enable-basic-auth Enables HTTP Basic authentication for the federation-apiserver. Defaults to false.
|
||||
--apiserver-enable-token-auth Enables token authentication for the federation-apiserver. Defaults to false.
|
||||
--controllermanager-arg-overrides string comma separated list of federation-controller-manager arguments to override: Example "--arg1=value1,--arg2=value2..."
|
||||
--dns-provider string Dns provider to be used for this deployment.
|
||||
--dns-provider-config string Config file path on local file system for configuring DNS provider.
|
||||
--dns-zone-name string DNS suffix for this federation. Federated Service DNS names are published with this suffix.
|
||||
--dry-run dry run without sending commands to server.
|
||||
--etcd-image string Image to use for etcd server. (default "gcr.io/google_containers/etcd:3.0.17")
|
||||
--etcd-persistent-storage Use persistent volume for etcd. Defaults to 'true'. (default true)
|
||||
--etcd-pv-capacity string Size of persistent volume claim to be used for etcd. (default "10Gi")
|
||||
--etcd-pv-storage-class string The storage class of the persistent volume claim used for etcd. Must be provided if a default storage class is not enabled for the host cluster.
|
||||
--federation-system-namespace string Namespace in the host cluster where the federation system components are installed (default "federation-system")
|
||||
--host-cluster-context string Host cluster context
|
||||
--image string Image to use for federation API server and controller manager binaries. (default "gcr.io/google_containers/hyperkube-amd64:v0.0.0-master+$Format:%h$")
|
||||
--kubeconfig string Path to the kubeconfig file to use for CLI requests.
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--alsologtostderr log to standard error as well as files
|
||||
--as string Username to impersonate for the operation
|
||||
--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
|
||||
--certificate-authority string Path to a cert file for the certificate authority
|
||||
--client-certificate string Path to a client certificate file for TLS
|
||||
--client-key string Path to a client key file for TLS
|
||||
--cloud-provider-gce-lb-src-cidrs cidrs CIDRS opened in GCE firewall for LB traffic proxy & health checks (default 209.85.152.0/22,209.85.204.0/22,130.211.0.0/22,35.191.0.0/16)
|
||||
--cluster string The name of the kubeconfig cluster to use
|
||||
--context string The name of the kubeconfig context to use
|
||||
--insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
|
||||
--log-backtrace-at traceLocation when logging hits line file:N, emit a stack trace (default :0)
|
||||
--log-dir string If non-empty, write log files in this directory
|
||||
--log-flush-frequency duration Maximum number of seconds between log flushes (default 5s)
|
||||
--logtostderr log to standard error instead of files (default true)
|
||||
--match-server-version Require server version to match client version
|
||||
-n, --namespace string If present, the namespace scope for this CLI request
|
||||
--password string Password for basic authentication to the API server
|
||||
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
|
||||
-s, --server string The address and port of the Kubernetes API server
|
||||
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
|
||||
--token string Bearer token for authentication to the API server
|
||||
--user string The name of the kubeconfig user to use
|
||||
--username string Username for basic authentication to the API server
|
||||
-v, --v Level log level for V logs
|
||||
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
* [kubefed](kubefed.md) - kubefed controls a Kubernetes Cluster Federation
|
||||
|
||||
###### Auto generated by spf13/cobra on 30-Jul-2017
|
||||
@@ -0,0 +1,83 @@
|
||||
## kubefed join
|
||||
|
||||
Join a cluster to a federation
|
||||
|
||||
### Synopsis
|
||||
|
||||
|
||||
Join adds a cluster to a federation.
|
||||
|
||||
Current context is assumed to be a federation API
|
||||
server. Please use the --context flag otherwise.
|
||||
|
||||
```
|
||||
kubefed join CLUSTER_NAME --host-cluster-context=HOST_CONTEXT
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
# Join a cluster to a federation by specifying the
|
||||
# cluster name and the context name of the federation
|
||||
# control plane's host cluster. Cluster name must be
|
||||
# a valid RFC 1123 subdomain name. Cluster context
|
||||
# must be specified if the cluster name is different
|
||||
# than the cluster's context in the local kubeconfig.
|
||||
kubefed join foo --host-cluster-context=bar
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--allow-missing-template-keys If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. (default true)
|
||||
--cluster-context string Name of the cluster's context in the local kubeconfig. Defaults to cluster name if unspecified.
|
||||
--dry-run If true, only print the object that would be sent, without sending it.
|
||||
--federation-system-namespace string Namespace in the host cluster where the federation system components are installed (default "federation-system")
|
||||
--generator string The name of the API generator to use. (default "cluster/v1beta1")
|
||||
--host-cluster-context string Host cluster context
|
||||
--kubeconfig string Path to the kubeconfig file to use for CLI requests.
|
||||
--no-headers When using the default or custom-column output format, don't print headers (default print headers).
|
||||
-o, --output string Output format. One of: json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... See custom columns [http://kubernetes.io/docs/user-guide/kubectl-overview/#custom-columns], golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [http://kubernetes.io/docs/user-guide/jsonpath].
|
||||
--save-config If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
|
||||
--schema-cache-dir string If non-empty, load/store cached API schemas in this directory, default is '$HOME/.kube/schema' (default "~/.kube/schema")
|
||||
-a, --show-all When printing, show all resources (default hide terminated pods.)
|
||||
--show-labels When printing, show all labels as the last column (default hide labels column)
|
||||
--sort-by string If non-empty, sort list types using this field specification. The field specification is expressed as a JSONPath expression (e.g. '{.metadata.name}'). The field in the API resource specified by this JSONPath expression must be an integer or a string.
|
||||
--template string Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
|
||||
--validate If true, use a schema to validate the input before sending it (default true)
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--alsologtostderr log to standard error as well as files
|
||||
--as string Username to impersonate for the operation
|
||||
--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
|
||||
--certificate-authority string Path to a cert file for the certificate authority
|
||||
--client-certificate string Path to a client certificate file for TLS
|
||||
--client-key string Path to a client key file for TLS
|
||||
--cloud-provider-gce-lb-src-cidrs cidrs CIDRS opened in GCE firewall for LB traffic proxy & health checks (default 209.85.152.0/22,209.85.204.0/22,130.211.0.0/22,35.191.0.0/16)
|
||||
--cluster string The name of the kubeconfig cluster to use
|
||||
--context string The name of the kubeconfig context to use
|
||||
--insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
|
||||
--log-backtrace-at traceLocation when logging hits line file:N, emit a stack trace (default :0)
|
||||
--log-dir string If non-empty, write log files in this directory
|
||||
--log-flush-frequency duration Maximum number of seconds between log flushes (default 5s)
|
||||
--logtostderr log to standard error instead of files (default true)
|
||||
--match-server-version Require server version to match client version
|
||||
-n, --namespace string If present, the namespace scope for this CLI request
|
||||
--password string Password for basic authentication to the API server
|
||||
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
|
||||
-s, --server string The address and port of the Kubernetes API server
|
||||
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
|
||||
--token string Bearer token for authentication to the API server
|
||||
--user string The name of the kubeconfig user to use
|
||||
--username string Username for basic authentication to the API server
|
||||
-v, --v Level log level for V logs
|
||||
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
* [kubefed](kubefed.md) - kubefed controls a Kubernetes Cluster Federation
|
||||
|
||||
###### Auto generated by spf13/cobra on 30-Jul-2017
|
||||
@@ -0,0 +1,55 @@
|
||||
## kubefed options
|
||||
|
||||
Print the list of flags inherited by all commands
|
||||
|
||||
### Synopsis
|
||||
|
||||
|
||||
Print the list of flags inherited by all commands
|
||||
|
||||
```
|
||||
kubefed options
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
# Print flags inherited by all commands
|
||||
kubectl options
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--alsologtostderr log to standard error as well as files
|
||||
--as string Username to impersonate for the operation
|
||||
--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
|
||||
--certificate-authority string Path to a cert file for the certificate authority
|
||||
--client-certificate string Path to a client certificate file for TLS
|
||||
--client-key string Path to a client key file for TLS
|
||||
--cloud-provider-gce-lb-src-cidrs cidrs CIDRS opened in GCE firewall for LB traffic proxy & health checks (default 209.85.152.0/22,209.85.204.0/22,130.211.0.0/22,35.191.0.0/16)
|
||||
--cluster string The name of the kubeconfig cluster to use
|
||||
--context string The name of the kubeconfig context to use
|
||||
--insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
|
||||
--kubeconfig string Path to the kubeconfig file to use for CLI requests.
|
||||
--log-backtrace-at traceLocation when logging hits line file:N, emit a stack trace (default :0)
|
||||
--log-dir string If non-empty, write log files in this directory
|
||||
--log-flush-frequency duration Maximum number of seconds between log flushes (default 5s)
|
||||
--logtostderr log to standard error instead of files (default true)
|
||||
--match-server-version Require server version to match client version
|
||||
-n, --namespace string If present, the namespace scope for this CLI request
|
||||
--password string Password for basic authentication to the API server
|
||||
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
|
||||
-s, --server string The address and port of the Kubernetes API server
|
||||
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
|
||||
--token string Bearer token for authentication to the API server
|
||||
--user string The name of the kubeconfig user to use
|
||||
--username string Username for basic authentication to the API server
|
||||
-v, --v Level log level for V logs
|
||||
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
* [kubefed](kubefed.md) - kubefed controls a Kubernetes Cluster Federation
|
||||
|
||||
###### Auto generated by spf13/cobra on 30-Jul-2017
|
||||
@@ -0,0 +1,69 @@
|
||||
## kubefed unjoin
|
||||
|
||||
Unjoin a cluster from a federation
|
||||
|
||||
### Synopsis
|
||||
|
||||
|
||||
Unjoin a cluster from a federation.
|
||||
|
||||
Current context is assumed to be a federation endpoint.
|
||||
Please use the --context flag otherwise.
|
||||
|
||||
```
|
||||
kubefed unjoin CLUSTER_NAME --host-cluster-context=HOST_CONTEXT
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
# Unjoin the specified cluster from a federation.
|
||||
# Federation control plane's host cluster context name
|
||||
# must be specified via the --host-cluster-context flag
|
||||
# to properly cleanup the credentials.
|
||||
kubectl unjoin foo --host-cluster-context=bar --cluster-context=baz
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--cluster-context string Name of the cluster's context in the local kubeconfig. Defaults to cluster name if unspecified.
|
||||
--federation-system-namespace string Namespace in the host cluster where the federation system components are installed (default "federation-system")
|
||||
--host-cluster-context string Host cluster context
|
||||
--kubeconfig string Path to the kubeconfig file to use for CLI requests.
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--alsologtostderr log to standard error as well as files
|
||||
--as string Username to impersonate for the operation
|
||||
--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
|
||||
--certificate-authority string Path to a cert file for the certificate authority
|
||||
--client-certificate string Path to a client certificate file for TLS
|
||||
--client-key string Path to a client key file for TLS
|
||||
--cloud-provider-gce-lb-src-cidrs cidrs CIDRS opened in GCE firewall for LB traffic proxy & health checks (default 209.85.152.0/22,209.85.204.0/22,130.211.0.0/22,35.191.0.0/16)
|
||||
--cluster string The name of the kubeconfig cluster to use
|
||||
--context string The name of the kubeconfig context to use
|
||||
--insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
|
||||
--log-backtrace-at traceLocation when logging hits line file:N, emit a stack trace (default :0)
|
||||
--log-dir string If non-empty, write log files in this directory
|
||||
--log-flush-frequency duration Maximum number of seconds between log flushes (default 5s)
|
||||
--logtostderr log to standard error instead of files (default true)
|
||||
--match-server-version Require server version to match client version
|
||||
-n, --namespace string If present, the namespace scope for this CLI request
|
||||
--password string Password for basic authentication to the API server
|
||||
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
|
||||
-s, --server string The address and port of the Kubernetes API server
|
||||
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
|
||||
--token string Bearer token for authentication to the API server
|
||||
--user string The name of the kubeconfig user to use
|
||||
--username string Username for basic authentication to the API server
|
||||
-v, --v Level log level for V logs
|
||||
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
* [kubefed](kubefed.md) - kubefed controls a Kubernetes Cluster Federation
|
||||
|
||||
###### Auto generated by spf13/cobra on 30-Jul-2017
|
||||
@@ -0,0 +1,63 @@
|
||||
## kubefed version
|
||||
|
||||
Print the client and server version information
|
||||
|
||||
### Synopsis
|
||||
|
||||
|
||||
Print the client and server version information for the current context
|
||||
|
||||
```
|
||||
kubefed version
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
# Print the client and server versions for the current context
|
||||
kubectl version
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--client Client version only (no server required).
|
||||
--output string output format, options available are yaml and json
|
||||
--short Print just the version number.
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--alsologtostderr log to standard error as well as files
|
||||
--as string Username to impersonate for the operation
|
||||
--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
|
||||
--certificate-authority string Path to a cert file for the certificate authority
|
||||
--client-certificate string Path to a client certificate file for TLS
|
||||
--client-key string Path to a client key file for TLS
|
||||
--cloud-provider-gce-lb-src-cidrs cidrs CIDRS opened in GCE firewall for LB traffic proxy & health checks (default 209.85.152.0/22,209.85.204.0/22,130.211.0.0/22,35.191.0.0/16)
|
||||
--cluster string The name of the kubeconfig cluster to use
|
||||
--context string The name of the kubeconfig context to use
|
||||
--insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
|
||||
--kubeconfig string Path to the kubeconfig file to use for CLI requests.
|
||||
--log-backtrace-at traceLocation when logging hits line file:N, emit a stack trace (default :0)
|
||||
--log-dir string If non-empty, write log files in this directory
|
||||
--log-flush-frequency duration Maximum number of seconds between log flushes (default 5s)
|
||||
--logtostderr log to standard error instead of files (default true)
|
||||
--match-server-version Require server version to match client version
|
||||
-n, --namespace string If present, the namespace scope for this CLI request
|
||||
--password string Password for basic authentication to the API server
|
||||
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
|
||||
-s, --server string The address and port of the Kubernetes API server
|
||||
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
|
||||
--token string Bearer token for authentication to the API server
|
||||
--user string The name of the kubeconfig user to use
|
||||
--username string Username for basic authentication to the API server
|
||||
-v, --v Level log level for V logs
|
||||
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
* [kubefed](kubefed.md) - kubefed controls a Kubernetes Cluster Federation
|
||||
|
||||
###### Auto generated by spf13/cobra on 30-Jul-2017
|
||||
@@ -14,7 +14,7 @@ This is a lightweight version of a broader Cluster Federation feature (previousl
|
||||
nickname ["Ubernetes"](https://git.k8s.io/community/contributors/design-proposals/federation.md)).
|
||||
Full Cluster Federation allows combining separate
|
||||
Kubernetes clusters running in different regions or cloud providers
|
||||
(or on-premise data centers). However, many
|
||||
(or on-premises data centers). However, many
|
||||
users simply want to run a more available Kubernetes cluster in multiple zones
|
||||
of their single cloud provider, and this is what the multizone support in 1.2 allows
|
||||
(this previously went by the nickname "Ubernetes Lite").
|
||||
|
||||
@@ -99,7 +99,7 @@ Troubleshooting:
|
||||
- Verify all requirements above.
|
||||
- Get $REGION (e.g. `us-west-2`) credentials on your workstation. SSH into the host and run Docker manually with those creds. Does it work?
|
||||
- Verify kubelet is running with `--cloud-provider=aws`.
|
||||
- Check kubelet logs (e.g. `journalctl -t kubelet`) for log lines like:
|
||||
- Check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like:
|
||||
- `plugins.go:56] Registering credential provider: aws-ecr-key`
|
||||
- `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
|
||||
|
||||
|
||||
@@ -26,6 +26,17 @@ different flags and/or different memory and cpu requests for different hardware
|
||||
|
||||
## Writing a DaemonSet Spec
|
||||
|
||||
### Create a DeamonSet
|
||||
|
||||
You can describe a DeamonSet in a YAML file. For example, the deamonset.yaml file below describes a DeamonSet that runs the fluentd-elasticsearch Docker image:
|
||||
|
||||
{% include code.html language="yaml" file="deamonset.yaml" ghlink="/docs/concepts/workloads/controllers/deamonset.yaml" %}
|
||||
|
||||
* Create a DeamonSet based on the YAML file:
|
||||
```
|
||||
kubectl create -f deamonset.yaml
|
||||
```
|
||||
|
||||
### Required Fields
|
||||
|
||||
As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields. For
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: DaemonSet
|
||||
metadata:
|
||||
name: fluentd-elasticsearch
|
||||
namespace: kube-system
|
||||
labels:
|
||||
k8s-app: fluentd-logging
|
||||
spec:
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
name: fluentd-elasticsearch
|
||||
spec:
|
||||
containers:
|
||||
- name: fluentd-elasticsearch
|
||||
image: gcr.io/google-containers/fluentd-elasticsearch:1.20
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 100m
|
||||
memory: 200Mi
|
||||
volumeMounts:
|
||||
- name: varlog
|
||||
mountPath: /var/log
|
||||
- name: varlibdockercontainers
|
||||
mountPath: /var/lib/docker/containers
|
||||
readOnly: true
|
||||
terminationGracePeriodSeconds: 30
|
||||
volumes:
|
||||
- name: varlog
|
||||
hostPath:
|
||||
path: /var/log
|
||||
- name: varlibdockercontainers
|
||||
hostPath:
|
||||
path: /var/lib/docker/containers
|
||||
@@ -7,14 +7,13 @@ title: Deployments
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
|
||||
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) (the next-generation ReplicationController).
|
||||
You describe the desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to
|
||||
create new ReplicaSets, or remove existing Deployments and adopt all their resources with new Deployments.
|
||||
A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
|
||||
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
|
||||
|
||||
**Note:** You should not manage ReplicaSets owned by a Deployment. If you do so, you are racing with the Deployment
|
||||
controller! All the use cases should be covered by manipulating the Deployment object. Consider opening
|
||||
an issue in the main Kubernetes repository if your use case is not covered below.
|
||||
You describe a _desired state_ in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
|
||||
|
||||
**Note:** You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
|
||||
{: .note}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -23,7 +22,7 @@ an issue in the main Kubernetes repository if your use case is not covered below
|
||||
|
||||
## Use Case
|
||||
|
||||
A typical use case is:
|
||||
The following are typical use cases for Deployments:
|
||||
|
||||
* [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
|
||||
* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
|
||||
@@ -106,10 +105,12 @@ The created ReplicaSet ensures that there are three nginx Pods at all times.
|
||||
StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
|
||||
controllers have overlapping selectors, those controllers may fight with each other and won't behave
|
||||
correctly.
|
||||
{: .note}
|
||||
|
||||
### Pod-template-hash label
|
||||
|
||||
**Note:** This label is not meant to be changed by users!
|
||||
**Note:** Do not change this label.
|
||||
{: .note}
|
||||
|
||||
Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
|
||||
Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child
|
||||
@@ -121,6 +122,7 @@ and in any existing Pods that the ReplicaSet may have.
|
||||
|
||||
**Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
|
||||
is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
|
||||
{: .note}
|
||||
|
||||
Suppose that we now want to update the nginx Pods to use the `nginx:1.9.1` image
|
||||
instead of the `nginx:1.7.9` image.
|
||||
@@ -268,6 +270,7 @@ for example if you update the labels or container images of the template. Other
|
||||
do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling.
|
||||
This means that when you roll back to an earlier revision, only the Deployment's pod template part is
|
||||
rolled back.
|
||||
{: .note}
|
||||
|
||||
Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
|
||||
|
||||
@@ -313,6 +316,7 @@ ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` speci
|
||||
Kubernetes by default sets the value to 1 and spec.replicas to 1 so if you haven't cared about setting those
|
||||
parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
|
||||
version.
|
||||
{: .note}
|
||||
|
||||
```shell
|
||||
$ kubectl describe deployment
|
||||
@@ -579,6 +583,7 @@ nginx-3926361531 3 3 3 28s
|
||||
```
|
||||
|
||||
**Note:** You cannot rollback a paused Deployment until you resume it.
|
||||
{: .note}
|
||||
|
||||
## Deployment status
|
||||
|
||||
@@ -652,10 +657,12 @@ See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/d
|
||||
**Note:** Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
||||
`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
|
||||
example, rollback the Deployment to its previous version.
|
||||
{: .note}
|
||||
|
||||
**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
|
||||
safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
|
||||
deadline.
|
||||
{: .note}
|
||||
|
||||
You may experience transient errors with your Deployments, either due to a low timeout that you have set or
|
||||
due to any other kind of error that can be treated as transient. For example, let's suppose you have
|
||||
@@ -758,7 +765,7 @@ all revision history will be kept. In a future version, it will default to switc
|
||||
|
||||
**Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
|
||||
thus that Deployment will not be able to roll back.
|
||||
|
||||
{: .note}
|
||||
|
||||
## Use Cases
|
||||
|
||||
@@ -809,6 +816,7 @@ Pods with `.spec.template` if the number of Pods is less than the desired number
|
||||
**Note:** You should not create other pods whose labels match this selector, either directly, by creating
|
||||
another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
|
||||
do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.
|
||||
{: .note}
|
||||
|
||||
If you have multiple controllers that have overlapping selectors, the controllers will fight with each
|
||||
other and won't behave correctly.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Installing Kubernetes On-premise/Cloud Providers with Kubespray
|
||||
title: Installing Kubernetes On-premises/Cloud Providers with Kubespray
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -136,7 +136,7 @@ This config file needs to be placed in the shared directory which should be acce
|
||||
scsicontrollertype = pvscsi
|
||||
```
|
||||
|
||||
Note: **```vm-name``` parameter is introduced in 1.6.4 release.** Both ```vm-uuid``` and ```vm-name``` are optional parameters. if ```vm-name``` is specified then ```vm-uuid``` is not used. if both are not specified then kubelet will get vm-uuid from `/sys/class/dmi/id/product_serial` and query vCenter to find the Node VM's name.
|
||||
Note: **```vm-name``` parameter is introduced in 1.6.4 release.** Both ```vm-uuid``` and ```vm-name``` are optional parameters. If ```vm-name``` is specified then ```vm-uuid``` is not used. If both are not specified then kubelet will get vm-uuid from `/sys/class/dmi/id/product_serial` and query vCenter to find the Node VM's name.
|
||||
|
||||
**```vsphere.conf``` for Worker Nodes:** (Only Applicable to 1.6.4 release and above. For older releases this file should have all the parameters specified in Master node's ```vSphere.conf``` file)
|
||||
|
||||
@@ -159,7 +159,7 @@ Below is summary of supported parameters in the `vsphere.conf` file
|
||||
**Note:** ```vm-name``` is added in the release 1.6.4. Prior releases does not support this parameter.
|
||||
|
||||
* ```working-dir``` can be set to empty ( working-dir = ""), if Node VMs are located in the root VM folder.
|
||||
* ```vm-uuid``` is the VM Instance UUID of virtual machine. ```vm-uuid``` can be set to empty (```vm-uuid = ""```). if set to empty, this will be retrieved from /sys/class/dmi/id/product_serial file on virtual machine (requires root access).
|
||||
* ```vm-uuid``` is the VM Instance UUID of virtual machine. ```vm-uuid``` can be set to empty (```vm-uuid = ""```). If set to empty, this will be retrieved from /sys/class/dmi/id/product_serial file on virtual machine (requires root access).
|
||||
|
||||
* ```vm-uuid``` needs to be set in this format - ```423D7ADC-F7A9-F629-8454-CE9615C810F1```
|
||||
|
||||
|
||||
+2
-2
@@ -20,8 +20,8 @@ Other/newer ways to set up a Kubernetes cluster include:
|
||||
* [Minikube](/docs/getting-started-guides/minikube/): Install a single-node Kubernetes cluster on your local machine for development and testing.
|
||||
* [Installing Kubernetes on AWS with kops](/docs/getting-started-guides/kops/): Bring up a complete Kubernetes cluster on Amazon Web Services, using a tool called `kops`.
|
||||
* [Installing Kubernetes on Linux with kubeadm](/docs/getting-started-guides/kubeadm/) (Beta): Install a secure Kubernetes cluster on any pre-existing machines running Linux, using the built-in `kubeadm` tool.
|
||||
* [Installing Kubernetes On-premise/Cloud Providers with Kubespray](/docs/getting-started-guides/kubespray/): Deploy a Kubernetes cluster on-premises baremetal or hosted on cloud providers, with Ansible and `kubespray` tools.
|
||||
* [Installing Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/): Deploy a Kubernetes cluster on-premise, baremetal, cloud providers, or localhost with Charms and `conjure-up`.
|
||||
* [Installing Kubernetes On-premises/Cloud Providers with Kubespray](/docs/getting-started-guides/kubespray/): Deploy a Kubernetes cluster on-premises baremetal or hosted on cloud providers, with Ansible and `kubespray` tools.
|
||||
* [Installing Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/): Deploy a Kubernetes cluster on-premises, baremetal, cloud providers, or localhost with Charms and `conjure-up`.
|
||||
|
||||
## Concepts, Tasks, and Tutorials
|
||||
|
||||
|
||||
@@ -25,7 +25,8 @@ client libraries:
|
||||
|
||||
* [kubectl](/docs/user-guide/kubectl-overview) - Main CLI tool for running commands and managing Kubernetes clusters.
|
||||
* [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
|
||||
* [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster
|
||||
* [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
|
||||
* [kubefed](/docs/admin/kubefed/) - CLI tool to help you administrate your federated clusters.
|
||||
|
||||
## Config Reference
|
||||
|
||||
|
||||
@@ -132,7 +132,7 @@ These solutions provide integration with third-party schedulers, resource manage
|
||||
* Instructions specify GCE, but are generic enough to be adapted to most existing Mesos clusters
|
||||
* [DCOS](/docs/getting-started-guides/dcos)
|
||||
* Community Edition DCOS uses AWS
|
||||
* Enterprise Edition DCOS supports cloud hosting, on-premise VMs, and bare metal
|
||||
* Enterprise Edition DCOS supports cloud hosting, on-premises VMs, and bare metal
|
||||
|
||||
# Table of Solutions
|
||||
|
||||
|
||||
@@ -1,10 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Authenticate Across Clusters with kubeconfig
|
||||
title: Authenticate across clusters with kubeconfig
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
Authentication in Kubernetes can differ for different individuals.
|
||||
|
||||
- A running kubelet might have one way of authenticating (i.e. certificates).
|
||||
@@ -17,11 +15,13 @@ So in order to easily switch between multiple clusters, for multiple users, a ku
|
||||
This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
|
||||
|
||||
Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging-rules) below).
|
||||
{% endcapture %}
|
||||
|
||||
## Related discussion
|
||||
|
||||
[http://issue.k8s.io/1755](http://issue.k8s.io/1755)
|
||||
{% capture prerequisites %}
|
||||
* {% include task-tutorial-prereqs.md %}
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
## Components of a kubeconfig file
|
||||
|
||||
### Example kubeconfig file
|
||||
@@ -164,25 +164,24 @@ the settings relevant to the `current-context` by passing `--minify`. See
|
||||
|
||||
## Building your own kubeconfig file
|
||||
|
||||
NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you.
|
||||
You can use the [sample kubeconfig file](#example-kubeconfig-file) above as a template for your own kubeconfig files.
|
||||
|
||||
In any case, you can easily use this file as a template to create your own kubeconfig files.
|
||||
**Note:** If you're deploying Kubernetes with `kube-up.sh`, you don't need to create your own kubeconfig files—the script does it for you.
|
||||
{: .note}
|
||||
|
||||
So, lets do a quick walk through the basics of the above file so you can easily modify it as needed...
|
||||
|
||||
The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this:
|
||||
The sample file corresponds to an [API server](https://kubernetes.io/docs/admin/kube-apiserver/) launched using the `--token-auth-file=tokens.csv` option, where the `tokens.csv` file contains:
|
||||
|
||||
```conf
|
||||
blue-user,blue-user,1
|
||||
mister-red,mister-red,2
|
||||
```
|
||||
|
||||
Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes).
|
||||
**Note:** There are many [options available](https://kubernetes.io/docs/admin/kube-apiserver/) for launching an API server. Make sure you understand the options you include.
|
||||
{: .note}
|
||||
|
||||
- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials.
|
||||
- Similarly, we can operate as the "blue-user" if we choose to change the value of current-context.
|
||||
The sample kubeconfig file provides client credentials for the user `green-user`. Because the user for `current-context` is `green-user`, any client of the API server using the sample kubeconfig file could log in successfully. Similarly, we can operate as `blue-user` by changing the value of `current-context`.
|
||||
|
||||
In the above scenario, green-user would have to log in by providing certificates, whereas blue-user would just provide the token. All this information would be handled for us by the
|
||||
In the example provided, `green-user` logs in by providing certificates, and `blue-user` provides a token. Login information is specified with the `kubectl config set-credentials` command. For more information, see "[Commands for the example file](#commands-for-the-example-file)".
|
||||
|
||||
## Loading and merging rules
|
||||
|
||||
@@ -198,7 +197,7 @@ The rules for loading and merging the kubeconfig files are straightforward, but
|
||||
Merge files together based on the following rules.
|
||||
Empty filenames are ignored. Files with non-deserializable content produced errors.
|
||||
The first file to set a particular value or map key wins and the value or map key is never changed.
|
||||
This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a "red-user", only values from the first file's red-user are used. Even non-conflicting entries from the second file's "red-user" are discarded.
|
||||
This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a `red-user`, only values from the first file's `red-user` are used. Even non-conflicting entries from the second file's `red-user` are discarded.
|
||||
|
||||
|
||||
Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging.
|
||||
@@ -302,8 +301,10 @@ $ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=bla
|
||||
$ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns
|
||||
$ kubectl config use-context federal-context
|
||||
```
|
||||
{% endcapture %}
|
||||
|
||||
### Final notes for tying it all together
|
||||
{% capture discussion %}
|
||||
## Final notes for tying it all together
|
||||
|
||||
So, tying this all together, a quick start to create your own kubeconfig file:
|
||||
|
||||
@@ -311,4 +312,10 @@ So, tying this all together, a quick start to create your own kubeconfig file:
|
||||
|
||||
- Replace the snippet above with information for your cluster's api-server endpoint.
|
||||
|
||||
- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
|
||||
- Make sure your api-server provides at least one set of credentials (for example, `green-user`) when launched. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
|
||||
|
||||
## Related discussion
|
||||
[http://issue.k8s.io/1755](http://issue.k8s.io/1755)
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
@@ -22,7 +22,7 @@ unresponsive clusters).
|
||||
Federated Ingress is released as an alpha feature, and supports Google Cloud Platform (GKE,
|
||||
GCE and hybrid scenarios involving both) in Kubernetes v1.4. Work is under way to support other cloud
|
||||
providers such as AWS, and other hybrid cloud scenarios (e.g. services
|
||||
spanning private on-premise as well as public cloud Kubernetes
|
||||
spanning private on-premises as well as public cloud Kubernetes
|
||||
clusters).
|
||||
|
||||
You create Federated Ingresses in much that same way as traditional
|
||||
@@ -303,7 +303,3 @@ Check that:
|
||||
[Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md).
|
||||
{% endcapture %}
|
||||
{% include templates/task.md %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -43,7 +43,8 @@ The output contains a section similar to this:
|
||||
}
|
||||
}
|
||||
|
||||
NOTE: If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
|
||||
**Note:** If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
|
||||
{: .note}
|
||||
|
||||
## Create a Secret that holds your authorization token
|
||||
|
||||
|
||||
@@ -35,13 +35,13 @@ annotations["federation.kubernetes.io/replica-set-preferences"] = preferences {
|
||||
#
|
||||
# In English, the policy asserts that resources in the "production" namespace
|
||||
# that are not annotated with "criticality=low" MUST be placed on clusters
|
||||
# labelled with "on-premise=true".
|
||||
# labelled with "on-premises=true".
|
||||
annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector {
|
||||
input.metadata.namespace = "production"
|
||||
not input.metadata.annotations.criticality = "low"
|
||||
json.marshal([{
|
||||
"operator": "=",
|
||||
"key": "on-premise",
|
||||
"key": "on-premises",
|
||||
"values": "[true]",
|
||||
}], selector)
|
||||
}
|
||||
|
||||
@@ -29,18 +29,22 @@ Nvidia GPUs can be consumed via container level resource requirements using the
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: pod
|
||||
spec:
|
||||
containers:
|
||||
-
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: gpu-pod
|
||||
spec:
|
||||
containers:
|
||||
-
|
||||
name: gpu-container-1
|
||||
resources:
|
||||
limits:
|
||||
image: gcr.io/google_containers/pause:2.0
|
||||
resources:
|
||||
limits:
|
||||
alpha.kubernetes.io/nvidia-gpu: 2 # requesting 2 GPUs
|
||||
-
|
||||
name: gpu-container-2
|
||||
resources:
|
||||
limits:
|
||||
image: gcr.io/google_containers/pause:2.0
|
||||
resources:
|
||||
limits:
|
||||
alpha.kubernetes.io/nvidia-gpu: 3 # requesting 3 GPUs
|
||||
```
|
||||
|
||||
|
||||
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 295 KiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 7.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.4 KiB After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.9 KiB After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.8 KiB After Width: | Height: | Size: 21 KiB |
+1
-1
@@ -50,7 +50,7 @@ cid: home
|
||||
<div class="image-wrapper"><img src="images/suitcase.png"></div>
|
||||
<div class="content">
|
||||
<h4>Run Anywhere</h4>
|
||||
<p>Kubernetes is open source giving you the freedom to take advantage of on-premise, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.</p>
|
||||
<p>Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.</p>
|
||||
</div>
|
||||
</main>
|
||||
</section>
|
||||
|
||||
@@ -4,6 +4,12 @@ docs/getting-started-guides/docker.md
|
||||
docs/getting-started-guides/docker-multinode.md
|
||||
docs/user-guide/configmap/README.md
|
||||
docs/user-guide/downward-api/README.md
|
||||
docs/admin/kubefed_unjoin.md
|
||||
docs/admin/kubefed_init.md
|
||||
docs/admin/kubefed.md
|
||||
docs/admin/kubefed_join.md
|
||||
docs/admin/kubefed_options.md
|
||||
docs/admin/kubefed_version.md
|
||||
docs/api-reference/extensions/v1beta1/definitions.md
|
||||
docs/api-reference/extensions/v1beta1/operations.md
|
||||
docs/api-reference/v1/definitions.md
|
||||
|
||||
Reference in New Issue
Block a user