whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'release-1.5' of github.com:kubernetes/kubernetes.github.io into ss-basics

Browse Source
This commit is contained in:
Kenneth Owens
2016-12-02 09:57:38 -08:00
parent bef91e9b26 3777dde47f
commit 1ce5dc5cce
12 changed files with 507 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_data/tasks.yml
+6 -1
View File
@@ -31,4 +31,9 @@ toc:
section:
- title: Assigning Pods to 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/
_includes/head-header.html
+1
View File
@@ -13,6 +13,7 @@
<script src="/js/jquery-ui.min.js"></script>
<script src="/js/script.js"></script>
<script src="/js/sweetalert.min.js"></script>
<script src="/js/bootstrap.min.js"></script>
<title>Kubernetes - {{ title }}</title>
</head>
<body>
docs/admin/dns.md
+2
View File
@@ -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)
## What's next
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
docs/contribute/style-guide.md
+33 -22
View File
@@ -14,20 +14,31 @@ docs, follow the instructions on
{% 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
"object."
When you refer to an API object, use the same uppercase and lowercase letters
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>
<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 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>
### Use angle brackets for placeholders
#### Use angle brackets for placeholders
Use angle brackets for placeholders. Tell the reader what a placeholder
represents.
@@ -38,7 +49,7 @@ represents.
where `<pod-name>` is the name of one of your pods.
### Use bold for user interface elements
#### Use bold for user interface elements
<table>
<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>
</table>
### Use italics to define or introduce new terms
#### Use italics to define or introduce new terms
<table>
<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>
</table>
### Use code style for filenames, directories, and paths
#### Use code style for filenames, directories, and paths
<table>
<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>
</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
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>
</table>
### Don't include the command prompt
#### Don't include the command prompt
<table>
<tr><th>Do</th><th>Don't</th></tr>
<tr><td>kubectl get pods</td><td>$ kubectl get pods</td></tr>
</table>
### Separate commands from output
#### Separate commands from output
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 %}
## Content best practices
### Content best practices
This section contains suggested best practices for clear, concise, and consistent content.
### Use present tense
#### Use present tense
<table>
<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
meaning.
### Use active voice
#### Use active voice
<table>
<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.
### Use simple and direct language
#### Use simple and direct language
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>
### Address the reader as "you"
#### Address the reader as "you"
<table>
<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>
</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
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>
</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.
@@ -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>
</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
an alpha feature, put the text under a heading that identifies it as alpha
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
considered new in a few months.
docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
+31
View File
@@ -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
docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+238
View File
@@ -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 %}
docs/tasks/index.md
+5
View File
@@ -26,6 +26,11 @@ single thing, typically by giving a short sequence of steps.
#### Administering a Cluster
* [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
docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set.md
+163
View File
@@ -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 %}
docs/troubleshooting.md
+7
View File
@@ -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-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
The Kubernetes / Google Container Engine mailing list is [kubernetes-users@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-users)
docs/user-guide/containers.md
+12 -12
View File
@@ -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
we can use:
1. `Command`: Controls the actual command run by the image
2. `Args`: Controls the arguments passed to the command
1. `command`: Controls the actual command run by the image
2. `args`: Controls the arguments passed to the command
### 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.
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
will be used
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
3. If you supply only `Args`, the image's default command will be used with the arguments you
supply
4. If you supply a `Command` **and** `Args`, the image's defaults will be ignored and the values
you supply will be used
1. If you do not supply a `command` or `args` for a container, the defaults defined by the image
will be used.
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.
3. If you supply only `args`, the image's default command will be used with the arguments you
supply.
4. If you supply a `command` **and** `args`, the image's defaults will be ignored and the values
you supply will be used.
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]` | &lt;not set&gt; | &lt;not set&gt; | `[ep-1 foo bar]` |
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | &lt;not set&gt; | `[ep-2]` |
docs/user-guide/federation/secrets.md
+2 -2
View File
@@ -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:
``` 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'
@@ -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:
```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
js/bootstrap.min.js
Vendored
+7
View File
File diff suppressed because one or more lines are too long