Add admonition type to shortcode (#9482)
* Change existing admon blocks * Fix includes issue
This commit is contained in:
committed by
k8s-ci-robot
parent
e839031292
commit
d65e1790ff
+1
-1
@@ -13,7 +13,7 @@ one or more configuration files, you can quickly switch between clusters by usin
|
||||
`kubectl config use-context` command.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A file that is used to configure access to a cluster is sometimes called
|
||||
A file that is used to configure access to a cluster is sometimes called
|
||||
a *kubeconfig file*. This is a generic way of referring to configuration files.
|
||||
It does not mean that there is a file named `kubeconfig`.
|
||||
{{< /note >}}
|
||||
|
||||
+5
-6
@@ -84,12 +84,11 @@ gcloud compute firewall-rules create my-rule --allow=tcp:<port>
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note**: GCE firewalls are defined per-vm, rather than per-ip
|
||||
address. This means that when you open a firewall for a service's ports,
|
||||
anything that serves on that port on that VM's host IP address may potentially
|
||||
serve traffic. Note that this is not a problem for other Kubernetes services,
|
||||
as they listen on IP addresses that are different than the host node's external
|
||||
IP address.
|
||||
GCE firewalls are defined per-vm, rather than per-ip address. This means that
|
||||
when you open a firewall for a service's ports, anything that serves on that
|
||||
port on that VM's host IP address may potentially serve traffic. Note that this
|
||||
is not a problem for other Kubernetes services, as they listen on IP addresses
|
||||
that are different than the host node's external IP address.
|
||||
|
||||
Consider:
|
||||
|
||||
|
||||
@@ -148,11 +148,13 @@ deployment.apps/frontend created
|
||||
service/frontend created
|
||||
```
|
||||
|
||||
{{< note >}}**Note:** The nginx configuration is baked into the
|
||||
[container image](/examples/service/access/Dockerfile).
|
||||
A better way to do this would be to use a
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), so
|
||||
you can change the configuration more easily.{{< /note >}}
|
||||
{{< note >}}
|
||||
The nginx configuration is baked into the [container
|
||||
image](/examples/service/access/Dockerfile). A better way to do this would
|
||||
be to use a
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
|
||||
so that you can change the configuration more easily.
|
||||
{{< /note >}}
|
||||
|
||||
### Interact with the frontend Service
|
||||
|
||||
|
||||
@@ -108,8 +108,9 @@ which should produce output like this:
|
||||
The IP address is listed next to `LoadBalancer Ingress`.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: If you are running your service on Minikube, you can find the assigned IP address and port with:
|
||||
If you are running your service on Minikube, you can find the assigned IP address and port with:
|
||||
{{< /note >}}
|
||||
|
||||
```bash
|
||||
minikube service example-service --url
|
||||
```
|
||||
@@ -181,7 +182,7 @@ compared to the `service.spec.externalTrafficPolicy` field. The values match as
|
||||
* "Global" for annotation <-> "Cluster" for field
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This feature is not currently implemented for all cloudproviders/environments.
|
||||
This feature is not currently implemented for all cloudproviders/environments.
|
||||
{{< /note >}}
|
||||
|
||||
Known issues:
|
||||
|
||||
+1
-1
@@ -63,7 +63,7 @@ The jsonpath is interpreted as follows:
|
||||
- `.image`: get the image
|
||||
|
||||
{{< note >}}
|
||||
**Note:** When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
|
||||
When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
|
||||
the `.items[*]` portion of the path should be omitted because a single
|
||||
Pod is returned instead of a list of items.
|
||||
{{< /note >}}
|
||||
|
||||
+2
-2
@@ -71,7 +71,7 @@ load-balanced access to an application running in a cluster.
|
||||
command.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you are using Minikube, you don't get an external IP address. The
|
||||
If you are using Minikube, you don't get an external IP address. The
|
||||
external IP address remains in the pending state.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -90,7 +90,7 @@ load-balanced access to an application running in a cluster.
|
||||
Hello Kubernetes!
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you are using Minikube, enter these commands:
|
||||
If you are using Minikube, enter these commands:
|
||||
{{< /note >}}
|
||||
|
||||
kubectl cluster-info
|
||||
|
||||
+1
-1
@@ -137,7 +137,7 @@ is running the Redis server. With this connection in place you can use your
|
||||
local workstation to debug the database that is running in the pod.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: Due to known limitations, port forward today only works for TCP protocol.
|
||||
Due to known limitations, port forward today only works for TCP protocol.
|
||||
The support to UDP protocol is being tracked in
|
||||
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -19,7 +19,7 @@ Configuring the [aggregation layer](/docs/concepts/api-extension/apiserver-aggre
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
|
||||
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+2
-2
@@ -15,8 +15,8 @@ level of your CustomResourceDefinitions. It also describes how to upgrade an
|
||||
object from one version to another.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: All specified versions must use the same schema. The is no schema
|
||||
conversion between versions.
|
||||
All specified versions must use the same schema. There is no schema conversion
|
||||
between versions.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -105,7 +105,7 @@ For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are tr
|
||||
Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
|
||||
etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
|
||||
{{< /note >}}
|
||||
|
||||
## Replacing a failed etcd member
|
||||
@@ -212,7 +212,7 @@ The upgrade procedure described in this document assumes that either:
|
||||
etcd cluster. During the time the etcd cluster is shut down, the Kubernetes API Server will be read only.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: Deviations from the assumptions are untested by continuous
|
||||
Deviations from the assumptions are untested by continuous
|
||||
integration, and deviations might create undesirable consequences. Additional information about operating an etcd cluster is available [from the etcd maintainers](https://github.com/coreos/etcd/tree/master/Documentation).
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -264,7 +264,7 @@ but the rollback tool has these limitations:
|
||||
* Rollback doesn’t preserve resource versions of objects stored in etcd.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: If the data is not kept in `application/json` format (see [Upgrade
|
||||
If the data is not kept in `application/json` format (see [Upgrade
|
||||
Procedure](#upgrade-procedure)), you will lose the option to roll back to etcd
|
||||
2.2.
|
||||
{{< /warning >}}
|
||||
@@ -276,7 +276,7 @@ resource versions. Since both the kubelet and kube-proxy use the watch API, a
|
||||
rollback might require restarting all Kubernetes components on all nodes.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: At the time of writing, both Kubelet and KubeProxy are using “resource
|
||||
At the time of writing, both Kubelet and KubeProxy are using “resource
|
||||
version” only for watching (i.e. are not using resource versions for anything
|
||||
else). And both are using reflector and/or informer frameworks for watching
|
||||
(i.e. they don’t send watch requests themselves). Both those frameworks if they
|
||||
@@ -390,7 +390,7 @@ STORAGE_MEDIA_TYPE=application/json
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This procedure upgrades from 2.x to 3.x. Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
|
||||
This procedure upgrades from 2.x to 3.x. Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
|
||||
{{< /note >}}
|
||||
|
||||
## Notes for etcd Version 2.2.1
|
||||
|
||||
@@ -52,7 +52,7 @@ your existing Corefile will be retained.
|
||||
## Installing kube-dns instead of CoreDNS with kubeadm
|
||||
|
||||
{{< note >}}
|
||||
**Note:** In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
|
||||
In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
|
||||
and is installed by default.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -75,16 +75,16 @@ The `static` policy allows containers in `Guaranteed` pods with integer CPU
|
||||
using the [cpuset cgroup controller](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs. The exclusivity only extends to other pods.
|
||||
System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs. The exclusivity only extends to other pods.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The alpha version of this policy does not guarantee static
|
||||
The alpha version of this policy does not guarantee static
|
||||
exclusive allocations across Kubelet restarts.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** CPU Manager doesn't support offlining and onlining of
|
||||
CPU Manager doesn't support offlining and onlining of
|
||||
CPUs at runtime. Also, if the set of online CPUs changes on the node,
|
||||
the node must be drained and CPU manager manually reset by deleting the
|
||||
state file `cpu_manager_state` in the kubelet root directory.
|
||||
@@ -102,7 +102,7 @@ both part of a `Guaranteed` pod and have integer CPU `requests` are assigned
|
||||
exclusive CPUs.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The kubelet requires a CPU reservation greater than zero be made
|
||||
The kubelet requires a CPU reservation greater than zero be made
|
||||
using either `--kube-reserved` and/or `--system-reserved` when the static
|
||||
policy is enabled. This is because zero CPU reservation would allow the shared
|
||||
pool to become empty.
|
||||
|
||||
@@ -21,7 +21,9 @@ Make sure you've configured a network provider with network policy support. Ther
|
||||
* [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
|
||||
* [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
|
||||
|
||||
**Note**: The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
|
||||
{{< note >}}
|
||||
The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
|
||||
{{< /note >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
@@ -66,9 +66,11 @@ resources from storage each provider that matches the stored data attempts to de
|
||||
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
|
||||
is returned which prevents clients from accessing that resource.
|
||||
|
||||
**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
|
||||
{{< caution >}}
|
||||
If any resource is not readable via the encryption config (because keys were changed),
|
||||
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
|
||||
read that resource will fail until it is deleted or a valid decryption key is provided.
|
||||
{{< /caution >}}
|
||||
|
||||
### Providers:
|
||||
|
||||
@@ -113,7 +115,9 @@ To create a new secret perform the following steps:
|
||||
3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
|
||||
4. Restart your API server.
|
||||
|
||||
**IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
|
||||
{{< caution >}}
|
||||
Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
## Verifying that data is encrypted
|
||||
|
||||
@@ -74,10 +74,12 @@ curl --header "Content-Type: application/json-patch+json" \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
**Note**: In the preceding request, `~1` is the encoding for the character / in
|
||||
{{< note >}}
|
||||
In the preceding request, `~1` is the encoding for the character / in
|
||||
the patch path. The operation path value in JSON-Patch is interpreted as a
|
||||
JSON-Pointer. For more details, see
|
||||
[IETF RFC 6901](https://tools.ietf.org/html/rfc6901), section 3.
|
||||
{{< /note >}}
|
||||
|
||||
The output shows that the Node has a capacity of 4 dongles:
|
||||
|
||||
|
||||
@@ -73,14 +73,16 @@ 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/configure-pod-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/configure-pod-configmap/) in a file called "config".
|
||||
**Note:** It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
|
||||
|
||||
{{< note >}}
|
||||
It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
|
||||
|
||||
```
|
||||
nonMasqueradeCIDRs:
|
||||
- 10.0.0.0/8
|
||||
resyncInterval: 60s
|
||||
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
Run the following command to add the config map to your cluster:
|
||||
|
||||
|
||||
@@ -24,8 +24,7 @@ Before proceeding:
|
||||
- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/).
|
||||
|
||||
{{< note >}}
|
||||
**Note**: All commands on any control plane or etcd node should be
|
||||
run as root.
|
||||
All commands on any control plane or etcd node should be run as root.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+1
-1
@@ -82,7 +82,7 @@ CPU request and limit to the Container.
|
||||
* Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** When creating a `LimitRange` object, you can specify limits on huge-pages
|
||||
When creating a `LimitRange` object, you can specify limits on huge-pages
|
||||
or GPUs as well. However, when both `default` and `defaultRequest` are specified
|
||||
on these resources, the two values must be the same.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -106,7 +106,9 @@ More information on `finalizers` can be found in the namespace [design doc](http
|
||||
$ kubectl delete namespaces <insert-some-namespace-name>
|
||||
```
|
||||
|
||||
**WARNING, this deletes _everything_ under the namespace!**
|
||||
{{< warning >}}
|
||||
This deletes _everything_ under the namespace!
|
||||
{{< /warning >}}
|
||||
|
||||
This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ allows you to change the configuration of each Kubelet in a live Kubernetes
|
||||
cluster by deploying a ConfigMap and configuring each Node to use it.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** All Kubelet configuration parameters can be changed dynamically,
|
||||
All Kubelet configuration parameters can be changed dynamically,
|
||||
but this is unsafe for some parameters. Before deciding to change a parameter
|
||||
dynamically, you need a strong understanding of how that change will affect your
|
||||
cluster's behavior. Always carefully test configuration changes on a small set
|
||||
@@ -69,7 +69,7 @@ This document only describes a single Node consuming each ConfigMap. Keep in
|
||||
mind that it is also valid for multiple Nodes to consume the same ConfigMap.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** While it is *possible* to change the configuration by
|
||||
While it is *possible* to change the configuration by
|
||||
updating the ConfigMap in-place, this causes all Kubelets configured with
|
||||
that ConfigMap to update simultaneously. It is much safer to treat ConfigMaps
|
||||
as immutable by convention, aided by `kubectl`'s `--append-hash` option,
|
||||
|
||||
@@ -37,10 +37,12 @@ hardware maintenance, etc.). Safe evictions allow the pod's containers
|
||||
to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
and will respect the `PodDisruptionBudgets` you have specified.
|
||||
|
||||
**Note:** By default `kubectl drain` will ignore certain system pods on the node
|
||||
{{< note >}}
|
||||
By default `kubectl drain` will ignore certain system pods on the node
|
||||
that cannot be killed; see
|
||||
the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
|
||||
documentation for more details.
|
||||
{{< /note >}}
|
||||
|
||||
When `kubectl drain` returns successfully, that indicates that all of
|
||||
the pods (except the ones excluded as described in the previous paragraph)
|
||||
|
||||
@@ -165,10 +165,12 @@ credentials from the API servers to their etcd server, such as mutual auth via T
|
||||
and it is often recommended to isolate the etcd servers behind a firewall that only the API servers
|
||||
may access.
|
||||
|
||||
**CAUTION:** Allowing other components within the cluster to access the master etcd instance with
|
||||
{{< caution >}}
|
||||
Allowing other components within the cluster to access the master etcd instance with
|
||||
read or write access to the full keyspace is equivalent to granting cluster-admin access. Using
|
||||
separate etcd instances for non-master components or using etcd ACLs to restrict read and write
|
||||
access to a subset of the keyspace is strongly recommended.
|
||||
{{< /caution >}}
|
||||
|
||||
### Enable audit logging
|
||||
|
||||
|
||||
@@ -100,11 +100,10 @@ Labels from the static pod are propagated into the mirror-pod and can be used as
|
||||
|
||||
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/) command), kubelet simply won't remove it.
|
||||
|
||||
{{<note>}}
|
||||
**Note**: Make sure the kubelet has permission to create the mirror pod in the API server.
|
||||
If not, the creation request is rejected by the API server. See
|
||||
{{< note >}}
|
||||
Make sure the kubelet has permission to create the mirror pod in the API server. If not, the creation request is rejected by the API server. See
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
|
||||
{{</note>}}
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
[joe@my-master ~] $ kubectl delete pod static-web-my-node1
|
||||
|
||||
@@ -58,7 +58,7 @@ The following sysctls are supported in the _safe_ set:
|
||||
- `net.ipv4.tcp_syncookies`.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
{{< /note >}}
|
||||
|
||||
This list will be extended in future Kubernetes versions when the kubelet
|
||||
@@ -141,7 +141,7 @@ spec:
|
||||
{{% capture discussion %}}
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
is at-your-own-risk and can lead to severe problems like wrong behavior of
|
||||
containers, resource shortage or complete breakage of a node.
|
||||
{{< /warning >}}
|
||||
@@ -184,7 +184,7 @@ Do not configure these two fields such that there is overlap, meaning that a
|
||||
given sysctl is both allowed and forbidden.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning**: If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
|
||||
If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
|
||||
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
|
||||
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
|
||||
flag as well on that node.
|
||||
|
||||
@@ -81,7 +81,7 @@ kubectl --context=federation-cluster delete configmap
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Deleting a Federated ConfigMap does not delete the corresponding ConfigMaps from underlying clusters. You must delete the underlying ConfigMaps manually.
|
||||
Deleting a Federated ConfigMap does not delete the corresponding ConfigMaps from underlying clusters. You must delete the underlying ConfigMaps manually.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -87,7 +87,7 @@ max replicas on the federated HPA object, and the sum of minimum replicas will b
|
||||
than or equal to the minimum specified on the federated HPA object.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A particular cluster cannot have a minimum replica sum of 0.
|
||||
A particular cluster cannot have a minimum replica sum of 0.
|
||||
{{< /note >}}
|
||||
|
||||
### Spreading HPA min and max replicas in underlying clusters
|
||||
@@ -125,8 +125,9 @@ in the previous section.
|
||||
You can delete a federated HPA as you would delete a Kubernetes
|
||||
HPA; however, for a federated HPA, you must send the request to
|
||||
the federation API server instead of to a specific Kubernetes cluster.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** For the federated resource to be deleted from all underlying clusters, [cascading deletion](/docs/concepts/cluster-administration/federation/#cascading-deletion) should be used.
|
||||
For the federated resource to be deleted from all underlying clusters, [cascading deletion](/docs/concepts/cluster-administration/federation/#cascading-deletion) should be used.
|
||||
{{< /note >}}
|
||||
|
||||
For example, you can do that using `kubectl` by running:
|
||||
|
||||
@@ -99,7 +99,7 @@ kubectl --context=federation-cluster delete job myjob
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Deleting a federated job will not delete the
|
||||
Deleting a federated job will not delete the
|
||||
corresponding jobs from underlying clusters.
|
||||
You must delete the underlying jobs manually.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -84,7 +84,7 @@ As in Kubernetes, deleting a federated Namespace will delete all resources in th
|
||||
Namespace from the federation control plane.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future.
|
||||
At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -124,7 +124,7 @@ kubectl --context=federation-cluster delete rs myrs
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** At this point, deleting a federated ReplicaSet will not delete the corresponding ReplicaSets from underlying clusters. You must delete the underlying ReplicaSets manually. We intend to fix this in the future.
|
||||
At this point, deleting a federated ReplicaSet will not delete the corresponding ReplicaSets from underlying clusters. You must delete the underlying ReplicaSets manually. We intend to fix this in the future.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -87,7 +87,7 @@ kubectl --context=federation-cluster delete secret mysecret
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future.
|
||||
At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -120,7 +120,7 @@ cpu-demo 974m <something>
|
||||
Recall that by setting `-cpu "2"`, you configured the Container to attempt to use 2 CPUs, but the Container is only being allowed to use about 1 CPU. The Container CPU use is being throttled, because the Container is attempting to use more CPU resources than its limit.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Another possible explanation for the CPU throttling is that the Node might not have
|
||||
Another possible explanation for the CPU throttling is that the Node might not have
|
||||
enough CPU resources available. Recall that the prerequisites for this exercise require each of
|
||||
your Nodes to have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container
|
||||
cannot use more than 1 CPU regardless of the CPU limit specified for the Container.
|
||||
|
||||
@@ -77,7 +77,7 @@ unless the Pod's grace period expires. For more details, see
|
||||
[Termination of Pods](/docs/user-guide/pods/#termination-of-pods).
|
||||
|
||||
{{< note >}}
|
||||
**Note**: Kubernetes only sends the preStop event when a Pod is *terminated*.
|
||||
Kubernetes only sends the preStop event when a Pod is *terminated*.
|
||||
This means that the preStop hook is not invoked when the Pod is *completed*.
|
||||
This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807).
|
||||
{{< /note >}}
|
||||
|
||||
+1
-1
@@ -189,7 +189,7 @@ annotation or the Pod’s specification, is applied to the first process run in
|
||||
each Container.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: When a Pod consumes a PersistentVolume, the GIDs associated with the
|
||||
When a Pod consumes a PersistentVolume, the GIDs associated with the
|
||||
PersistentVolume are not present on the Pod resource itself.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -388,7 +388,7 @@ metadata:
|
||||
## Configure all key-value pairs in a ConfigMap as container environment variables
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This functionality is available in Kubernetes v1.6 and later.
|
||||
This functionality is available in Kubernetes v1.6 and later.
|
||||
{{< /note >}}
|
||||
|
||||
1. Create a ConfigMap containing multiple key-value pairs.
|
||||
@@ -516,7 +516,7 @@ special.type
|
||||
```
|
||||
|
||||
{{< caution >}}
|
||||
**Caution:** If there are some files in the `/etc/config/` directory, they will be deleted.
|
||||
If there are some files in the `/etc/config/` directory, they will be deleted.
|
||||
{{< /caution >}}
|
||||
|
||||
### Add ConfigMap data to a specific path in the Volume
|
||||
@@ -563,7 +563,7 @@ basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files
|
||||
When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A container using a ConfigMap as a
|
||||
A container using a ConfigMap as a
|
||||
[subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive
|
||||
ConfigMap updates.
|
||||
{{< /note >}}
|
||||
@@ -577,7 +577,7 @@ ConfigMap updates.
|
||||
The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
|
||||
ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
|
||||
{{< /note >}}
|
||||
|
||||
The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
|
||||
@@ -618,7 +618,7 @@ data:
|
||||
This includes pods created via the Kubelet's --manifest-url flag, --config flag, or the Kubelet REST API.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** These are not commonly-used ways to create pods.
|
||||
These are not commonly-used ways to create pods.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -15,7 +15,7 @@ A service account provides an identity for processes that run in a Pod.
|
||||
[Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/).*
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This document describes how service accounts behave in a cluster set up
|
||||
This document describes how service accounts behave in a cluster set up
|
||||
as recommended by the Kubernetes project. Your cluster administrator may have
|
||||
customized the behavior in your cluster, in which case this documentation may
|
||||
not apply.
|
||||
@@ -175,7 +175,7 @@ token: ...
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The content of `token` is elided here.
|
||||
The content of `token` is elided here.
|
||||
{{< /note >}}
|
||||
|
||||
## Add ImagePullSecrets to a service account
|
||||
@@ -254,7 +254,7 @@ TODO: Test and explain how to use additional non-K8s secrets with an existing se
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This ServiceAccountTokenVolumeProjection is __beta__ in 1.12 and
|
||||
This ServiceAccountTokenVolumeProjection is __beta__ in 1.12 and
|
||||
enabled by passing all of the following flags to the API server:
|
||||
|
||||
* `--service-account-issuer`
|
||||
|
||||
@@ -53,7 +53,7 @@ The output contains a section similar to this:
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
|
||||
If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
|
||||
{{< /note >}}
|
||||
|
||||
## Create a Secret in the cluster that holds your authorization token
|
||||
|
||||
@@ -84,7 +84,7 @@ spec:
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
|
||||
If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
|
||||
automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
|
||||
CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
|
||||
the limit.
|
||||
|
||||
@@ -299,7 +299,7 @@ See [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/li
|
||||
for definitions of the capability constants.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
|
||||
Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
|
||||
{{< /note >}}
|
||||
|
||||
## Assign SELinux labels to a Container
|
||||
@@ -318,7 +318,7 @@ securityContext:
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** To assign SELinux labels, the SELinux security module must be loaded on the host operating system.
|
||||
To assign SELinux labels, the SELinux security module must be loaded on the host operating system.
|
||||
{{< /note >}}
|
||||
|
||||
## Discussion
|
||||
@@ -339,7 +339,7 @@ need to set the `level` section. This sets the
|
||||
label given to all Containers in the Pod as well as the Volumes.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
|
||||
After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
|
||||
{{< /warning >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -296,7 +296,9 @@ INFO OpenShift file "foo-imagestream.yaml" created
|
||||
INFO OpenShift file "foo-buildconfig.yaml" created
|
||||
```
|
||||
|
||||
**Note**: If you are manually pushing the Openshift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this Openshift issue: https://github.com/openshift/origin/issues/4518 .
|
||||
{{< note >}}
|
||||
If you are manually pushing the Openshift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this Openshift issue: https://github.com/openshift/origin/issues/4518 .
|
||||
{{< /note >}}
|
||||
|
||||
## `kompose up`
|
||||
|
||||
@@ -335,6 +337,7 @@ pod/frontend-2768218532-cs5t5 1/1 Running 0 4m
|
||||
pod/redis-master-1432129712-63jn8 1/1 Running 0 4m
|
||||
pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
|
||||
```
|
||||
|
||||
**Note**:
|
||||
|
||||
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
|
||||
@@ -550,7 +553,9 @@ The currently supported options are:
|
||||
| kompose.service.type | nodeport / clusterip / loadbalancer |
|
||||
| kompose.service.expose| true / hostname |
|
||||
|
||||
**Note**: `kompose.service.type` label should be defined with `ports` only, otherwise `kompose` will fail.
|
||||
{{< note >}}
|
||||
The `kompose.service.type` label should be defined with `ports` only, otherwise `kompose` will fail.
|
||||
{{< /note >}}
|
||||
|
||||
## Restart
|
||||
|
||||
@@ -563,7 +568,9 @@ If you want to create normal pods without controllers you can use `restart` cons
|
||||
| `on-failure` | Pod | `OnFailure` |
|
||||
| `no` | Pod | `Never` |
|
||||
|
||||
**Note**: controller object could be `deployment` or `replicationcontroller`, etc.
|
||||
{{< note >}}
|
||||
The controller object could be `deployment` or `replicationcontroller`, etc.
|
||||
{{< /note >}}
|
||||
|
||||
For e.g. `pival` service will become pod down here. This container calculated value of `pi`.
|
||||
|
||||
|
||||
@@ -46,8 +46,8 @@ Each request can be recorded with an associated "stage". The known stages are:
|
||||
- `Panic` - Events generated when a panic occurred.
|
||||
|
||||
{{< note >}}
|
||||
**Note** The audit logging feature increases the memory consumption of the API
|
||||
server because some context required for auditing is stored for each request.
|
||||
The audit logging feature increases the memory consumption of the API server
|
||||
because some context required for auditing is stored for each request.
|
||||
Additionally, memory consumption depends on the audit logging configuration.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -102,7 +102,7 @@ In both cases, audit events structure is defined by the API in the
|
||||
[`v1`][auditing-api].
|
||||
|
||||
{{< note >}}
|
||||
**Note:** In case of patches, request body is a JSON array with patch operations, not a JSON object
|
||||
In case of patches, request body is a JSON array with patch operations, not a JSON object
|
||||
with an appropriate Kubernetes API object. For example, the following request body is a valid patch
|
||||
request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
|
||||
|
||||
@@ -216,7 +216,7 @@ In this example, we will use fluentd to split audit events by different namespac
|
||||
|
||||
1. install [fluentd][fluentd_install_doc], fluent-plugin-forest and fluent-plugin-rewrite-tag-filter in the kube-apiserver node
|
||||
{{< note >}}
|
||||
**Note:** Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
|
||||
Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
|
||||
{{< /note >}}
|
||||
|
||||
1. create a config file for fluentd
|
||||
|
||||
@@ -34,7 +34,7 @@ The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blo
|
||||
repository. You can find more information about the API there.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
|
||||
The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
|
||||
{{< /note >}}
|
||||
|
||||
## Metrics Server
|
||||
|
||||
@@ -67,7 +67,7 @@ debug: true
|
||||
The following examples show some `crictl` commands and example output.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** If you use `crictl` to create pod sandboxes or containers on a running
|
||||
If you use `crictl` to create pod sandboxes or containers on a running
|
||||
Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a
|
||||
general purpose workflow tool, but a tool that is useful for debugging.
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -84,7 +84,7 @@ $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** `-c ${CONTAINER_NAME}` is optional. You can omit it for Pods that only contain a single container.
|
||||
`-c ${CONTAINER_NAME}` is optional. You can omit it for Pods that only contain a single container.
|
||||
{{< /note >}}
|
||||
|
||||
As an example, to look at the logs from a running Cassandra pod, you might run
|
||||
|
||||
@@ -112,8 +112,10 @@ Alternately, you can run commands inside that container with `exec`:
|
||||
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
|
||||
```
|
||||
|
||||
{{< note >}}**Note:** `-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
|
||||
only contain a single container.{{< /note >}}
|
||||
{{< note >}}
|
||||
`-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
|
||||
only contain a single container.
|
||||
{{< /note >}}
|
||||
|
||||
As an example, to look at the logs from a running Cassandra pod, you might run:
|
||||
|
||||
|
||||
@@ -79,7 +79,7 @@ deployment.apps/hostnames created
|
||||
|
||||
`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
|
||||
{{< note >}}
|
||||
**Note:** This is the same as if you started the `Deployment` with the following YAML:
|
||||
This is the same as if you started the `Deployment` with the following YAML:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
@@ -214,7 +214,10 @@ The "cluster.local" is your cluster domain, which COULD be different in your
|
||||
own cluster.
|
||||
|
||||
You can also try this from a `Node` in the cluster:
|
||||
{{< note >}}**Note:** 10.0.0.10 is my DNS `Service`, yours might be different){{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
10.0.0.10 is my DNS `Service`, yours might be different).
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10
|
||||
@@ -383,8 +386,11 @@ as the `Service` selecting for `run=hostnames`, but the `Deployment` specifying
|
||||
|
||||
At this point, we know that your `Service` exists and has selected your `Pods`.
|
||||
Let's check that the `Pods` are actually working - we can bypass the `Service`
|
||||
mechanism and go straight to the `Pods`.
|
||||
{{< note >}}**Note:** These commands use the `Pod` port (9376), rather than the `Service` port (80).{{< /note >}}
|
||||
mechanism and go straight to the `Pods`.
|
||||
|
||||
{{< note >}}
|
||||
These commands use the `Pod` port (9376), rather than the `Service` port (80).
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
u@pod$ wget -qO- 10.244.0.5:9376
|
||||
|
||||
@@ -25,7 +25,7 @@ This article describes a solution that exports Kubernetes events to
|
||||
Stackdriver Logging, where they can be processed and analyzed.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** It is not guaranteed that all events happening in a cluster will be
|
||||
It is not guaranteed that all events happening in a cluster will be
|
||||
exported to Stackdriver. One possible scenario when events will not be
|
||||
exported is when event exporter is not running (e.g. during restart or
|
||||
upgrade). In most cases it's fine to use events for purposes like setting up
|
||||
|
||||
@@ -18,7 +18,7 @@ them using [Kibana](https://www.elastic.co/products/kibana), as an alternative t
|
||||
Stackdriver Logging when running on GCE.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
|
||||
You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Before reading this page, it's highly recommended to familiarize yourself
|
||||
with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** By default, Stackdriver logging collects only your container's standard output and
|
||||
By default, Stackdriver logging collects only your container's standard output and
|
||||
standard error streams. To collect any logs your application writes to a file (for example),
|
||||
see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
|
||||
in the Kubernetes logging overview.
|
||||
@@ -52,7 +52,7 @@ consider starting a cluster without a pre-configured logging solution and then d
|
||||
Stackdriver Logging agents to the running cluster.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** The Stackdriver logging daemon has known issues on platforms other
|
||||
The Stackdriver logging daemon has known issues on platforms other
|
||||
than Google Kubernetes Engine. Proceed at your own risk.
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -88,9 +88,11 @@ than Google Kubernetes Engine. Proceed at your own risk.
|
||||
kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
|
||||
```
|
||||
|
||||
{{< note >}}**Note:** If a node fails and has to be recreated, you must re-apply the label to
|
||||
{{< note >}}
|
||||
If a node fails and has to be recreated, you must re-apply the label to
|
||||
the recreated node. To make this easier, you can use Kubelet's command-line parameter
|
||||
for applying node labels in your node startup script.{{< /note >}}
|
||||
for applying node labels in your node startup script.
|
||||
{{< /note >}}
|
||||
|
||||
1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
|
||||
|
||||
@@ -263,8 +265,12 @@ In this case you need to be able to change the parameters of `DaemonSet` and `Co
|
||||
If you're using GKE and Stackdriver Logging is enabled in your cluster, you
|
||||
cannot change its configuration, because it's managed and supported by GKE.
|
||||
However, you can disable the default integration and deploy your own.
|
||||
{{< note >}}**Note:** You will have to support and maintain a newly deployed configuration
|
||||
yourself: update the image and configuration, adjust the resources and so on.{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
You will have to support and maintain a newly deployed configuration
|
||||
yourself: update the image and configuration, adjust the resources and so on.
|
||||
{{< /note >}}
|
||||
|
||||
To disable the default logging integration, use the following command:
|
||||
|
||||
```
|
||||
@@ -325,7 +331,10 @@ kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-
|
||||
|
||||
Then in the value for the key `containers.input.conf` insert a new filter right after
|
||||
the `source` section.
|
||||
{{< note >}}**Note:** Order is important.{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Order is important.
|
||||
{{< /note >}}
|
||||
|
||||
Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
|
||||
to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
|
||||
|
||||
@@ -8,7 +8,9 @@ toc_hide: true
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
**NOTE:** Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
|
||||
{{< note >}}
|
||||
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
|
||||
{{< /note >}}
|
||||
|
||||
This page shows how to ...
|
||||
|
||||
|
||||
@@ -18,9 +18,10 @@ of plugins as a means of utilizing these building blocks to create more complex
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
You need to have a working `kubectl` binary installed.
|
||||
You need to have a working `kubectl` binary installed.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Plugins were officially introduced as an alpha feature in the v1.8.0 release. They have been re-worked in the v1.12.0 release to support a wider range of use-cases. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.12.0 or later is recommended if you are following these docs.
|
||||
Plugins were officially introduced as an alpha feature in the v1.8.0 release. They have been re-worked in the v1.12.0 release to support a wider range of use-cases. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.12.0 or later is recommended if you are following these docs.
|
||||
{{< /note >}}
|
||||
|
||||
Until a GA version is released, plugins should be considered unstable, and their underlying mechanism is prone to change.
|
||||
@@ -34,7 +35,7 @@ Until a GA version is released, plugins should be considered unstable, and their
|
||||
A plugin is nothing more than a standalone executable file, whose name begins with `kubectl-`. To install a plugin, simply move this executable file to anywhere on your PATH.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Kubernetes does not provide a package manager or anything similar to install or update plugins. It is your responsibility to ensure that plugin executables have a filename that begins with `kubectl-`, and that they are placed somewhere on your PATH.
|
||||
Kubernetes does not provide a package manager or anything similar to install or update plugins. It is your responsibility to ensure that plugin executables have a filename that begins with `kubectl-`, and that they are placed somewhere on your PATH.
|
||||
{{< /note >}}
|
||||
|
||||
### Discovering plugins
|
||||
@@ -127,7 +128,7 @@ For example, a plugin that wishes to be invoked whenever the command `kubectl fo
|
||||
#### Flags and argument handling
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Unlike previous versions of `kubectl`, the plugin mechanism will _not_ create any custom, plugin-specific values or environment variables to a plugin process.
|
||||
Unlike previous versions of `kubectl`, the plugin mechanism will _not_ create any custom, plugin-specific values or environment variables to a plugin process.
|
||||
This means that environment variables such as `KUBECTL_PLUGINS_CURRENT_NAMESPACE` are no longer provided to a plugin. Plugins must parse all of the arguments passed to them by a user,
|
||||
and handle flag validation as part of their own implementation. For plugins written in Go, a set of utilities has been provided under [k8s.io/cli-runtime](https://github.com/kubernetes/cli-runtime) to assist with this.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -135,7 +135,7 @@ Events: <none>
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The 'LoadBalancer Ingress' addresses of your Federated Service
|
||||
The 'LoadBalancer Ingress' addresses of your Federated Service
|
||||
correspond with the 'LoadBalancer Ingress' addresses of all of the
|
||||
underlying Kubernetes services (once these have been allocated - this
|
||||
may take a few seconds). For inter-cluster and inter-cloud-provider
|
||||
@@ -222,7 +222,7 @@ nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
|
||||
If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
|
||||
|
||||
``` shell
|
||||
$ aws route53 list-hosted-zones
|
||||
|
||||
@@ -44,7 +44,7 @@ Download the client tarball corresponding to the particular release and
|
||||
extract the binaries in the tarball:
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Until Kubernetes version `1.8.x` the federation project was
|
||||
Until Kubernetes version `1.8.x` the federation project was
|
||||
maintained as part of the [core kubernetes repo](https://github.com/kubernetes/kubernetes).
|
||||
Between Kubernetes releases `1.8` and `1.9`, the federation project moved into
|
||||
a separate [federation repo](https://github.com/kubernetes/federation), where it is
|
||||
@@ -59,7 +59,7 @@ curl -LO https://storage.googleapis.com/kubernetes-release/release/${RELEASE-VER
|
||||
tar -xzvf kubernetes-client-linux-amd64.tar.gz
|
||||
```
|
||||
{{< note >}}
|
||||
**Note:** The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed.
|
||||
The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed.
|
||||
{{< /note >}}
|
||||
|
||||
Copy the extracted binary to one of the directories in your `$PATH`
|
||||
@@ -78,7 +78,7 @@ tar -xzvf federation-client-linux-amd64.tar.gz
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases).
|
||||
The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases).
|
||||
{{< /note >}}
|
||||
|
||||
Copy the extracted binary to one of the directories in your `$PATH`
|
||||
@@ -179,7 +179,7 @@ modify a Google Kubernetes Engine cluster directly to add this scope, but you ca
|
||||
new node pool for your cluster and delete the old one.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This will cause pods in the cluster to be rescheduled.
|
||||
This will cause pods in the cluster to be rescheduled.
|
||||
{{< /note >}}
|
||||
|
||||
To add the new node pool, run:
|
||||
@@ -200,8 +200,9 @@ gcloud container node-pools delete default-pool --cluster gke-cluster
|
||||
`kubefed init` sets up the federation control plane in the host
|
||||
cluster and also adds an entry for the federation API server in your
|
||||
local kubeconfig.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** In the beta release of Kubernetes 1.6, `kubefed init` does not automatically set the current context to the
|
||||
In the beta release of Kubernetes 1.6, `kubefed init` does not automatically set the current context to the
|
||||
newly deployed federation. You can set the current context manually by running:
|
||||
|
||||
```shell
|
||||
@@ -466,7 +467,7 @@ A new context has now been added to your kubeconfig named `fellowship` (after th
|
||||
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The name that you provide to the `join` command is used as the joining cluster's identity in federation. This name should adhere to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
|
||||
The name that you provide to the `join` command is used as the joining cluster's identity in federation. This name should adhere to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
|
||||
corresponding to your joining cluster conforms to these rules, you can use the same name in the join command. Otherwise, you must choose a different name for your cluster's identity.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -515,7 +516,7 @@ kubefed join noldor --host-cluster-context=rivendell --secret-name=11kingdom
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If your cluster name does not conform to the DNS subdomain name specification, all you need to do is supply the secret name using the `--secret-name` flag. `kubefed join` automatically creates the secret for you.
|
||||
If your cluster name does not conform to the DNS subdomain name specification, all you need to do is supply the secret name using the `--secret-name` flag. `kubefed join` automatically creates the secret for you.
|
||||
{{< /note >}}
|
||||
|
||||
### `kube-dns` configuration
|
||||
@@ -555,7 +556,7 @@ kubectl delete ns federation-system --context=rivendell
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** `rivendell` is the host cluster name. Replace that name with the appropriate name in your configuration.
|
||||
`rivendell` is the host cluster name. Replace that name with the appropriate name in your configuration.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -118,15 +118,19 @@ coredns-provider.conf has below format:
|
||||
- `zones` is the federation domain for which CoreDNS is authoritative and is same as --dns-zone-name flag of `kubefed init`.
|
||||
- `coredns-endpoints` is the endpoint to access CoreDNS server. This is an optional parameter introduced from v1.7 onwards.
|
||||
|
||||
{{< note >}}**Note**: *plugins.etcd.zones in CoreDNS configuration and --dns-zone-name flag to kubefed init should match.*{{< /note >}}
|
||||
{{< note >}}
|
||||
`plugins.etcd.zones` in the CoreDNS configuration and the `--dns-zone-name` flag to `kubefed init` should match.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## Setup CoreDNS server in nameserver resolv.conf chain
|
||||
|
||||
*Note: The following section applies only to versions prior to v1.7
|
||||
{{< note >}}
|
||||
The following section applies only to versions prior to v1.7
|
||||
and will be automatically taken care of if the `coredns-endpoints`
|
||||
parameter is configured in `coredns-provider.conf` as described in
|
||||
section above.*
|
||||
section above.
|
||||
{{< /note >}}
|
||||
|
||||
Once the federation control plane is deployed and federated clusters
|
||||
are joined to the federation, you need to add the CoreDNS server to the
|
||||
|
||||
@@ -35,7 +35,7 @@ If you define args, but do not define a command, the default command is used
|
||||
with your new arguments.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** the `command` field corresponds to `entrypoint` in some container
|
||||
The `command` field corresponds to `entrypoint` in some container
|
||||
runtimes. Refer to the [Notes](#notes) below.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -85,7 +85,7 @@ and
|
||||
[Secrets](/docs/concepts/configuration/secret/).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The environment variable appears in parentheses, `"$(VAR)"`. This is
|
||||
The environment variable appears in parentheses, `"$(VAR)"`. This is
|
||||
required for the variable to be expanded in the `command` or `args` field.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
+1
-1
@@ -79,7 +79,7 @@ Pod:
|
||||
1. To exit the shell, enter `exit`.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The environment variables set using the `env` or `envFrom` field
|
||||
The environment variables set using the `env` or `envFrom` field
|
||||
will override any environment variables specified in the container image.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -42,9 +42,10 @@ username and password:
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret.yaml
|
||||
```
|
||||
{{< note >}}
|
||||
**Note:** If you want to skip the Base64 encoding step, you can create a Secret by using the `kubectl create secret` command:
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
If you want to skip the Base64 encoding step, you can create a Secret by using the `kubectl create secret` command:
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
|
||||
```
|
||||
@@ -79,7 +80,7 @@ username and password:
|
||||
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you want to skip the Base64 encoding step, you can create a Secret
|
||||
If you want to skip the Base64 encoding step, you can create a Secret
|
||||
by using the `kubectl create secret` command:
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
+3
-3
@@ -49,7 +49,7 @@ The second element specifies that the value of the Pod's `annotations`
|
||||
field should be stored in a file named `annotations`.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The fields in this example are Pod fields. They are not
|
||||
The fields in this example are Pod fields. They are not
|
||||
fields of the Container in the Pod.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -139,7 +139,7 @@ atomically using
|
||||
[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A container using Downward API as a
|
||||
A container using Downward API as a
|
||||
[subPath](/docs/concepts/storage/volumes/#using-subpath) volume mount will not
|
||||
receive Downward API updates.
|
||||
{{< /note >}}
|
||||
@@ -221,7 +221,7 @@ In addition, the following information is available through
|
||||
* `metadata.annotations` - all of the pod’s annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If CPU and memory limits are not specified for a Container, the
|
||||
If CPU and memory limits are not specified for a Container, the
|
||||
Downward API defaults to the node allocatable value for CPU and memory.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
+1
-1
@@ -48,7 +48,7 @@ variable gets its value from the Pod's `spec.nodeName` field. Similarly, the
|
||||
other environment variables get their names from Pod fields.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The fields in this example are Pod fields. They are not fields of the
|
||||
The fields in this example are Pod fields. They are not fields of the
|
||||
Container in the Pod.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -14,9 +14,11 @@ These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks o
|
||||
Cron jobs are useful for creating periodic and recurring tasks, like running backups or sending emails.
|
||||
Cron jobs can also schedule individual tasks for a specific time, such as if you want to schedule a job for a low activity period.
|
||||
|
||||
**Note:** CronJob resource in `batch/v2alpha1` API group has been deprecated starting from cluster version 1.8.
|
||||
{{< note >}}
|
||||
CronJob resource in `batch/v2alpha1` API group has been deprecated starting from cluster version 1.8.
|
||||
You should switch to using `batch/v1beta1`, instead, which is enabled by default in the API server.
|
||||
Examples in this document use `batch/v1beta1` in all examples.
|
||||
{{< /note >}}
|
||||
|
||||
Cron jobs have limitations and idiosyncrasies.
|
||||
For example, in certain circumstances, a single cron job can create multiple jobs.
|
||||
@@ -123,7 +125,9 @@ and [using kubectl to manage resources](/docs/user-guide/working-with-resources)
|
||||
|
||||
A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
|
||||
|
||||
**Note:** All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
|
||||
{{< note >}}
|
||||
All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
|
||||
{{< /note >}}
|
||||
|
||||
### Schedule
|
||||
|
||||
@@ -139,8 +143,9 @@ The format also includes extended `vixie cron` step values. As explained in the
|
||||
> ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps are also permitted after an
|
||||
> asterisk, so if you want to say ``every two hours'', just use ``*/2''.
|
||||
|
||||
|
||||
**Note:** The question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field.
|
||||
{{< note >}}
|
||||
The question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field.
|
||||
{{< /note >}}
|
||||
|
||||
### Job Template
|
||||
|
||||
@@ -187,7 +192,7 @@ This setting does not apply to already started executions.
|
||||
Defaults to false.
|
||||
|
||||
{{< caution >}}
|
||||
**Caution:** Executions that are suspended during their scheduled time count as missed jobs.
|
||||
Executions that are suspended during their scheduled time count as missed jobs.
|
||||
When `.spec.suspend` changes from `true` to `false` on an existing cron job without a [starting deadline](#starting-deadline), the missed jobs are scheduled immediately.
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
@@ -140,7 +140,7 @@ previous revision through other commands, such as `kubectl edit` or `kubectl
|
||||
apply`.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** DaemonSet revisions only roll forward. That is to say, after a
|
||||
DaemonSet revisions only roll forward. That is to say, after a
|
||||
rollback completes, the revision number (`.revision` field) of the
|
||||
`ControllerRevision` being rolled back to will advance. For example, if you
|
||||
have revision 1 and 2 in the system, and roll back from revision 2 to revision
|
||||
|
||||
@@ -159,9 +159,10 @@ kubectl get pods -l <daemonset-selector-key>=<daemonset-selector-value> -o wide
|
||||
```
|
||||
|
||||
Once you've found those nodes, delete some non-DaemonSet pods from the node to
|
||||
make room for new DaemonSet pods.
|
||||
make room for new DaemonSet pods.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
|
||||
This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
|
||||
replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
|
||||
either.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -91,7 +91,7 @@ of the number of pods from that set that can be unavailable after the eviction.
|
||||
It can be either an absolute number or a percentage.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
|
||||
For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
|
||||
object using the `kubectl` command line tool, the `minAvailable` field has a
|
||||
default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified.
|
||||
{{< /note >}}
|
||||
@@ -117,12 +117,14 @@ of the desired replicas are unhealthy.
|
||||
In typical usage, a single budget would be used for a collection of pods managed by
|
||||
a controller—for example, the pods in a single ReplicaSet or StatefulSet.
|
||||
|
||||
**Note:** A disruption budget does not truly guarantee that the specified
|
||||
{{< note >}}
|
||||
A disruption budget does not truly guarantee that the specified
|
||||
number/percentage of pods will always be up. For example, a node that hosts a
|
||||
pod from the collection may fail when the collection is at the minimum size
|
||||
specified in the budget, thus bringing the number of available pods from the
|
||||
collection below the specified size. The budget can only protect against
|
||||
voluntary evictions, not all causes of unavailability.
|
||||
{{< /note >}}
|
||||
|
||||
A `maxUnavailable` of 0% (or 0) or a `minAvailable` of 100% (or equal to the
|
||||
number of replicas) may block node drains entirely. This is permitted as per the
|
||||
|
||||
@@ -59,7 +59,9 @@ kubectl delete pods -l app=myapp
|
||||
|
||||
Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
|
||||
|
||||
**Note: Use caution when deleting a PVC, as it may lead to data loss.**
|
||||
{{< note >}}
|
||||
Use caution when deleting a PVC, as it may lead to data loss.
|
||||
{{< /note >}}
|
||||
|
||||
### Complete deletion of a StatefulSet
|
||||
|
||||
|
||||
@@ -130,9 +130,11 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 7 7 7 7 19m
|
||||
```
|
||||
|
||||
**Note** Sometimes it may take a few minutes to stabilize the number of replicas.
|
||||
Since the amount of load is not controlled in any way it may happen that the final number of replicas will
|
||||
differ from this example.
|
||||
{{< note >}}
|
||||
It may take a few minutes to stabilize the number of replicas. Since the amount
|
||||
of load is not controlled in any way it may happen that the final number of replicas
|
||||
will differ from this example.
|
||||
{{< /note >}}
|
||||
|
||||
## Stop load
|
||||
|
||||
@@ -156,7 +158,7 @@ php-apache 1 1 1 1 27m
|
||||
Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas back down to 1.
|
||||
|
||||
{{< note >}}
|
||||
**Note** autoscaling the replicas may take a few minutes.
|
||||
Autoscaling the replicas may take a few minutes.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -222,11 +222,11 @@ upscale delay.
|
||||
The default value is 5 minutes (`5m0s`).
|
||||
|
||||
{{< note >}}
|
||||
**Note**: When tuning these parameter values, a cluster operator should be aware of
|
||||
the possible consequences. If the delay (cooldown) value is set too long, there
|
||||
could be complaints that the Horizontal Pod Autoscaler is not responsive to workload
|
||||
changes. However, if the delay value is set too short, the scale of the replicas set
|
||||
may keep thrashing as usual.
|
||||
When tuning these parameter values, a cluster operator should be aware of the possible
|
||||
consequences. If the delay (cooldown) value is set too long, there could be complaints
|
||||
that the Horizontal Pod Autoscaler is not responsive to workload changes. However, if
|
||||
the delay value is set too short, the scale of the replicas set may keep thrashing as
|
||||
usual.
|
||||
{{< /note >}}
|
||||
|
||||
## Support for multiple metrics
|
||||
@@ -238,10 +238,12 @@ proposed scales will be used as the new scale.
|
||||
|
||||
## Support for custom metrics
|
||||
|
||||
**Note**: Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
|
||||
{{< note >}}
|
||||
Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
|
||||
Support for these annotations was removed in Kubernetes 1.6 in favor of the new autoscaling API. While the old method for collecting
|
||||
custom metrics is still available, these metrics will not be available for use by the Horizontal Pod Autoscaler, and the former
|
||||
annotations for specifying which custom metrics to scale on are no longer honored by the Horizontal Pod Autoscaler controller.
|
||||
{{< /note >}}
|
||||
|
||||
Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler.
|
||||
You can add custom metrics for the Horizontal Pod Autoscaler to use in the `autoscaling/v2beta2` API.
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 80
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< note >}}
|
||||
**Note**: The preferred way to create a replicated application is to use a
|
||||
The preferred way to create a replicated application is to use a
|
||||
[Deployment](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps),
|
||||
which in turn uses a
|
||||
[ReplicaSet](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicaset-v1-apps).
|
||||
|
||||
@@ -68,7 +68,7 @@ AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
|
||||
By default, `helm init` installs the Tiller Pod into the `kube-system` namespace, with Tiller configured to use the `default` service account.
|
||||
|
||||
{{< note >}}
|
||||
**NOTE:** If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
|
||||
If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
|
||||
{{< /note >}}
|
||||
|
||||
Configure Tiller to have `cluster-admin` access:
|
||||
|
||||
@@ -50,7 +50,7 @@ The following section demonstrates how to create a TLS certificate for a
|
||||
Kubernetes service accessed through DNS.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://blog.cloudflare.com/introducing-cfssl/) to know more.
|
||||
This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://blog.cloudflare.com/introducing-cfssl/) to know more.
|
||||
{{< /note >}}
|
||||
|
||||
## Download and install CFSSL
|
||||
|
||||
@@ -106,7 +106,7 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
|
||||
If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
|
||||
{{< /note >}}
|
||||
|
||||
The installer creates `$HOME/.kube` and instructs it to create a config file
|
||||
@@ -118,7 +118,7 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Updating the installation is performed by rerunning the two commands listed in step 1.
|
||||
Updating the installation is performed by rerunning the two commands listed in step 1.
|
||||
{{< /note >}}
|
||||
|
||||
## Install with Chocolatey on Windows
|
||||
@@ -153,9 +153,13 @@ If you are on Windows and using [Chocolatey](https://chocolatey.org) package man
|
||||
```
|
||||
|
||||
6. Configure kubectl to use a remote Kubernetes cluster:
|
||||
New-Item config -type file
|
||||
|
||||
```
|
||||
New-Item config -type file
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Edit the config file with a text editor of your choice, such as Notepad.
|
||||
Edit the config file with a text editor of your choice, such as Notepad.
|
||||
{{< /note >}}
|
||||
|
||||
## Download as part of the Google Cloud SDK
|
||||
|
||||
@@ -30,7 +30,7 @@ If you do not already have a hypervisor installed, install the appropriate one f
|
||||
[KVM](http://www.linux-kvm.org/).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Minikube also supports a `-\-vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires Docker and a linux environment, but not a hypervisor.
|
||||
Minikube also supports a `-\-vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires Docker and a linux environment, but not a hypervisor.
|
||||
{{< /note >}}
|
||||
|
||||
* Windows: [VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
|
||||
|
||||
Reference in New Issue
Block a user