Merge branch 'master' into release-1.8
This commit is contained in:
steveperry-53
+1
-10
@@ -1,6 +1,6 @@
|
||||
language: go
|
||||
go:
|
||||
- 1.8.1
|
||||
- 1.8.3
|
||||
|
||||
# Don't want default ./... here:
|
||||
install:
|
||||
@@ -15,15 +15,6 @@ install:
|
||||
- cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
|
||||
- rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
|
||||
|
||||
# (2) Fetch md-check along with all its dependencies.
|
||||
- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check
|
||||
- go get -t -v k8s.io/md-check
|
||||
|
||||
# (3) Fetch mungedocs
|
||||
- go get -v k8s.io/kubernetes/cmd/mungedocs
|
||||
|
||||
script:
|
||||
- go test -v k8s.io/kubernetes.github.io/test
|
||||
- $GOPATH/bin/md-check --root-dir=$HOME/gopath/src/k8s.io/kubernetes.github.io
|
||||
- ./verify-docs-format.sh
|
||||
- $GOPATH/bin/mungedocs --verbose --verify --upstream=origin --root-dir=$HOME/gopath/src/k8s.io/kubernetes.github.io/docs/ --repo-root=$HOME/gopath/src/k8s.io/kubernetes.github.io --skip-munges=remove-whitespace,blank-lines-surround-preformatted,header-lines,sync-examples,analytics,analytics,kubectl-dash-f,table-of-contents,md-links,kubectl-dash-f
|
||||
|
||||
@@ -15,4 +15,4 @@ serve: ## Boot the development server.
|
||||
jekyll serve
|
||||
|
||||
stage: ## Run the Jekyll staging container.
|
||||
docker run -ti --rm -v "$PWD":/k8sdocs -p 4000:4000 gcr.io/google-samples/k8sdocs:1.1
|
||||
docker run -ti --rm -v "${PWD}":/k8sdocs -p 4000:4000 gcr.io/google-samples/k8sdocs:1.1
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
- Fundamental
|
||||
- API Object
|
||||
- Metadata
|
||||
- Configuration
|
||||
- Security
|
||||
- Networking
|
||||
- Storage
|
||||
- Operation
|
||||
- Workload
|
||||
- Component
|
||||
- API
|
||||
- Extension
|
||||
@@ -1,30 +0,0 @@
|
||||
canonical-tags:
|
||||
- Fundamental
|
||||
- API Object
|
||||
- Metadata
|
||||
- Configuration
|
||||
- Security
|
||||
- Networking
|
||||
- Storage
|
||||
- Operation
|
||||
- Workload
|
||||
- Component
|
||||
- API
|
||||
- Extension
|
||||
|
||||
# TODO: Add list of glossary terms here
|
||||
# (to avoid writing a function that iterates through all glossary term pages)
|
||||
# e.g.
|
||||
# terms:
|
||||
# - name: StatefulSets
|
||||
# tags:
|
||||
# - Storage
|
||||
# - Workload
|
||||
# - API Object
|
||||
# - name: Aggregation Layer
|
||||
# tags:
|
||||
# - API
|
||||
# - Component
|
||||
# - Extension
|
||||
#
|
||||
# See https://github.com/kubernetes/kubernetes.github.io/projects/4 for details.
|
||||
@@ -0,0 +1,17 @@
|
||||
id: _example
|
||||
name: Example K8s Term
|
||||
formerly:
|
||||
- Slang K8s Term
|
||||
- Misnomer
|
||||
- Formerly Known as Prince
|
||||
related:
|
||||
- Less Fancy K8s Term
|
||||
- Tangential Term
|
||||
- Commonly Used With
|
||||
tags:
|
||||
- Some Tag
|
||||
short-description: |
|
||||
Required. One or two lines that provide a minimum definition. Do not repeat the term. Write about the plural of the term. Prefer fragments. Model after tooltips. End with a period.
|
||||
long-description: |
|
||||
Optional. Longer additional text to appear after (in conjunction with) short description. Provide where the short description is not sufficient as the intro paragraph to a topic. Write complete but concise sentences.
|
||||
**See /_includes/templates/glossary/README.md for the official style guide.**
|
||||
@@ -0,0 +1,18 @@
|
||||
id: statefulset
|
||||
name: StatefulSet
|
||||
formerly:
|
||||
- PetSet
|
||||
related:
|
||||
- Deployment
|
||||
- Pod
|
||||
tags:
|
||||
- Storage
|
||||
- Workload
|
||||
- API Object
|
||||
short-description: |
|
||||
Manage the deployment and scaling of a set of Pods, *and provide guarantees about ordering*. They do so by maintaining a *unique*, sticky identity for each of their Pods.
|
||||
|
||||
long-description: |
|
||||
Like Deployments, StatefulSets manage Pods that are based on an identical container spec. However, although their specs are the same, the Pods in a StatefulSet are not interchangeable. Each Pod has a persistent identifier that it maintains across any rescheduling.
|
||||
|
||||
StatefulSets also operate according to the Controller pattern. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to the get there from the current state.
|
||||
@@ -1,24 +0,0 @@
|
||||
|
||||
---
|
||||
term: Some Fancy K8s Term
|
||||
formerly:
|
||||
- Slang K8s Term
|
||||
- Misnomer
|
||||
- Formerly Known as Prince
|
||||
related:
|
||||
- Less Fancy K8s Term
|
||||
- Tangential Term
|
||||
- Commonly Used With
|
||||
---
|
||||
|
||||
{% capture short-description %}
|
||||
Required. One or two lines that provide a minimum definition. Do not repeat the term. Prefer fragments. Model after tooltips.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture long-description %}
|
||||
Optional. Longer additional text to appear after (in conjunction with) short description. Provide where the short description is not sufficient as the intro paragraph to a topic. Write complete but concise sentences.
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed hendrerit dictum nisi quis posuere. Integer eleifend neque lobortis ultrices viverra. Praesent viverra placerat ex sit amet aliquet. Aliquam non ipsum ut lectus viverra pulvinar id vitae nisi. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Suspendisse aliquet congue tristique. Pellentesque at condimentum orci, iaculis pellentesque urna. Aliquam ut rhoncus lorem, a tristique est. Quisque eu est sem.
|
||||
|
||||
Suspendisse id feugiat orci. Etiam in posuere arcu, id euismod velit. Etiam pulvinar lectus at diam porta, non lobortis dolor blandit. Donec id faucibus elit. Suspendisse auctor ligula purus, id aliquam odio vehicula a. Donec pretium ligula at nulla pulvinar, sed ultrices ligula dapibus. Cras lacinia mauris ut metus rutrum volutpat. Sed fermentum lobortis ipsum, in hendrerit lectus consectetur sed. Aliquam pulvinar tortor tellus, ac luctus est euismod congue. Maecenas enim ipsum, maximus a turpis eu, blandit imperdiet lacus.
|
||||
{% endcapture %}
|
||||
@@ -0,0 +1,15 @@
|
||||
<!-- Use include_cached when incorporating this file, in order to reduce computation/build time -->
|
||||
|
||||
{% assign glossary_terms = site.data.glossary | where_exp: "term", "term.id != '_example'" %}
|
||||
|
||||
{% assign tag_map = "" | split: " " %}
|
||||
|
||||
{% for tag in site.data.canonical-tags %}
|
||||
|
||||
{% assign term_list = glossary_terms | where_exp:"term", "term.tags contains tag" | map: "id" %}
|
||||
|
||||
{% assign tag_obj = "" | split: " " | push: tag | push: term_list %}
|
||||
|
||||
{% assign tag_map = tag_map | push: tag_obj %}
|
||||
|
||||
{% endfor %}
|
||||
@@ -0,0 +1,62 @@
|
||||
# Kubernetes Glossary
|
||||
|
||||
To write a glossary snippet, start with a copy of the template, [`/_data/glossary/_example.yml`](/_data/glossary/_example.yml). Make sure to provide (or omit) values for the following fields:
|
||||
|
||||
* (Required) `id`.
|
||||
* This field must match the name of the glossary file itself (without the `*.yml` extension). It is *not* intended to be displayed to users, and is only used programmatically.
|
||||
* (Required) `name`.
|
||||
* The name of the term.
|
||||
* (Required) `tags`.
|
||||
* Must be one of the tags listed in kubernetes.github.io/_data/canonical-terms-tags.yml.
|
||||
* (Required) `short description`.
|
||||
* Make sure to replace the instructional text in the template with your content.
|
||||
* (Optional) `formerly` and `related`.
|
||||
* If you do not provide these values, remove the fields.
|
||||
* (Optional) `long description`.
|
||||
* If you do not provide a long description, remove the field -- that is, the complete key-value pair.
|
||||
|
||||
The `_example.yml` template also contains basic information about how to write your snippet. For additional guidance, continue reading this readme.
|
||||
|
||||
## Glossary snippet style guide
|
||||
|
||||
This style guide supplements the guidance provided in the glossary template. It's intended to help you think about what and how to write glossary definitions. For more general guidance on style, consult [the core docs style guide](https://kubernetes.io/docs/home/contribute/style-guide/).
|
||||
|
||||
### Minimum viable snippet:
|
||||
|
||||
Every snippet must include at least the short description. The long description is optional, but should be provided for terms that need additional clarification. For consistency with existing *Concept* definitions, *write your definitions as if the term is plural*.
|
||||
|
||||
**short-description** (Required): One line (or two short lines) that provides a minimum definition. Do not repeat the term. Prefer fragments. Model after tooltips. End with a period.
|
||||
|
||||
**long-description** (Optional): Longer additional text to appear after (in conjunction with) short description. Provide in cases where the short description is not sufficient for the intro paragraph to a topic. Write complete but concise sentences.
|
||||
|
||||
### Examples
|
||||
|
||||
```yaml
|
||||
- name: Pod
|
||||
- tags:
|
||||
- Fundamental
|
||||
- Workload
|
||||
- API Object
|
||||
- short-description: The smallest and simplest Kubernetes objects. Represent a set of running processes on your cluster.
|
||||
- long-description: Pods most often run only a single container, and are managed by a Deployment.
|
||||
```
|
||||
|
||||
```yaml
|
||||
- name: Deployment
|
||||
- tags:
|
||||
- Fundamental
|
||||
- Workload
|
||||
- API Object
|
||||
- short-description: Controllers that provide declarative updates for Pods and ReplicaSets.
|
||||
- long-description: Deployments are responsible for creating and updating instances of an application.
|
||||
```
|
||||
|
||||
### Thinking about definitions
|
||||
|
||||
* **Think of the short description as it would appear in a tooltip.** Is it sufficient to get the reader started? Is it short enough to be read inside a small UI element?
|
||||
|
||||
*Tip*: look at the API reference doc content (for example, https://kubernetes.io/docs/api-reference/v1.7/). Note, however, that this content should be used with care. The concept docs for Pod, for example, are clearer than the reference docs.
|
||||
|
||||
* **The long description should follow the short description to make a complete introduction to a topic.** (This is the content that appears at the top of the content, before any generated TOC.) Does it provide information that's not already clear from the short description? Does it provide information that readers should have a general sense of before they dive into the details of the topic it helps introduce?
|
||||
|
||||
*Tip:* the long description does not need to be long; it's intended to extend but not replace the short description. Look through current related docs for ideas. (The Deployment long description is taken from a tutorial, for example.)
|
||||
@@ -0,0 +1,10 @@
|
||||
### ERROR: You must define a <span style="font-family: monospace">`{{ include.missing_block }}`</span> field
|
||||
{: style="color:red" }
|
||||
|
||||
The glossary template requires that you provide text that {{ include.purpose }}.
|
||||
|
||||
To get rid of this message and take advantage of this template, define the `{{ include.missing_block }}`
|
||||
field for the `{{ include.term }}` glossary term and populate it with content.
|
||||
|
||||
See `_data/glossary/_example.yml` for reference.
|
||||
<!-- TEMPLATE_ERROR -->
|
||||
@@ -0,0 +1,25 @@
|
||||
{% assign term_data = site.data.glossary.[include.term] %}
|
||||
|
||||
{% if term_data.short-description %}
|
||||
|
||||
{{ term_data.short-description | markdownify }}
|
||||
|
||||
{% else %}
|
||||
|
||||
{% include templates/glossary/_error.md term=term_data.name missing_block='short-description' purpose='concisely describes the key term in 1-2 lines' %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% if include.length == "long" %}
|
||||
|
||||
{% if term_data.long-description %}
|
||||
|
||||
{{ term_data.long-description | markdownify }}
|
||||
|
||||
{% else %}
|
||||
|
||||
{% include templates/glossary/_error.md term=term_data.name missing_block='long-description' purpose='describes the key term in greater depth, supplementing the short-description' %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endif %}
|
||||
@@ -34,7 +34,7 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
|
||||
The company is transitioning to cloud native infrastructure, using <a href="https://www.docker.com">Docker</a> containerization, <a href="https://kubernetes.io">Kubernetes</a> orchestration and <a href="https://prometheus.io">Prometheus</a> for cluster monitoring.<br>
|
||||
<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."
|
||||
"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 significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
@@ -26,7 +26,7 @@ css: /css/style_box.css
|
||||
<div class="col1">
|
||||
|
||||
<h2>Challenge</h2>
|
||||
Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <a href="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company’s own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It’s been a huge challenge because different clouds, especially bare metal, have very different interfaces."
|
||||
Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <a href="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company’s own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It’s been a huge challenge because of different clouds, especially bare metal, have very different interfaces."
|
||||
<br>
|
||||
</div>
|
||||
|
||||
@@ -52,7 +52,7 @@ css: /css/style_box.css
|
||||
<div class="fullcol">
|
||||
<h2>In the summer of 2014, Box was feeling the pain of a decade’s worth of hardware and software infrastructure that wasn’t keeping up with the company’s needs.</h2>
|
||||
|
||||
A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It’s been a huge challenge thus far because all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."<br><br>
|
||||
A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It’s been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."<br><br>
|
||||
Box’s cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.<br><br>
|
||||
At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google’s internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."<br><br>
|
||||
Another plus: Ghods liked that <a href="kubernetes.io">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."<br><br>
|
||||
@@ -69,7 +69,7 @@ css: /css/style_box.css
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that’s ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that’s going to be expanding a lot over the next 12 months, probably to many hundreds if not thousands."<br><br>
|
||||
The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that’s ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that’s going to be expanding a lot over the next 12 months, probably too many hundreds if not thousands."<br><br>
|
||||
While observing teams who began to use Kubernetes for their microservices, "we immediately saw an uptick in the number of microservices being released," Ghods notes. "There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."
|
||||
<br><br><div class="quote">"There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."</div><br>
|
||||
Ghods reflects that as early adopters, Box had a different journey from what companies experience now. "We were definitely lock step with waiting for certain things to stabilize or features to get released," he says. "In the early days we were doing a lot of contributions [to components such as kubectl apply] and waiting for Kubernetes to release each of them, and then we’d upgrade, contribute more, and go back and forth several times. The entire project took about 18 months from our first real deployment on Kubernetes to having general availability. If we did that exact same thing today, it would probably be no more than six."<br><br>
|
||||
|
||||
@@ -41,7 +41,7 @@ css: /css/style_wink.css
|
||||
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
"It’s not proprietary, it’s totally open, it’s really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There’s massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time.”<br><br><span style="font-size:15px;letter-spacing:0.08em">- KIT KLEIN, HEAD OF ENGINEERING, WINK</span>
|
||||
"It’s not proprietary, it’s totally open, it’s really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time.”<br><br><span style="font-size:15px;letter-spacing:0.08em">- KIT KLEIN, HEAD OF ENGINEERING, WINK</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -102,7 +102,7 @@ css: /css/style_wink.css
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
Wink’s reasons for going all in are clear: "It’s not proprietary, it’s totally open, it’s really portable,” Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There’s massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time.”<br><br>
|
||||
Wink’s reasons for going all in are clear: "It’s not proprietary, it’s totally open, it’s really portable,” Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time.”<br><br>
|
||||
Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people,” he says. "In order to take advantage of this, you really have to keep up with the technology. You can’t treat it like it’s a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”<br><br>
|
||||
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>
|
||||
|
||||
@@ -77,9 +77,9 @@ Cluster DNS is a DNS server, in addition to the other DNS server(s) in your envi
|
||||
|
||||
Containers started by Kubernetes automatically include this DNS server in their DNS searches.
|
||||
|
||||
#### User interface
|
||||
#### Web UI (Dashboard)
|
||||
|
||||
The kube-ui provides a read-only overview of the cluster state. For more information, see [Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
|
||||
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself.
|
||||
|
||||
|
||||
#### Container Resource Monitoring
|
||||
@@ -115,20 +115,20 @@ network rules on the host and performing connection forwarding.
|
||||
|
||||
### docker
|
||||
|
||||
docker is used for running containers.
|
||||
`docker` is used for running containers.
|
||||
|
||||
### rkt
|
||||
|
||||
rkt is supported experimentally for running containers as an alternative to docker.
|
||||
`rkt` is supported experimentally for running containers as an alternative to docker.
|
||||
|
||||
### supervisord
|
||||
|
||||
supervisord is a lightweight process monitor and control system that can be used to keep kubelet and docker
|
||||
`supervisord` is a lightweight process monitor and control system that can be used to keep kubelet and docker
|
||||
running.
|
||||
|
||||
### fluentd
|
||||
|
||||
fluentd is a daemon which helps provide [cluster-level logging](#cluster-level-logging).
|
||||
`fluentd` is a daemon which helps provide [cluster-level logging](#cluster-level-logging).
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
||||
@@ -123,7 +123,7 @@ Some possible patterns for communicating with pods in a DaemonSet are:
|
||||
|
||||
- **Push**: Pods in the DaemonSet are configured to send updates to another service, such
|
||||
as a stats database. They do not have clients.
|
||||
- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of nodes ips somehow, and know the port by convention.
|
||||
- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of node IPs somehow, and know the port by convention.
|
||||
- **DNS**: Create a [headless service](/docs/user-guide/services/#headless-services) with the same pod selector,
|
||||
and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
|
||||
DNS.
|
||||
|
||||
@@ -15,8 +15,7 @@ PetSets feature from 1.4. Users of PetSets are referred to the 1.5
|
||||
[Upgrade Guide](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/)
|
||||
for further information on how to upgrade existing PetSets to StatefulSets.**
|
||||
|
||||
A StatefulSet is a Controller that provides a unique identity to its Pods. It provides
|
||||
guarantees about the ordering of deployment and scaling.
|
||||
{% include templates/glossary/snippet.md term="statefulset" length="long" %}
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
@@ -40,6 +39,7 @@ provides a set of stateless replicas. Controllers such as
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs.
|
||||
|
||||
## Limitations
|
||||
|
||||
* StatefulSet is a beta resource, not available in any Kubernetes release prior to 1.5.
|
||||
* As with all alpha/beta resources, you can disable StatefulSet through the `--runtime-config` option passed to the apiserver.
|
||||
* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
|
||||
|
||||
@@ -125,7 +125,7 @@ Service Configuration file.
|
||||
"kind": "Service",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "example-service",
|
||||
"name": "example-service"
|
||||
},
|
||||
"spec": {
|
||||
"ports": [{
|
||||
@@ -164,6 +164,10 @@ compared to the `service.spec.externalTrafficPolicy` field. The values match as
|
||||
|
||||
**Note that this feature is not currently implemented for all cloudproviders/environments.**
|
||||
|
||||
Known issues:
|
||||
|
||||
* AWS: [kubernetes/kubernetes#35758](https://github.com/kubernetes/kubernetes/issues/35758)
|
||||
* Weave-Net: [weaveworks/weave/#2924](https://github.com/weaveworks/weave/issues/2924)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -77,7 +77,7 @@ CPU request and limit to the Container.
|
||||
|
||||
* Verify that the Container specifies a CPU request that is greater than or equal to 200 millicpu.
|
||||
|
||||
* Verify that the Container specifies a memory limit that is less than or equal to 800 millicpu.
|
||||
* Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.
|
||||
|
||||
Here's the configuration file for a Pod that has one Container. The Container manifest
|
||||
specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
|
||||
|
||||
@@ -86,6 +86,7 @@ spec:
|
||||
## Assign the policy to the service
|
||||
|
||||
Use kubectl to create a NetworkPolicy from the above nginx-policy.yaml file:
|
||||
|
||||
```console
|
||||
$ kubectl create -f nginx-policy.yaml
|
||||
networkpolicy "access-nginx" created
|
||||
|
||||
@@ -22,7 +22,6 @@ spec:
|
||||
- /cluster-proportional-autoscaler
|
||||
- --namespace=kube-system
|
||||
- --configmap=kube-dns-autoscaler
|
||||
- --mode=linear
|
||||
- --target=<SCALE_TARGET>
|
||||
# When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
|
||||
# If using small nodes, "nodesPerReplica" should dominate.
|
||||
|
||||
@@ -92,11 +92,11 @@ $ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-
|
||||
|
||||
## Best practices for replicating masters for HA clusters
|
||||
|
||||
* Try to place masters replicas in different zones. During a zone failure, all master placed inside the zone will fail.
|
||||
* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail.
|
||||
To survive zone failure, also place nodes in multiple zones
|
||||
(see [multiple-zones](/docs/admin/multiple-zones/) for details).
|
||||
|
||||
* Do not use a cluster with two master replicas. Consensus on a two replica cluster requires both replicas running when changing persistent state.
|
||||
* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state.
|
||||
As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
|
||||
A two-replica cluster is thus inferior, in terms of HA, to a single replica cluster.
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ The ip-masq-agent configures iptables rules to hide a pod's IP address behind th
|
||||
* **NAT (Network Address Translation)**
|
||||
Is a method of remapping one IP address to another by modifying either the source and/or destination address information in the IP header. Typically performed by a device doing IP routing.
|
||||
* **Masquerading**
|
||||
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In kubernetes this is the Node's IP address.
|
||||
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
|
||||
* **CIDR (Classless Inter-Domain Routing)**
|
||||
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
|
||||
* **Link Local**
|
||||
@@ -32,10 +32,10 @@ The ip-masq-agent configures iptables rules to handle masquerading node/pod IP a
|
||||
|
||||
|
||||
|
||||
The agent configuration file must be written in yaml or json syntax, and may contain three optional keys:
|
||||
The agent configuration file must be written in YAML or JSON syntax, and may contain three optional keys:
|
||||
|
||||
* **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
|
||||
* **masqLinkLocal:** A boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
|
||||
* **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
|
||||
* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
|
||||
|
||||
Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded. An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range. Any other traffic will be masqueraded by default. The below entries show the default set of rules that are applied by the ip-masq-agent:
|
||||
@@ -50,7 +50,7 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent:
|
||||
|
||||
```
|
||||
|
||||
By default, in GCE/GKE starting with Kubernetes version 1.7.0, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) to your cluster:
|
||||
By default, in GCE/GKE starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to your cluster:
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -63,6 +63,12 @@ To create an ip-masq-agent, run the following kubectl command:
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml
|
||||
`
|
||||
|
||||
You must also apply the appropriate node label to any nodes in your cluster that you want the agent to run on.
|
||||
|
||||
`
|
||||
kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
|
||||
`
|
||||
|
||||
More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent)
|
||||
|
||||
In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configmap/) to customize the IP ranges that are affected. For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configmap/) in a file called "config".
|
||||
|
||||
@@ -165,7 +165,7 @@ Ingresses in the clusters comprising your federation.
|
||||
To render the underlying ingress shards healthy, you need to add
|
||||
backend Pods behind the service upon which the Ingress is based. There are several ways to achieve this, but
|
||||
the easiest is to create a Federated Service and
|
||||
Federated Replicaset. To
|
||||
Federated ReplicaSet. To
|
||||
create appropriately labelled pods and services in the 13 underlying clusters of
|
||||
your federation:
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ similar to the following:
|
||||
|
||||
```
|
||||
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
|
||||
gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1
|
||||
* gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -145,7 +145,7 @@ kubectl rollout status ds/<daemonset-name>
|
||||
When the rollout is complete, the output is similar to this:
|
||||
|
||||
```shell
|
||||
daemon set "<daemonset-name>" successfully rolled out
|
||||
daemonset "<daemonset-name>" successfully rolled out
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
@@ -198,7 +198,7 @@ progress.
|
||||
|
||||
* See [Task: Performing a rollback on a
|
||||
DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
|
||||
* *TODO: Link to "Task: Creating a DaemonSet to adopt existing DaemonSet pods"*
|
||||
* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -49,15 +49,26 @@ a Deployment that runs the nginx:1.7.9 Docker image:
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
|
||||
Labels: app=nginx
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=nginx
|
||||
Replicas: 2 updated | 2 total | 2 available | 0 unavailable
|
||||
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
Pod Template:
|
||||
Labels: app=nginx
|
||||
Containers:
|
||||
nginx:
|
||||
Image: nginx:1.7.9
|
||||
Port: 80/TCP
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available True MinimumReplicasAvailable
|
||||
Progressing True NewReplicaSetAvailable
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
|
||||
No events.
|
||||
|
||||
@@ -111,7 +111,7 @@ Notice that the `server.csr` file created in step 1 is base64 encoded
|
||||
and stashed in the `.spec.request` field. We are also requesting a
|
||||
certificate with the "digital signature", "key encipherment", and "server
|
||||
auth" key usages. We support all key usages and extended key usages listed
|
||||
[here](https://godoc.org/k8s.io/client-go/pkg/apis/certificates/v1beta1#KeyUsage)
|
||||
[here](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)
|
||||
so you can request client certificates and other certificates using this
|
||||
same API.
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ Here are a few methods to install kubectl.
|
||||
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{page.fullversion}}/bin/windows/amd64/kubectl.exe
|
||||
|
||||
To find out the latest stable version (for example, for scripting), take a look at https://storage.googleapis.com/kubernetes-release/release/stable.txt
|
||||
To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
|
||||
|
||||
2. Add the binary in to your PATH.
|
||||
|
||||
|
||||
+5
-5
@@ -72,7 +72,7 @@ kubectl apply -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
|
||||
@@ -143,7 +143,7 @@ configuration file instead of a directory.
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
|
||||
@@ -194,7 +194,7 @@ kubectl scale deployment/nginx-deployment --replicas 2
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the `replicas` field has been set to 2, and the `last-applied-configuration`
|
||||
@@ -248,7 +248,7 @@ kubectl apply -f https://k8s.io/docs/tutorials/object-management-kubectl/update_
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows the following changes to the live configuration:
|
||||
@@ -679,7 +679,7 @@ kubectl apply -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_
|
||||
Print the live configuration using `kubectl get`:
|
||||
|
||||
```shell
|
||||
kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
kubectl get -f https://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml
|
||||
```
|
||||
|
||||
The output shows that the API server set several fields to default values in the live
|
||||
|
||||
@@ -667,7 +667,7 @@ web-2 1/1 Running 0 18s
|
||||
Get the Pod's container.
|
||||
|
||||
```shell{% raw %}
|
||||
get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
gcr.io/google_containers/nginx-slim:0.8
|
||||
{% endraw %}
|
||||
```
|
||||
@@ -738,7 +738,7 @@ web-1 1/1 Running 0 18s
|
||||
Get the `web-1` Pods container.
|
||||
|
||||
```shell{% raw %}
|
||||
get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
|
||||
gcr.io/google_containers/nginx-slim:0.8
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: pod-quota-demo
|
||||
spec:
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: pod-quota-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: pod-quota-demo
|
||||
image: nginx
|
||||
@@ -0,0 +1,91 @@
|
||||
/*
|
||||
Copyright 2016 The Kubernetes Authors.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
*/
|
||||
|
||||
package examples_test
|
||||
|
||||
import (
|
||||
"io/ioutil"
|
||||
"gopkg.in/yaml.v2"
|
||||
"path"
|
||||
"strings"
|
||||
"testing"
|
||||
)
|
||||
|
||||
// Not unmarshaling short-description and long-description fields
|
||||
// (for simplicity)
|
||||
type GlossaryTerm struct {
|
||||
Id string `yaml: "id"`
|
||||
Name string `yaml: "name"`
|
||||
Formerly []string `yaml: "formerly"`
|
||||
Related []string `yaml: "related"`
|
||||
Tags []string `yaml: "tags"`
|
||||
}
|
||||
|
||||
// Checks that all glossary files (../_data/glossary/*) contain valid tags
|
||||
// that are present in the canonical set.
|
||||
func TestCanonicalTags(t *testing.T) {
|
||||
canonicalTagsFile := "../_data/canonical-tags.yml"
|
||||
data, err := ioutil.ReadFile(canonicalTagsFile)
|
||||
if err != nil {
|
||||
t.Errorf("Unable to read file %s: %v", canonicalTagsFile, err)
|
||||
return
|
||||
}
|
||||
var tagList []string
|
||||
err = yaml.Unmarshal(data, &tagList)
|
||||
if err != nil {
|
||||
t.Errorf("Unable to unmarshal file %s: %v", tagList, err)
|
||||
return
|
||||
}
|
||||
|
||||
canonicalTagsSet := make(map[string]bool)
|
||||
for _, tag := range tagList {
|
||||
canonicalTagsSet[tag] = true
|
||||
}
|
||||
|
||||
glossaryDir := "../_data/glossary"
|
||||
files, err := ioutil.ReadDir(glossaryDir)
|
||||
if err != nil {
|
||||
t.Errorf("Unable to read directory %s: %v", glossaryDir, err)
|
||||
return
|
||||
}
|
||||
|
||||
var term GlossaryTerm
|
||||
for _, f := range files {
|
||||
// skip validation of example files
|
||||
if (strings.HasPrefix(f.Name(), "_")) {
|
||||
continue
|
||||
}
|
||||
|
||||
filePath := path.Join(glossaryDir, f.Name())
|
||||
data, err := ioutil.ReadFile(filePath)
|
||||
if err != nil {
|
||||
t.Errorf("Unable to read file %s: %v", filePath, err)
|
||||
continue
|
||||
}
|
||||
err = yaml.Unmarshal(data, &term)
|
||||
if err != nil {
|
||||
t.Errorf("Unable to unmarshal file %s: %v", filePath, err)
|
||||
continue
|
||||
}
|
||||
|
||||
for _, tag := range term.Tags {
|
||||
if _, present := canonicalTagsSet[tag]; !present {
|
||||
t.Errorf("Glossary term \"%s\" has invalid tag \"%s\". See %s for the list of valid tags.", term.Name, tag, canonicalTagsFile)
|
||||
continue
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user