Merge branch 'release-1.5' of github.com:kubernetes/kubernetes.github.io into ss-basics
This commit is contained in:
+6
-1
@@ -31,4 +31,9 @@ toc:
|
|||||||
section:
|
section:
|
||||||
- title: Assigning Pods to Nodes
|
- title: Assigning Pods to Nodes
|
||||||
path: /docs/tasks/administer-cluster/assign-pods-nodes/
|
path: /docs/tasks/administer-cluster/assign-pods-nodes/
|
||||||
|
- title: Autoscaling the DNS Service in a Cluster
|
||||||
|
path: /docs/tasks/administer-cluster/dns-horizontal-autoscaling/
|
||||||
|
- title: Managing Stateful Applications
|
||||||
|
section:
|
||||||
|
- title: Upgrading from PetSets to StatefulSets
|
||||||
|
path: /docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/
|
||||||
|
|||||||
@@ -13,6 +13,7 @@
|
|||||||
<script src="/js/jquery-ui.min.js"></script>
|
<script src="/js/jquery-ui.min.js"></script>
|
||||||
<script src="/js/script.js"></script>
|
<script src="/js/script.js"></script>
|
||||||
<script src="/js/sweetalert.min.js"></script>
|
<script src="/js/sweetalert.min.js"></script>
|
||||||
|
<script src="/js/bootstrap.min.js"></script>
|
||||||
<title>Kubernetes - {{ title }}</title>
|
<title>Kubernetes - {{ title }}</title>
|
||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
|
|||||||
@@ -356,3 +356,5 @@ for more information.
|
|||||||
|
|
||||||
- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/build-tools/kube-dns/README.md)
|
- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/build-tools/kube-dns/README.md)
|
||||||
|
|
||||||
|
## What's next
|
||||||
|
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
|
||||||
|
|||||||
@@ -14,20 +14,31 @@ docs, follow the instructions on
|
|||||||
|
|
||||||
{% capture body %}
|
{% capture body %}
|
||||||
|
|
||||||
## Documentation formatting standards
|
### Documentation formatting standards
|
||||||
|
|
||||||
### Capitalize API objects
|
#### Use Camel Case for API objects
|
||||||
|
|
||||||
Capitalize the names of API objects. Refer to API objects without saying
|
When you refer to an API object, use the same uppercase and lowercase letters
|
||||||
"object."
|
that are used in the actual object name. Typically, the names of API
|
||||||
|
objects use
|
||||||
|
[camel case](https://en.wikipedia.org/wiki/Camel_case).
|
||||||
|
|
||||||
|
Don't split the API object name into separate words. For example, use
|
||||||
|
PodTemplateList, not Pod Template List.
|
||||||
|
|
||||||
|
Refer to API objects without saying "object," unless omitting "object"
|
||||||
|
leads to an awkward construction.
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
<tr><td>The Pod has two Containers.</td><td>The pod has two containers.</td></tr>
|
<tr><td>The Pod has two Containers.</td><td>The pod has two containers.</td></tr>
|
||||||
<tr><td>The Deployment is responsible for ...</td><td>The Deployment object is responsible for ...</td></tr>
|
<tr><td>The Deployment is responsible for ...</td><td>The Deployment object is responsible for ...</td></tr>
|
||||||
|
<tr><td>A PodList is a list of Pods.</td><td>A Pod List is a list of pods.</td></tr>
|
||||||
|
<tr><td>The two ContainerPorts ...</td><td>The two ContainerPort objects ...</td></tr>
|
||||||
|
<tr><td>The two ContainerStateTerminated objects ...</td><td>The two ContainerStateTerminateds ...</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Use angle brackets for placeholders
|
#### Use angle brackets for placeholders
|
||||||
|
|
||||||
Use angle brackets for placeholders. Tell the reader what a placeholder
|
Use angle brackets for placeholders. Tell the reader what a placeholder
|
||||||
represents.
|
represents.
|
||||||
@@ -38,7 +49,7 @@ represents.
|
|||||||
|
|
||||||
where `<pod-name>` is the name of one of your pods.
|
where `<pod-name>` is the name of one of your pods.
|
||||||
|
|
||||||
### Use bold for user interface elements
|
#### Use bold for user interface elements
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
@@ -46,7 +57,7 @@ represents.
|
|||||||
<tr><td>Select <b>Other</b>.</td><td>Select 'Other'.</td></tr>
|
<tr><td>Select <b>Other</b>.</td><td>Select 'Other'.</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Use italics to define or introduce new terms
|
#### Use italics to define or introduce new terms
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
@@ -54,7 +65,7 @@ represents.
|
|||||||
<tr><td>These components form the <i>control plane.</i></td><td>These components form the <b>control plane.</b></td></tr>
|
<tr><td>These components form the <i>control plane.</i></td><td>These components form the <b>control plane.</b></td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Use code style for filenames, directories, and paths
|
#### Use code style for filenames, directories, and paths
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
@@ -63,9 +74,9 @@ represents.
|
|||||||
<tr><td>Open the <code>/_data/concepts.yaml</code> file.</td><td>Open the /_data/concepts.yaml file.</td></tr>
|
<tr><td>Open the <code>/_data/concepts.yaml</code> file.</td><td>Open the /_data/concepts.yaml file.</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
## Code snippet formatting
|
### Code snippet formatting
|
||||||
|
|
||||||
### Use code style for inline code and commands
|
#### Use code style for inline code and commands
|
||||||
|
|
||||||
For inline code in an HTML document, use the `<code>` tag. In a Markdown
|
For inline code in an HTML document, use the `<code>` tag. In a Markdown
|
||||||
document, use the backtick (`).
|
document, use the backtick (`).
|
||||||
@@ -76,14 +87,14 @@ document, use the backtick (`).
|
|||||||
<tr><td>The <code>kubectl run</code> command creates a Deployment.</td><td>The "kubectl run" command creates a Deployment.</td></tr>
|
<tr><td>The <code>kubectl run</code> command creates a Deployment.</td><td>The "kubectl run" command creates a Deployment.</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Don't include the command prompt
|
#### Don't include the command prompt
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
<tr><td>kubectl get pods</td><td>$ kubectl get pods</td></tr>
|
<tr><td>kubectl get pods</td><td>$ kubectl get pods</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Separate commands from output
|
#### Separate commands from output
|
||||||
|
|
||||||
Verify that the pod is running on your chosen node:
|
Verify that the pod is running on your chosen node:
|
||||||
|
|
||||||
@@ -105,11 +116,11 @@ A list of Kubernetes-specific terms and words to be used consistently across the
|
|||||||
</table>{% endcomment %}
|
</table>{% endcomment %}
|
||||||
|
|
||||||
|
|
||||||
## Content best practices
|
### Content best practices
|
||||||
|
|
||||||
This section contains suggested best practices for clear, concise, and consistent content.
|
This section contains suggested best practices for clear, concise, and consistent content.
|
||||||
|
|
||||||
### Use present tense
|
#### Use present tense
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
@@ -119,7 +130,7 @@ This section contains suggested best practices for clear, concise, and consisten
|
|||||||
Exception: Use future or past tense if it is required to convey the correct
|
Exception: Use future or past tense if it is required to convey the correct
|
||||||
meaning.
|
meaning.
|
||||||
|
|
||||||
### Use active voice
|
#### Use active voice
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
@@ -129,7 +140,7 @@ meaning.
|
|||||||
|
|
||||||
Exception: Use passive voice if active voice leads to an awkward construction.
|
Exception: Use passive voice if active voice leads to an awkward construction.
|
||||||
|
|
||||||
### Use simple and direct language
|
#### Use simple and direct language
|
||||||
|
|
||||||
Use simple and direct language. Avoid using unnecessary phrases, such as saying "please."
|
Use simple and direct language. Avoid using unnecessary phrases, such as saying "please."
|
||||||
|
|
||||||
@@ -141,7 +152,7 @@ Use simple and direct language. Avoid using unnecessary phrases, such as saying
|
|||||||
|
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Address the reader as "you"
|
#### Address the reader as "you"
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th>Do</th><th>Don't</th></tr>
|
<tr><th>Do</th><th>Don't</th></tr>
|
||||||
@@ -149,9 +160,9 @@ Use simple and direct language. Avoid using unnecessary phrases, such as saying
|
|||||||
<tr><td>In the preceding output, you can see...</td><td>In the preceding output, we can see ...</td></tr>
|
<tr><td>In the preceding output, you can see...</td><td>In the preceding output, we can see ...</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
## Patterns to avoid
|
### Patterns to avoid
|
||||||
|
|
||||||
### Avoid using "we"
|
#### Avoid using "we"
|
||||||
|
|
||||||
Using "we" in a sentence can be confusing, because the reader might not know
|
Using "we" in a sentence can be confusing, because the reader might not know
|
||||||
whether they're part of the "we" you're describing.
|
whether they're part of the "we" you're describing.
|
||||||
@@ -163,7 +174,7 @@ whether they're part of the "we" you're describing.
|
|||||||
<tr><td>This page teaches you how to use pods.</td><td>In this page, we are going to learn about pods.</td></tr>
|
<tr><td>This page teaches you how to use pods.</td><td>In this page, we are going to learn about pods.</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Avoid jargon and idioms
|
#### Avoid jargon and idioms
|
||||||
|
|
||||||
Some readers speak English as a second language. Avoid jargon and idioms to help make their understanding easier.
|
Some readers speak English as a second language. Avoid jargon and idioms to help make their understanding easier.
|
||||||
|
|
||||||
@@ -173,13 +184,13 @@ Some readers speak English as a second language. Avoid jargon and idioms to help
|
|||||||
<tr><td>Create a new cluster.</td><td>Turn up a new cluster.</td></tr>
|
<tr><td>Create a new cluster.</td><td>Turn up a new cluster.</td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
### Avoid statements about the future
|
#### Avoid statements about the future
|
||||||
|
|
||||||
Avoid making promises or giving hints about the future. If you need to talk about
|
Avoid making promises or giving hints about the future. If you need to talk about
|
||||||
an alpha feature, put the text under a heading that identifies it as alpha
|
an alpha feature, put the text under a heading that identifies it as alpha
|
||||||
information.
|
information.
|
||||||
|
|
||||||
### Avoid statements that will soon be out of date
|
#### Avoid statements that will soon be out of date
|
||||||
|
|
||||||
Avoid words like "currently" and "new." A feature that is new today might not be
|
Avoid words like "currently" and "new." A feature that is new today might not be
|
||||||
considered new in a few months.
|
considered new in a few months.
|
||||||
|
|||||||
@@ -0,0 +1,31 @@
|
|||||||
|
apiVersion: extensions/v1beta1
|
||||||
|
kind: Deployment
|
||||||
|
metadata:
|
||||||
|
name: kube-dns-autoscaler
|
||||||
|
namespace: kube-system
|
||||||
|
labels:
|
||||||
|
k8s-app: kube-dns-autoscaler
|
||||||
|
spec:
|
||||||
|
template:
|
||||||
|
metadata:
|
||||||
|
labels:
|
||||||
|
k8s-app: kube-dns-autoscaler
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: autoscaler
|
||||||
|
image: gcr.io/google_containers/cluster-proportional-autoscaler-amd64:1.0.0
|
||||||
|
resources:
|
||||||
|
requests:
|
||||||
|
cpu: "20m"
|
||||||
|
memory: "10Mi"
|
||||||
|
command:
|
||||||
|
- /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.
|
||||||
|
- --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
|
||||||
|
- --logtostderr=true
|
||||||
|
- --v=2
|
||||||
@@ -0,0 +1,238 @@
|
|||||||
|
---
|
||||||
|
---
|
||||||
|
|
||||||
|
{% capture overview %}
|
||||||
|
This page shows how to enable and configure autoscaling of the DNS service in a
|
||||||
|
Kubernetes cluster.
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% capture prerequisites %}
|
||||||
|
|
||||||
|
* {% include task-tutorial-prereqs.md %}
|
||||||
|
|
||||||
|
* Make sure the [DNS feature](/docs/admin/dns/) itself is enabled.
|
||||||
|
|
||||||
|
* Kubernetes version 1.4.0 or later is recommended.
|
||||||
|
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% capture steps %}
|
||||||
|
|
||||||
|
### Determining whether DNS horizontal autoscaling is already enabled
|
||||||
|
|
||||||
|
List the Deployments in your cluster in the kube-system namespace:
|
||||||
|
|
||||||
|
kubectl get deployment --namespace=kube-system
|
||||||
|
|
||||||
|
The output is similar to this:
|
||||||
|
|
||||||
|
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||||
|
...
|
||||||
|
kube-dns-autoscaler 1 1 1 1 ...
|
||||||
|
...
|
||||||
|
|
||||||
|
If you see "kube-dns-autoscaler" in the output, DNS horizontal autoscaling is
|
||||||
|
already enabled, and you can skip to
|
||||||
|
[Tuning autoscaling parameters](#tuning-autoscaling-parameters).
|
||||||
|
|
||||||
|
### Getting the name of your DNS Deployment or ReplicationController
|
||||||
|
|
||||||
|
List the Deployments in your cluster in the kube-system namespace:
|
||||||
|
|
||||||
|
kubectl get deployment --namespace=kube-system
|
||||||
|
|
||||||
|
The output is similar to this:
|
||||||
|
|
||||||
|
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||||
|
...
|
||||||
|
kube-dns 1 1 1 1 ...
|
||||||
|
...
|
||||||
|
|
||||||
|
In Kubernetes versions earlier than 1.5 DNS is implemented using a
|
||||||
|
ReplicationController instead of a Deployment. So if you don't see kube-dns,
|
||||||
|
or a similar name, in the preceding output, list the ReplicationControllers in
|
||||||
|
your cluster in the kube-system namespace:
|
||||||
|
|
||||||
|
kubectl get rc --namespace=kube-system
|
||||||
|
|
||||||
|
The output is similar to this:
|
||||||
|
|
||||||
|
NAME DESIRED CURRENT READY AGE
|
||||||
|
...
|
||||||
|
kube-dns-v20 1 1 1 ...
|
||||||
|
...
|
||||||
|
|
||||||
|
### Determining your scale target
|
||||||
|
|
||||||
|
If you have a DNS Deployment, your scale target is:
|
||||||
|
|
||||||
|
Deployment/<your-deployment-name>
|
||||||
|
|
||||||
|
where <dns-deployment-name> is the name of your DNS Deployment. For example, if
|
||||||
|
your DNS Deployment name is kube-dns, your scale target is Deployment/kube-dns.
|
||||||
|
|
||||||
|
If you have a DNS ReplicationController, your scale target is:
|
||||||
|
|
||||||
|
ReplicationController/<your-rc-name>
|
||||||
|
|
||||||
|
where <your-rc-name> is the name of your DNS ReplicationController. For example,
|
||||||
|
if your DNS ReplicationController name is kube-dns-v20, your scale target is
|
||||||
|
ReplicationController/kube-dns-v20.
|
||||||
|
|
||||||
|
### Enabling DNS horizontal autoscaling
|
||||||
|
|
||||||
|
In this section, you create a Deployment. The Pods in the Deployment run a
|
||||||
|
container based on the `cluster-proportional-autoscaler-amd64` image.
|
||||||
|
|
||||||
|
Create a file named `dns-horizontal-autoscaler.yaml` with this content:
|
||||||
|
|
||||||
|
{% include code.html language="yaml" file="dns-horizontal-autoscaler.yaml" ghlink="/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml" %}
|
||||||
|
|
||||||
|
In the file, replace `<SCALE_TARGET>` with your scale target.
|
||||||
|
|
||||||
|
Go to the directory that contains your configuration file, and enter this
|
||||||
|
command to create the Deployment:
|
||||||
|
|
||||||
|
kubectl create -f dns-horizontal-autoscaler.yaml
|
||||||
|
|
||||||
|
The output of a successful command is:
|
||||||
|
|
||||||
|
deployment "kube-dns-autoscaler" created
|
||||||
|
|
||||||
|
DNS horizontal autoscaling is now enabled.
|
||||||
|
|
||||||
|
### Tuning autoscaling parameters
|
||||||
|
|
||||||
|
Verify that the kube-dns-autoscaler ConfigMap exists:
|
||||||
|
|
||||||
|
kubectl get configmap --namespace=kube-system
|
||||||
|
|
||||||
|
The output is similar to this:
|
||||||
|
|
||||||
|
NAME DATA AGE
|
||||||
|
...
|
||||||
|
kube-dns-autoscaler 1 ...
|
||||||
|
...
|
||||||
|
|
||||||
|
Modify the data in the ConfigMap:
|
||||||
|
|
||||||
|
kubectl edit configmap kube-dns-autoscaler --namespace=kube-system
|
||||||
|
|
||||||
|
Look for this line:
|
||||||
|
|
||||||
|
linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
|
||||||
|
|
||||||
|
Modify the fields according to your needs. The "min" field indicates the
|
||||||
|
minimal number of DNS backends. The actual number of backends number is
|
||||||
|
calculated using this equation:
|
||||||
|
|
||||||
|
replicas = max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) )
|
||||||
|
|
||||||
|
Note that the values of both `coresPerReplica` and `nodesPerReplica` are
|
||||||
|
integers.
|
||||||
|
|
||||||
|
The idea is that when a cluster is using nodes that have many cores,
|
||||||
|
`coresPerReplica` dominates. When a cluster is using nodes that have fewer
|
||||||
|
cores, `nodesPerReplica` dominates.
|
||||||
|
|
||||||
|
There are other supported scaling patterns. For details, see
|
||||||
|
[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
|
||||||
|
|
||||||
|
### Disable DNS horizontal autoscaling
|
||||||
|
|
||||||
|
There are a few options for turning DNS horizontal autoscaling. Which option to
|
||||||
|
use depends on different conditions.
|
||||||
|
|
||||||
|
#### Option 1: Scale down the kube-dns-autoscaler deployment to 0 replicas
|
||||||
|
|
||||||
|
This option works for all situations. Enter this command:
|
||||||
|
|
||||||
|
kubectl scale deployment --replicas=0 kube-dns-autoscaler --namespace=kube-system
|
||||||
|
|
||||||
|
The output is:
|
||||||
|
|
||||||
|
deployment "kube-dns-autoscaler" scaled
|
||||||
|
|
||||||
|
Verify that the replica count is zero:
|
||||||
|
|
||||||
|
kubectl get deployment --namespace-kube-system
|
||||||
|
|
||||||
|
The output displays 0 in the DESIRED and CURRENT columns:
|
||||||
|
|
||||||
|
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||||
|
...
|
||||||
|
kube-dns-autoscaler 0 0 0 0 ...
|
||||||
|
...
|
||||||
|
|
||||||
|
#### Option 2: Delete the kube-dns-autoscaler deployment
|
||||||
|
|
||||||
|
This option works if kube-dns-autoscaler is under your own control, which means
|
||||||
|
no one will re-create it:
|
||||||
|
|
||||||
|
kubectl delete deployment kube-dns-autoscaler --namespace=kube-system
|
||||||
|
|
||||||
|
The output is:
|
||||||
|
|
||||||
|
deployment "kube-dns-autoscaler" deleted
|
||||||
|
|
||||||
|
#### Option 3: Delete the kube-dns-autoscaler manifest file from the master node
|
||||||
|
|
||||||
|
This option works if kube-dns-autoscaler is under control of the
|
||||||
|
[Addon Manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/README.md)'s
|
||||||
|
control, and you have write access to the master node.
|
||||||
|
|
||||||
|
Sign in to the master node and delete the corresponding manifest file.
|
||||||
|
The common path for this kube-dns-autoscaler is:
|
||||||
|
|
||||||
|
/etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml
|
||||||
|
|
||||||
|
After the manifest file is deleted, the Addon Manager will delete the
|
||||||
|
kube-dns-autoscaler Deployment.
|
||||||
|
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% capture discussion %}
|
||||||
|
|
||||||
|
### Understanding how DNS horizontal autoscaling works
|
||||||
|
|
||||||
|
* The cluster-proportional-autoscaler application is deployed separately from
|
||||||
|
the DNS service.
|
||||||
|
|
||||||
|
* An autoscaler Pod runs a client that polls the Kubernetes API server for the
|
||||||
|
number of nodes and cores in the cluster.
|
||||||
|
|
||||||
|
* A desired replica count is calculated and applied to the DNS backends based on
|
||||||
|
the current schedulable nodes and cores and the given scaling parameters.
|
||||||
|
|
||||||
|
* The scaling parameters and data points are provided via a ConfigMap to the
|
||||||
|
autoscaler, and it refreshes its parameters table every poll interval to be up
|
||||||
|
to date with the latest desired scaling parameters.
|
||||||
|
|
||||||
|
* Changes to the scaling parameters are allowed without rebuilding or restarting
|
||||||
|
the autoscaler Pod.
|
||||||
|
|
||||||
|
* The autoscaler provides a controller interface to support two control
|
||||||
|
patterns: *linear* and *ladder*.
|
||||||
|
|
||||||
|
### Future enhancements
|
||||||
|
|
||||||
|
Control patterns, in addition to linear and ladder, that consider custom metrics
|
||||||
|
are under consideration as a future development.
|
||||||
|
|
||||||
|
Scaling of DNS backends based on DNS-specific metrics is under consideration as
|
||||||
|
a future development. The current implementation, which uses the number of nodes
|
||||||
|
and cores in cluster, is limited.
|
||||||
|
|
||||||
|
Support for custom metrics, similar to that provided by
|
||||||
|
[Horizontal Pod Autoscaling](http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/),
|
||||||
|
is under consideration as a future development.
|
||||||
|
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% capture whatsnext %}
|
||||||
|
Learn more about the
|
||||||
|
[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
|
||||||
|
{% include templates/task.md %}
|
||||||
@@ -26,6 +26,11 @@ single thing, typically by giving a short sequence of steps.
|
|||||||
#### Administering a Cluster
|
#### Administering a Cluster
|
||||||
|
|
||||||
* [Assigning Pods to Nodes](/docs/tasks/administer-cluster/assign-pods-nodes/)
|
* [Assigning Pods to Nodes](/docs/tasks/administer-cluster/assign-pods-nodes/)
|
||||||
|
* [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
|
||||||
|
|
||||||
|
#### Managing Stateful Applications
|
||||||
|
|
||||||
|
* [Upgrading from PetSets to StatefulSets](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/)
|
||||||
|
|
||||||
### What's next
|
### What's next
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,163 @@
|
|||||||
|
---
|
||||||
|
assignees:
|
||||||
|
- bprashanth
|
||||||
|
- enisoc
|
||||||
|
- erictune
|
||||||
|
- foxish
|
||||||
|
- janetkuo
|
||||||
|
- kow3ns
|
||||||
|
- smarterclayton
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
{% capture overview %}
|
||||||
|
This page shows how to upgrade from PetSets (Kubernetes version 1.3 or 1.4) to *StatefulSets* (Kubernetes version 1.5 or later).
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% capture prerequisites %}
|
||||||
|
|
||||||
|
* If you don't have PetSets in your current cluster, or you don't plan to upgrade
|
||||||
|
your master to Kubernetes 1.5 or later, you can skip this task.
|
||||||
|
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% capture steps %}
|
||||||
|
|
||||||
|
### Differences between alpha PetSets and beta StatefulSets
|
||||||
|
|
||||||
|
PetSet was introduced as an alpha resource in Kubernetes release 1.3, and was renamed to StatefulSet as a beta resource in 1.5.
|
||||||
|
Here are some notable changes:
|
||||||
|
|
||||||
|
* **StatefulSet is the new PetSet**: PetSet is no longer available in Kubernetes release 1.5 or later. It becomes beta StatefulSet. To understand why the name was changed, see this [discussion thread](https://github.com/kubernetes/kubernetes/issues/27430).
|
||||||
|
* **StatefulSet guards against split brain**: StatefulSets guarantee at most one Pod for a given ordinal index can be running anywhere in a cluster, to guard against split brain scenarios with distributed applications. *TODO: Link to doc about fencing.*
|
||||||
|
* **Flipped debug annotation behavior**: The default value of the debug annotation (`pod.alpha.kubernetes.io/initialized`) is now `true`. The absence of this annotation will pause PetSet operations, but will NOT pause StatefulSet operations. In most cases, you no longer need this annotation in your StatefulSet manifests.
|
||||||
|
|
||||||
|
|
||||||
|
### Upgrading from PetSets to StatefulSets
|
||||||
|
|
||||||
|
Note that these steps need to be done in the specified order. You **should
|
||||||
|
NOT upgrade your Kubernetes master, nodes, or `kubectl` to Kubernetes version
|
||||||
|
1.5 or later**, until told to do so.
|
||||||
|
|
||||||
|
#### Find all PetSets and their manifests
|
||||||
|
|
||||||
|
First, find all existing PetSets in your cluster:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl get petsets --all-namespaces
|
||||||
|
```
|
||||||
|
|
||||||
|
If you don't find any existing PetSets, you can safely upgrade your cluster to
|
||||||
|
Kubernetes version 1.5 or later.
|
||||||
|
|
||||||
|
If you find existing PetSets and you have all their manifests at hand, you can continue to the next step to prepare StatefulSet manifests.
|
||||||
|
|
||||||
|
Otherwise, you need to save their manifests so that you can recreate them as StatefulSets later.
|
||||||
|
Here's an example command for you to save all existing PetSets as one file.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
# Save all existing PetSets in all namespaces into a single file. Only needed when you don't have their manifests at hand.
|
||||||
|
kubectl get petsets --all-namespaces -o yaml > all-petsets.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Prepare StatefulSet manifests
|
||||||
|
|
||||||
|
Now, for every PetSet manifest you have, prepare a corresponding StatefulSet manifest:
|
||||||
|
|
||||||
|
1. Change `apiVersion` from `apps/v1alpha1` to `apps/v1beta1`.
|
||||||
|
2. Change `kind` from `PetSet` to `StatefulSet`.
|
||||||
|
3. If you have the debug hook annotation `pod.alpha.kubernetes.io/initialized` set to `true`, you can remove it because it's redundant. If you don't have this annotation, you should add one, with the value set to `false`, to pause StatefulSets operations.
|
||||||
|
|
||||||
|
It's recommended that you keep both PetSet manifests and StatefulSet manifests, so that you can safely roll back and recreate your PetSets,
|
||||||
|
if you decide not to upgrade your cluster.
|
||||||
|
|
||||||
|
#### Delete all PetSets without cascading
|
||||||
|
|
||||||
|
If you find existing PetSets in your cluster in the previous step, you need to delete all PetSets *without cascading*. You can do this from `kubectl` with `--cascade=false`.
|
||||||
|
Note that if the flag isn't set, **cascading deletion will be performed by default**, and all Pods managed by your PetSets will be gone.
|
||||||
|
|
||||||
|
Delete those PetSets by specifying file names. This only works when
|
||||||
|
the files contain only PetSets, but not other resources such as Services:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
# Delete all existing PetSets without cascading
|
||||||
|
# Note that <pet-set-file> should only contain PetSets that you want to delete, but not any other resources
|
||||||
|
kubectl delete -f <pet-set-file> --cascade=false
|
||||||
|
```
|
||||||
|
|
||||||
|
Alternatively, delete them by specifying resource names:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
# Alternatively, delete them by name and namespace without cascading
|
||||||
|
kubectl delete petsets <pet-set-name> -n=<pet-set-namespace> --cascade=false
|
||||||
|
```
|
||||||
|
|
||||||
|
Make sure you've deleted all PetSets in the system:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
# Get all PetSets again to make sure you deleted them all
|
||||||
|
# This should return nothing
|
||||||
|
kubectl get petsets --all-namespaces
|
||||||
|
```
|
||||||
|
|
||||||
|
At this moment, you've deleted all PetSets in your cluster, but not their Pods, Persistent Volumes, or Persistent Volume Claims.
|
||||||
|
However, since the Pods are not managed by PetSets anymore, they will be vulnerable to node failures until you finish the master upgrade and recreate StatefulSets.
|
||||||
|
|
||||||
|
#### Upgrade your master to Kubernetes version 1.5 or later
|
||||||
|
|
||||||
|
Now, you can [upgrade your Kubernetes master](/docs/admin/cluster-management/#upgrading-a-cluster) to Kubernetes version 1.5 or later.
|
||||||
|
Note that **you should NOT upgrade Nodes at this time**, because the Pods
|
||||||
|
(that were once managed by PetSets) are now vulnerable to node failures.
|
||||||
|
|
||||||
|
#### Upgrade kubectl to Kubernetes version 1.5 or later
|
||||||
|
|
||||||
|
Upgrade `kubectl` to Kubernetes version 1.5 or later, following [the steps for installing and setting up
|
||||||
|
kubectl](/docs/user-guide/prereqs/).
|
||||||
|
|
||||||
|
#### Create StatefulSets
|
||||||
|
|
||||||
|
Make sure you have both master and `kubectl` upgraded to Kubernetes version 1.5
|
||||||
|
or later before continuing:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl version
|
||||||
|
```
|
||||||
|
|
||||||
|
The output is similar to this:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.0", GitCommit:"0776eab45fe28f02bbeac0f05ae1a203051a21eb", GitTreeState:"clean", BuildDate:"2016-11-24T22:35:03Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"}
|
||||||
|
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.0", GitCommit:"0776eab45fe28f02bbeac0f05ae1a203051a21eb", GitTreeState:"clean", BuildDate:"2016-11-24T22:30:23Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"}
|
||||||
|
```
|
||||||
|
|
||||||
|
If both `Client Version` (`kubectl` version) and `Server Version` (master
|
||||||
|
version) are 1.5 or later, you are good to go.
|
||||||
|
|
||||||
|
Create StatefulSets to adopt the Pods belonging to the deleted PetSets with the
|
||||||
|
StatefulSet manifests generated in the previous step:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl create -f <stateful-set-file>
|
||||||
|
```
|
||||||
|
|
||||||
|
Make sure all StatefulSets are created and running as expected in the
|
||||||
|
newly-upgraded cluster:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl get statefulsets --all-namespaces
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Upgrade nodes to Kubernetes version 1.5 or later (optional)
|
||||||
|
|
||||||
|
You can now [upgrade Kubernetes nodes](/docs/admin/cluster-management/#upgrading-a-cluster)
|
||||||
|
to Kubernetes version 1.5 or later. This step is optional, but needs to be done after all StatefulSets
|
||||||
|
are created to adopt PetSets' Pods.
|
||||||
|
|
||||||
|
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% capture whatsnext %}
|
||||||
|
Learn more about debugging a StatefulSet. *TODO: Link to the task for debugging a StatefulSet.*
|
||||||
|
{% endcapture %}
|
||||||
|
|
||||||
|
{% include templates/task.md %}
|
||||||
@@ -59,6 +59,13 @@ interest. For example, people new to Kubernetes may also want to join the
|
|||||||
`#kubernetes-novice` channel. As another example, developers should join the
|
`#kubernetes-novice` channel. As another example, developers should join the
|
||||||
`#kubernetes-dev` channel.
|
`#kubernetes-dev` channel.
|
||||||
|
|
||||||
|
There are also many country specific/local language channels. Feel free to join
|
||||||
|
these channels for localized support and info:
|
||||||
|
|
||||||
|
- France: `#fr-users`, `#fr-events`
|
||||||
|
- Germany: `#de-users`, `#de-events`
|
||||||
|
- Japan: `#jp-users`, `#jp-events`
|
||||||
|
|
||||||
### Mailing List
|
### Mailing List
|
||||||
|
|
||||||
The Kubernetes / Google Container Engine mailing list is [kubernetes-users@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-users)
|
The Kubernetes / Google Container Engine mailing list is [kubernetes-users@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-users)
|
||||||
|
|||||||
@@ -14,8 +14,8 @@ should run in a container. In this case, Kubernetes runs the image's default co
|
|||||||
to run a particular command or override the image's defaults, there are two additional fields that
|
to run a particular command or override the image's defaults, there are two additional fields that
|
||||||
we can use:
|
we can use:
|
||||||
|
|
||||||
1. `Command`: Controls the actual command run by the image
|
1. `command`: Controls the actual command run by the image
|
||||||
2. `Args`: Controls the arguments passed to the command
|
2. `args`: Controls the arguments passed to the command
|
||||||
|
|
||||||
### How docker handles command and arguments
|
### How docker handles command and arguments
|
||||||
|
|
||||||
@@ -28,20 +28,20 @@ fields as either a string array or a string and there are subtle differences in
|
|||||||
handled. We encourage the curious to check out Docker's documentation for this feature.
|
handled. We encourage the curious to check out Docker's documentation for this feature.
|
||||||
|
|
||||||
Kubernetes allows you to override both the image's default command (docker `Entrypoint`) and args
|
Kubernetes allows you to override both the image's default command (docker `Entrypoint`) and args
|
||||||
(docker `Cmd`) with the `Command` and `Args` fields of `Container`. The rules are:
|
(docker `Cmd`) with the `command` and `args` fields of `container`. The rules are:
|
||||||
|
|
||||||
1. If you do not supply a `Command` or `Args` for a container, the defaults defined by the image
|
1. If you do not supply a `command` or `args` for a container, the defaults defined by the image
|
||||||
will be used
|
will be used.
|
||||||
2. If you supply a `Command` but no `Args` for a container, only the supplied `Command` will be
|
2. If you supply a `command` but no `args` for a container, only the supplied `command` will be
|
||||||
used; the image's default arguments are ignored
|
used; the image's default arguments are ignored.
|
||||||
3. If you supply only `Args`, the image's default command will be used with the arguments you
|
3. If you supply only `args`, the image's default command will be used with the arguments you
|
||||||
supply
|
supply.
|
||||||
4. If you supply a `Command` **and** `Args`, the image's defaults will be ignored and the values
|
4. If you supply a `command` **and** `args`, the image's defaults will be ignored and the values
|
||||||
you supply will be used
|
you supply will be used.
|
||||||
|
|
||||||
Here are examples for these rules in table format
|
Here are examples for these rules in table format
|
||||||
|
|
||||||
| Image `Entrypoint` | Image `Cmd` | Container `Command` | Container `Args` | Command Run |
|
| Image `Entrypoint` | Image `Cmd` | Container `command` | Container `args` | Command Run |
|
||||||
|--------------------|------------------|---------------------|--------------------|------------------|
|
|--------------------|------------------|---------------------|--------------------|------------------|
|
||||||
| `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` |
|
| `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` |
|
||||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` |
|
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` |
|
||||||
|
|||||||
@@ -50,7 +50,7 @@ a matching secret in all underlying kubernetes clusters.
|
|||||||
You can verify this by checking each of the underlying clusters, for example:
|
You can verify this by checking each of the underlying clusters, for example:
|
||||||
|
|
||||||
``` shell
|
``` shell
|
||||||
kubectl --context=gce-asia-east1a get rs myrs
|
kubectl --context=gce-asia-east1a get secret mysecret
|
||||||
```
|
```
|
||||||
|
|
||||||
The above assumes that you have a context named 'gce-asia-east1a'
|
The above assumes that you have a context named 'gce-asia-east1a'
|
||||||
@@ -77,7 +77,7 @@ the federation apiserver instead of sending it to a specific Kubernetes cluster.
|
|||||||
For example, you can do that using kubectl by running:
|
For example, you can do that using kubectl by running:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl --context=federation-cluster delete rs myrs
|
kubectl --context=federation-cluster delete secret mysecret
|
||||||
```
|
```
|
||||||
|
|
||||||
Note that at this point, deleting a federated secret will not delete the
|
Note that at this point, deleting a federated secret will not delete the
|
||||||
|
|||||||
Vendored
+7
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user