merge upstream master
This commit is contained in:
Zach Arnold
@@ -251,11 +251,11 @@ rules:
|
||||
|
||||
The following cloud providers have implemented CCMs:
|
||||
|
||||
* Digital Ocean
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* Azure
|
||||
* GCE
|
||||
* AWS
|
||||
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
|
||||
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
|
||||
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
|
||||
|
||||
## Cluster Administration
|
||||
|
||||
|
||||
@@ -32,8 +32,6 @@ Before choosing a guide, here are some considerations:
|
||||
|
||||
Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
|
||||
-If you are using a guide involving Salt, see [Configuring Kubernetes with Salt](/docs/setup/salt/).
|
||||
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
|
||||
|
||||
@@ -71,15 +71,29 @@ A desired state of an object is described by a Deployment, and if changes to tha
|
||||
|
||||
## Container Images
|
||||
|
||||
- The default [imagePullPolicy](/docs/concepts/containers/images/#updating-images) for a container is `IfNotPresent`, which causes the [kubelet](/docs/admin/kubelet/) to pull an image only if it does not already exist locally. If you want the image to be pulled every time Kubernetes starts the container, specify `imagePullPolicy: Always`.
|
||||
The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image.
|
||||
|
||||
An alternative, but deprecated way to have Kubernetes always pull the image is to use the `:latest` tag, which will implicitly set the `imagePullPolicy` to `Always`.
|
||||
- `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
|
||||
|
||||
- `imagePullPolicy: Always`: the image is pulled every time the pod is started.
|
||||
|
||||
- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied.
|
||||
|
||||
- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `IfNotPresent` is applied.
|
||||
|
||||
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You should avoid using the `:latest` tag when deploying containers in production, because this makes it hard to track which version of the image is running and hard to roll back.
|
||||
**Note:** To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
|
||||
{{< /note >}}
|
||||
|
||||
- To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) (for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). This uniquely identifies a specific version of the image, so it will never be updated by Kubernetes unless you change the digest value.
|
||||
{{< note >}}
|
||||
**Note:** You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
|
||||
{{< /note >}}
|
||||
|
||||
## Using kubectl
|
||||
|
||||
|
||||
@@ -25,13 +25,11 @@ The default pull policy is `IfNotPresent` which causes the Kubelet to skip
|
||||
pulling an image if it already exists. If you would like to always force a pull,
|
||||
you can do one of the following:
|
||||
|
||||
- set the `imagePullPolicy` of the container to `Always`;
|
||||
- use `:latest` as the tag for the image to use;
|
||||
- set the `imagePullPolicy` of the container to `Always`.
|
||||
- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
|
||||
- omit the `imagePullPolicy` and the tag for the image to use.
|
||||
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
|
||||
|
||||
If you did not specify tag of your image, it will be assumed as `:latest`, with
|
||||
pull image policy of `Always` correspondingly.
|
||||
|
||||
Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
|
||||
|
||||
## Using a Private Registry
|
||||
|
||||
@@ -95,6 +95,8 @@ In order for the Ingress resource to work, the cluster must have an Ingress cont
|
||||
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
|
||||
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket...), and it also comes with commercial support by [Containous](https://containo.us/services)
|
||||
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
|
||||
* [HAProxy](http://www.haproxy.org/) based ingress controller [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) which is mentioned on this blog post [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)
|
||||
* [Istio](https://istio.io/) based ingress controller [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Review the documentation for your controller to find its specific support policy.
|
||||
|
||||
@@ -92,13 +92,70 @@ __egress__: Each `NetworkPolicy` may include a list of whitelist `egress` rules.
|
||||
So, the example NetworkPolicy:
|
||||
|
||||
1. isolates "role=db" pods in the "default" namespace for both ingress and egress traffic (if they weren't already isolated)
|
||||
2. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from any pod in the "default" namespace with the label "role=frontend"
|
||||
3. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from any pod in a namespace with the label "project=myproject"
|
||||
4. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from IP addresses that are in CIDR 172.17.0.0/16 and not in 172.17.1.0/24
|
||||
5. allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978
|
||||
2. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from:
|
||||
* any pod in the "default" namespace with the label "role=frontend"
|
||||
* any pod in a namespace with the label "project=myproject"
|
||||
* IP addresses in the ranges 172.17.0.0–172.17.0.255 and 172.17.2.0–172.17.255.255 (ie, all of 172.17.0.0/16 except 172.17.1.0/24)
|
||||
3. allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978
|
||||
|
||||
See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples.
|
||||
|
||||
## Behavior of `to` and `from` selectors
|
||||
|
||||
There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section:
|
||||
|
||||
__podSelector__: This selects particular Pods in the same namespace as the `NetworkPolicy` which should be allowed as ingress sources or egress destinations.
|
||||
|
||||
__namespaceSelector__: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations.
|
||||
|
||||
__namespaceSelector__ *and* __podSelector__: A single `to`/`from` entry that specifies both `namespaceSelector` and `podSelector` selects particular Pods within particular namespaces. Be careful to use correct YAML syntax; this policy:
|
||||
|
||||
```yaml
|
||||
...
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
user: alice
|
||||
podSelector:
|
||||
matchLabels:
|
||||
role: client
|
||||
...
|
||||
```
|
||||
|
||||
contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy:
|
||||
|
||||
```yaml
|
||||
...
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
user: alice
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
role: client
|
||||
...
|
||||
```
|
||||
|
||||
contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`.
|
||||
|
||||
When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy.
|
||||
|
||||
__ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.
|
||||
|
||||
Cluster ingress and egress mechanisms often require rewriting the source or destination IP
|
||||
of packets. In cases where this happens, it is not defined whether this happens before or
|
||||
after NetworkPolicy processing, and the behavior may be different for different
|
||||
combinations of network plugin, cloud provider, `Service` implementation, etc.
|
||||
|
||||
In the case of ingress, this means that in some cases you may be able to filter incoming
|
||||
packets based on the actual original source IP, while in other cases, the "source IP" that
|
||||
the NetworkPolicy acts on may be the IP of a `LoadBalancer` or of the Pod's node, etc.
|
||||
|
||||
For egress, this means that connections from pods to `Service` IPs that get rewritten to
|
||||
cluster-external IPs may or may not be subject to `ipBlock`-based policies.
|
||||
|
||||
## Default policies
|
||||
|
||||
By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. The following examples let you change the default behavior
|
||||
|
||||
@@ -383,18 +383,19 @@ A Kubernetes administrator can specify additional mount options for when a Persi
|
||||
|
||||
The following volume types support mount options:
|
||||
|
||||
* GCEPersistentDisk
|
||||
* AWSElasticBlockStore
|
||||
* AzureFile
|
||||
* AzureDisk
|
||||
* NFS
|
||||
* iSCSI
|
||||
* RBD (Ceph Block Device)
|
||||
* AzureFile
|
||||
* CephFS
|
||||
* Cinder (OpenStack block storage)
|
||||
* GCEPersistentDisk
|
||||
* Glusterfs
|
||||
* VsphereVolume
|
||||
* NFS
|
||||
* Quobyte Volumes
|
||||
* RBD (Ceph Block Device)
|
||||
* StorageOS
|
||||
* VsphereVolume
|
||||
* iSCSI
|
||||
|
||||
Mount options are not validated, so mount will simply fail if one is invalid.
|
||||
|
||||
@@ -514,7 +515,7 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: myfrontend
|
||||
image: dockerfile/nginx
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: "/var/www/html"
|
||||
name: mypd
|
||||
|
||||
@@ -972,7 +972,7 @@ spec:
|
||||
For more information including Dynamic Provisioning and Persistent Volume Claims, please see the
|
||||
[StorageOS examples](https://github.com/kubernetes/examples/blob/master/staging/volumes/storageos).
|
||||
|
||||
### vsphereVolume {#vsphereVolume}
|
||||
### vsphereVolume {#vspherevolume}
|
||||
|
||||
{{< note >}}
|
||||
**Prerequisite:** Kubernetes with vSphere Cloud Provider configured. For cloudprovider
|
||||
|
||||
@@ -21,7 +21,7 @@ Some typical uses of a DaemonSet are:
|
||||
- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
|
||||
- running a logs collection daemon on every node, such as `fluentd` or `logstash`.
|
||||
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
|
||||
https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, or Ganglia `gmond`.
|
||||
https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, Ganglia `gmond` or Instana agent.
|
||||
|
||||
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
|
||||
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
|
||||
|
||||
@@ -116,136 +116,83 @@ need to work with someone who can set the label and milestone for you.
|
||||
|
||||
## Overview of update-imported-docs
|
||||
|
||||
The `update-imported-docs` tool performs these steps:
|
||||
The website repository contains a `update-imported-docs` tool under the
|
||||
`kubernetes/website/update-imported-docs/` directory that performs the
|
||||
following steps:
|
||||
|
||||
1. Clone the `kubernetes/kubernetes` repository.
|
||||
1. Run several scripts under `kubernetes/kubernetes/hack`. These scripts
|
||||
generate Markdown files and place the files under `kubernetes/kubernetes/docs`.
|
||||
1. Copy the generated Markdown files to a local clone of the `kubernetes/website`
|
||||
repository under `kubernetes/website/docs/reference/generated`.
|
||||
1. Clone the `kubernetes/federation` repository.
|
||||
1. Run several scripts under `kubernetes/federation/hack`. These scripts
|
||||
generate Markdown files and place the files under `kubernetes/federation/docs`.
|
||||
1. Copy the generated Markdown files to a local clone of the `kubernetes/website`
|
||||
repository under `kubernetes/website/docs/reference/generated`.
|
||||
1. Clones the related repositories specified in a configuration file. For the
|
||||
purpose of generating reference docs, the repositories that are cloned by
|
||||
default are `kubernetes-incubator/reference-docs` and `kubernetes/federation`.
|
||||
1. Runs commands under the cloned repositories to prepare the docs generator and
|
||||
then generates the Markdown files.
|
||||
1. Copies the generated Markdown files to a local clone of the `kubernetes/website`
|
||||
repository under locations specified in the configuration file.
|
||||
|
||||
After the Markdown files are in your local clone of the `kubernetes/website`
|
||||
When the Markdown files are in your local clone of the `kubernetes/website`
|
||||
repository, you can submit them in a
|
||||
[pull request](https://kubernetes.io/docs/home/contribute/create-pull-request/)
|
||||
to `kubernetes/website`.
|
||||
|
||||
## Setting the branch
|
||||
## Customizing the config file
|
||||
|
||||
Open `<web-base>/update-imported-docs/config.yaml` for editing.
|
||||
|
||||
Set the value of `branch` to the Kubernetes release that you want to document.
|
||||
For example, if you want to generate docs for the Kubernetes 1.9 release,
|
||||
set `branch` to `release-1.9`.
|
||||
Open `<web-base>/update-imported-docs/reference.yaml` for editing.
|
||||
Do not change the content for the `generate-command` entry unless you undertand
|
||||
what it is doing and need to change the specified release branch.
|
||||
|
||||
```shell
|
||||
repos:
|
||||
- name: kubernetes
|
||||
remote: https://github.com/kubernetes/kubernetes.git
|
||||
branch: release-1.9
|
||||
- name: reference-docs
|
||||
remote: https://github.com/kubernetes-incubator/reference-docs.git
|
||||
# This and the generate-command below needs a change when reference-docs has
|
||||
# branches properly defined
|
||||
branch: master
|
||||
generate-command: |
|
||||
cd $GOPATH
|
||||
git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes
|
||||
cd src/k8s.io/kubernetes
|
||||
git checkout release-1.11
|
||||
make generated_files
|
||||
cp -L -R vendor $GOPATH/src
|
||||
rm -r vendor
|
||||
cd $GOPATH
|
||||
go get -v github.com/kubernetes-incubator/reference-docs/gen-compdocs
|
||||
cd src/github.com/kubernetes-incubator/reference-docs/
|
||||
make comp
|
||||
```
|
||||
|
||||
## Setting sources and destinations
|
||||
The `update-imported-docs` tool uses `src` and `dst` fields in a configuration
|
||||
to decide the source and target location for doc files to be copied.
|
||||
For example:
|
||||
|
||||
The `update-imported-docs` tool uses `src` and `dst` fields
|
||||
in `config.yaml` to know which files to copy from the `kubernetes/kubernetes`
|
||||
repository and where to place those files in the `kubernetes/website`
|
||||
repository.
|
||||
|
||||
For example, suppose you want the tool to copy the `kube-apiserver.md` file
|
||||
from the `docs/admin` directory of the `kubernetes/kubernetes` repository
|
||||
to the `docs/reference/generated/` directory of the `kubernetes/website`
|
||||
repository. Then you would include a `src` and `dst` in your `config.yaml`
|
||||
file like this:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
repos:
|
||||
- name: kubernetes
|
||||
remote: https://github.com/kubernetes/kubernetes.git
|
||||
branch: release-1.9
|
||||
- name: reference-docs
|
||||
remote: https://github.com/kubernetes-incubator/reference-docs.git
|
||||
files:
|
||||
- src: docs/admin/kube-apiserver.md
|
||||
dst: docs/reference/generated/kube-apiserver.md
|
||||
- src: gen-compdocs/build/kube-apiserver.md
|
||||
dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
|
||||
...
|
||||
```
|
||||
|
||||
The configuration is similar for files in the `kubernetes/federation`
|
||||
repository. Here's an example that configures the tool to copy `kubefed_init.md`
|
||||
from the `docs/admin` directory of the `kubernetes/federation` repository
|
||||
to the `docs/reference/generated` directory of the `kubernetes/website` repository:
|
||||
Note that when there are many files to be copied from the same source directory
|
||||
to the same destination directory, you can use wildcards in the value given to
|
||||
`src` and you can just provide the directory name as the value for `dst`.
|
||||
For example:
|
||||
|
||||
```shell
|
||||
- name: federation
|
||||
remote: https://github.com/kubernetes/federation.git
|
||||
# # Change this to a release branch when federation has release branches.
|
||||
branch: master
|
||||
files:
|
||||
- src: docs/admin/kubefed_init.md
|
||||
dst: docs/reference/generated/kubefed_init.md
|
||||
...
|
||||
- src: gen-compdocs/build/kubeadm*.md
|
||||
dst: content/en/docs/reference/setup-tools/kubeadm/generated/
|
||||
```
|
||||
|
||||
Here's an example a `config.yaml` file that shows the sources and
|
||||
destinations of all the Markdown files that were generated and copied
|
||||
by the `update-imported-docs` tool at the beginning of the Kubernetes
|
||||
1.9 release.
|
||||
|
||||
```shell
|
||||
repos:
|
||||
- name: kubernetes
|
||||
remote: https://github.com/kubernetes/kubernetes.git
|
||||
branch: release-1.9
|
||||
files:
|
||||
- src: docs/admin/cloud-controller-manager.md
|
||||
dst: docs/reference/generated/cloud-controller-manager.md
|
||||
- src: docs/admin/kube-apiserver.md
|
||||
dst: docs/reference/generated/kube-apiserver.md
|
||||
- src: docs/admin/kube-controller-manager.md
|
||||
dst: docs/reference/generated/kube-controller-manager.md
|
||||
- src: docs/admin/kubelet.md
|
||||
dst: docs/reference/generated/kubelet.md
|
||||
- src: docs/admin/kube-proxy.md
|
||||
dst: docs/reference/generated/kube-proxy.md
|
||||
- src: docs/admin/kube-scheduler.md
|
||||
dst: docs/reference/generated/kube-scheduler.md
|
||||
- src: docs/user-guide/kubectl/kubectl.md
|
||||
dst: docs/reference/generated/kubectl/kubectl.md
|
||||
- name: federation
|
||||
remote: https://github.com/kubernetes/federation.git
|
||||
# # Change this to a release branch when federation has release branches.
|
||||
branch: master
|
||||
files:
|
||||
- src: docs/admin/federation-apiserver.md
|
||||
dst: docs/reference/generated/federation-apiserver.md
|
||||
- src: docs/admin/federation-controller-manager.md
|
||||
dst: docs/reference/generated/federation-controller-manager.md
|
||||
- src: docs/admin/kubefed_init.md
|
||||
dst: docs/reference/generated/kubefed_init.md
|
||||
- src: docs/admin/kubefed_join.md
|
||||
dst: docs/reference/generated/kubefed_join.md
|
||||
- src: docs/admin/kubefed.md
|
||||
dst: docs/reference/generated/kubefed.md
|
||||
- src: docs/admin/kubefed_options.md
|
||||
dst: docs/reference/generated/kubefed_options.md
|
||||
- src: docs/admin/kubefed_unjoin.md
|
||||
dst: docs/reference/generated/kubefed_unjoin.md
|
||||
- src: docs/admin/kubefed_version.md
|
||||
dst: docs/reference/generated/kubefed_version.md
|
||||
```
|
||||
|
||||
## Running the update-imported-docs tool
|
||||
|
||||
Now that your `config.yaml` file contains your sources and destinations,
|
||||
you can run the `update-imported-docs` tool:
|
||||
After having reviewed and/or customized the `reference.yaml` file, you can run
|
||||
the `update-imported-docs` tool:
|
||||
|
||||
```shell
|
||||
cd <web-base>
|
||||
go get ./update-imported-docs
|
||||
go run update-imported-docs/update-imported-docs.go
|
||||
cd <web-base>/update-imported-docs
|
||||
./update-imported-docs reference.yml
|
||||
```
|
||||
|
||||
## Adding and committing changes in kubernetes/website
|
||||
@@ -263,21 +210,15 @@ might look like this:
|
||||
|
||||
```shell
|
||||
...
|
||||
modified: docs/reference/generated/cloud-controller-manager.md
|
||||
modified: docs/reference/generated/federation-apiserver.md
|
||||
modified: docs/reference/generated/federation-controller-manager.md
|
||||
modified: docs/reference/generated/kube-apiserver.md
|
||||
modified: docs/reference/generated/kube-controller-manager.md
|
||||
modified: docs/reference/generated/kube-proxy.md
|
||||
modified: docs/reference/generated/kube-scheduler.md
|
||||
modified: docs/reference/generated/kubectl/kubectl.md
|
||||
modified: docs/reference/generated/kubefed.md
|
||||
modified: docs/reference/generated/kubefed_init.md
|
||||
modified: docs/reference/generated/kubefed_join.md
|
||||
modified: docs/reference/generated/kubefed_options.md
|
||||
modified: docs/reference/generated/kubefed_unjoin.md
|
||||
modified: docs/reference/generated/kubefed_version.md
|
||||
modified: docs/reference/generated/kubelet.md
|
||||
|
||||
modified: content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
|
||||
modified: content/en/docs/reference/command-line-tools-reference/federation-apiserver.md
|
||||
modified: content/en/docs/reference/command-line-tools-reference/federation-controller-manager.md
|
||||
modified: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
|
||||
modified: content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
|
||||
modified: content/en/docs/reference/command-line-tools-reference/kube-proxy.md
|
||||
modified: content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
|
||||
...
|
||||
```
|
||||
|
||||
Run `git add` and `git commit` to commit the files.
|
||||
@@ -303,4 +244,3 @@ topics will be visible in the
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -730,6 +730,7 @@ the techniques described in
|
||||
[Commit into another person's PR](#commit-into-another-persons-pr).
|
||||
|
||||
If you need to write a new topic, the following links are useful:
|
||||
|
||||
- [Writing a New Topic](/docs/contribute/style/write-new-topic/)
|
||||
- [Using Page Templates](/docs/contribute/style/page-templates/)
|
||||
- [Documentation Style Guide](/docs/contribute/style/style-guide/)
|
||||
@@ -764,6 +765,11 @@ deadlines. Some deadlines related to documentation are:
|
||||
documentation and the docs are not ready, the feature may be removed from the
|
||||
milestone.
|
||||
|
||||
If your feature is an Alpha feature and is behind a feature gate, make sure you
|
||||
add it to [Feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
as part of your pull request. If your feature is moving out of Alpha, make sure to
|
||||
remove it from that file.
|
||||
|
||||
## Contribute to other repos
|
||||
|
||||
The [Kubernetes project](https://github.com/kubernetes) contains more than 50
|
||||
|
||||
@@ -28,7 +28,7 @@ The Kubernetes documentation is written in Markdown and processed and deployed
|
||||
using Hugo. The source is in Github at
|
||||
[https://github.com/kubernetes/website](https://github.com/kubernetes/website).
|
||||
Most of the documentation source is stored in `/content/en/docs/`. Some of the
|
||||
reference documentation is automatically generated from scripts, mostly in the
|
||||
reference documentation is automatically generated from scripts in the
|
||||
`update-imported-docs/` directory.
|
||||
|
||||
You can file issues, edit content, and review changes from others, all from the
|
||||
|
||||
@@ -81,6 +81,20 @@ The Kubernetes API server flag `disable-admission-plugins` takes a comma-delimit
|
||||
kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...
|
||||
```
|
||||
|
||||
## Which plugins are enabled by default?
|
||||
|
||||
To see which admission plugins are enabled:
|
||||
|
||||
```shell
|
||||
kube-apiserver -h | grep enable-admission-plugins
|
||||
```
|
||||
|
||||
In 1.11, they are:
|
||||
|
||||
```shell
|
||||
NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,Priority
|
||||
```
|
||||
|
||||
## What does each admission controller do?
|
||||
|
||||
### AlwaysAdmit (DEPRECATED) {#alwaysadmit}
|
||||
|
||||
@@ -342,7 +342,7 @@ Setup instructions for specific systems:
|
||||
|
||||
The first option is to use the kubectl `oidc` authenticator, which sets the `id_token` as a bearer token for all requests and refreshes the token once it expires. After you've logged into your provider, use kubectl to add your `id_token`, `refresh_token`, `client_id`, and `client_secret` to configure the plugin.
|
||||
|
||||
Providers that don't return an `id_token` as part of their refresh token response (e.g. [Okta](https://developer.okta.com/docs/api/resources/oidc.html#response-parameters-4)) aren't supported by this plugin and should use "Option 2" below.
|
||||
Providers that don't return an `id_token` as part of their refresh token response aren't supported by this plugin and should use "Option 2" below.
|
||||
|
||||
```bash
|
||||
kubectl config set-credentials USER_NAME \
|
||||
|
||||
@@ -452,7 +452,7 @@ Auto-reconciliation is enabled in Kubernetes version 1.6+ when the RBAC authoriz
|
||||
|
||||
### Discovery Roles
|
||||
|
||||
Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible. To disable anonymous unauthenticated access add `--anonymous-auth=false` to the API server configuration.
|
||||
Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access add `--anonymous-auth=false` to the API server configuration.
|
||||
|
||||
To view the configuration of these roles via `kubectl` run:
|
||||
|
||||
|
||||
@@ -114,6 +114,9 @@ For more details on each field in the configuration you can navigate to our
|
||||
For information about kube-proxy parameters in the kubeadm configuration see:
|
||||
- [kube-proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration)
|
||||
|
||||
For information about enabling IPVS mode with kubeadm see:
|
||||
- [IPVS](https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/README.md)
|
||||
|
||||
### Passing custom flags to control plane components {#control-plane-flags}
|
||||
|
||||
For information about passing flags to control plane components see:
|
||||
|
||||
@@ -5,13 +5,19 @@ content_template: templates/concept
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
|
||||
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
|
||||
|
||||
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
|
||||
|
||||
* a highly available cluster
|
||||
* composable attributes
|
||||
* support for most popular Linux distributions (CoreOS, Debian Jessie, Ubuntu 16.04, CentOS/RHEL 7, Fedora/CentOS Atomic)
|
||||
* support for most popular Linux distributions
|
||||
* Container Linux by CoreOS
|
||||
* Debian Jessie, Stretch, Wheezy
|
||||
* Ubuntu 16.04, 18.04
|
||||
* CentOS/RHEL 7
|
||||
* Fedora/CentOS Atomic
|
||||
* openSUSE Leap 42.3/Tumbleweed
|
||||
* continuous integration tests
|
||||
|
||||
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
|
||||
@@ -48,12 +54,16 @@ After you provision your servers, create an [inventory file for Ansible](http://
|
||||
|
||||
Kubespray provides the ability to customize many aspects of the deployment:
|
||||
|
||||
* Choice deployment mode: kubeadm or non-kubeadm
|
||||
* CNI (networking) plugins
|
||||
* DNS configuration
|
||||
* Choice of control plane: native/binary or containerized with docker or rkt)
|
||||
* Choice of control plane: native/binary or containerized with docker or rkt
|
||||
* Component versions
|
||||
* Calico route reflectors
|
||||
* Component runtime options
|
||||
* docker
|
||||
* rkt
|
||||
* cri-o
|
||||
* Certificate generation methods
|
||||
|
||||
Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
|
||||
|
||||
@@ -261,7 +261,7 @@ Please select one of the tabs to see installation instructions for the respectiv
|
||||
{{% tab name="Calico" %}}
|
||||
For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
|
||||
|
||||
In order for Network Policy to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init`. Note that Calico works on `amd64` only.
|
||||
For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64` only.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
|
||||
@@ -279,6 +279,35 @@ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Cilium" %}}
|
||||
For more information about using Cilium with Kubernetes, see [Quickstart for Cilium on Kubernetes](http://docs.cilium.io/en/v1.2/kubernetes/quickinstall/) and [Kubernetes Install guide for Cilium](http://docs.cilium.io/en/v1.2/kubernetes/install/).
|
||||
|
||||
Passing `--pod-network-cidr` option to `kubeadm init` is not required, but highly recommended.
|
||||
|
||||
These commands will deploy Cilium with its own etcd managed by etcd operator.
|
||||
|
||||
```shell
|
||||
# Download required manifests from Cilium repository
|
||||
wget https://github.com/cilium/cilium/archive/v1.2.0.zip
|
||||
unzip v1.2.0.zip
|
||||
cd cilium-1.2.0/examples/kubernetes/addons/etcd-operator
|
||||
|
||||
# Generate and deploy etcd certificates
|
||||
export CLUSTER_DOMAIN=$(kubectl get ConfigMap --namespace kube-system coredns -o yaml | awk '/kubernetes/ {print $2}')
|
||||
tls/certs/gen-cert.sh $CLUSTER_DOMAIN
|
||||
tls/deploy-certs.sh
|
||||
|
||||
# Label kube-dns with fixed identity label
|
||||
kubectl label -n kube-system pod $(kubectl -n kube-system get pods -l k8s-app=kube-dns -o jsonpath='{range .items[]}{.metadata.name}{" "}{end}') io.cilium.fixed-identity=kube-dns
|
||||
|
||||
kubectl create -f ./
|
||||
|
||||
# Wait several minutes for Cilium, coredns and etcd pods to converge to a working state
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Flannel" %}}
|
||||
|
||||
|
||||
@@ -74,30 +74,30 @@ run as root.
|
||||
1. Enable ssh-agent on your main device that has access to all other nodes in
|
||||
the system:
|
||||
|
||||
```
|
||||
eval $(ssh-agent)
|
||||
```
|
||||
```
|
||||
eval $(ssh-agent)
|
||||
```
|
||||
|
||||
1. Add your SSH identity to the session:
|
||||
|
||||
```
|
||||
ssh-add ~/.ssh/path_to_private_key
|
||||
```
|
||||
```
|
||||
ssh-add ~/.ssh/path_to_private_key
|
||||
```
|
||||
|
||||
1. SSH between nodes to check that the connection is working correctly.
|
||||
|
||||
- When you SSH to any node, make sure to add the `-A` flag:
|
||||
|
||||
```
|
||||
ssh -A 10.0.0.7
|
||||
```
|
||||
```
|
||||
ssh -A 10.0.0.7
|
||||
```
|
||||
|
||||
- When using sudo on any node, make sure to preserve the environment so SSH
|
||||
forwarding works:
|
||||
|
||||
```
|
||||
sudo -E -s
|
||||
```
|
||||
```
|
||||
sudo -E -s
|
||||
```
|
||||
|
||||
### Create load balancer for kube-apiserver
|
||||
|
||||
@@ -260,54 +260,54 @@ done
|
||||
|
||||
1. Move the copied files to the correct locations:
|
||||
|
||||
```sh
|
||||
USER=ubuntu # customizable
|
||||
mkdir -p /etc/kubernetes/pki/etcd
|
||||
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
|
||||
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
|
||||
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
|
||||
```
|
||||
```sh
|
||||
USER=ubuntu # customizable
|
||||
mkdir -p /etc/kubernetes/pki/etcd
|
||||
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
|
||||
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
|
||||
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
1. Run the kubeadm phase commands to bootstrap the kubelet:
|
||||
|
||||
```sh
|
||||
kubeadm alpha phase certs all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet config write-to-disk --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet write-env-file --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubeconfig kubelet --config kubeadm-config.yaml
|
||||
systemctl start kubelet
|
||||
```
|
||||
```sh
|
||||
kubeadm alpha phase certs all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet config write-to-disk --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet write-env-file --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubeconfig kubelet --config kubeadm-config.yaml
|
||||
systemctl start kubelet
|
||||
```
|
||||
|
||||
1. Run the commands to add the node to the etcd cluster:
|
||||
|
||||
```sh
|
||||
export CP0_IP=10.0.0.7
|
||||
export CP0_HOSTNAME=cp0
|
||||
export CP1_IP=10.0.0.8
|
||||
export CP1_HOSTNAME=cp1
|
||||
```sh
|
||||
export CP0_IP=10.0.0.7
|
||||
export CP0_HOSTNAME=cp0
|
||||
export CP1_IP=10.0.0.8
|
||||
export CP1_HOSTNAME=cp1
|
||||
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
kubectl exec -n kube-system etcd-${CP0_HOSTNAME} -- etcdctl --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/peer.crt --key-file /etc/kubernetes/pki/etcd/peer.key --endpoints=https://${CP0_IP}:2379 member add ${CP1_HOSTNAME} https://${CP1_IP}:2380
|
||||
kubeadm alpha phase etcd local --config kubeadm-config.yaml
|
||||
```
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
kubectl exec -n kube-system etcd-${CP0_HOSTNAME} -- etcdctl --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/peer.crt --key-file /etc/kubernetes/pki/etcd/peer.key --endpoints=https://${CP0_IP}:2379 member add ${CP1_HOSTNAME} https://${CP1_IP}:2380
|
||||
kubeadm alpha phase etcd local --config kubeadm-config.yaml
|
||||
```
|
||||
|
||||
- This command causes the etcd cluster to become unavailable for a
|
||||
- This command causes the etcd cluster to become unavailable for a
|
||||
brief period, after the node is added to the running cluster, and before the
|
||||
new node is joined to the etcd cluster.
|
||||
|
||||
1. Deploy the control plane components and mark the node as a master:
|
||||
|
||||
```sh
|
||||
kubeadm alpha phase kubeconfig all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase controlplane all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase mark-master --config kubeadm-config.yaml
|
||||
```
|
||||
```sh
|
||||
kubeadm alpha phase kubeconfig all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase controlplane all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase mark-master --config kubeadm-config.yaml
|
||||
```
|
||||
|
||||
### Add the third stacked control plane node
|
||||
|
||||
@@ -351,50 +351,50 @@ done
|
||||
|
||||
1. Move the copied files to the correct locations:
|
||||
|
||||
```sh
|
||||
USER=ubuntu # customizable
|
||||
mkdir -p /etc/kubernetes/pki/etcd
|
||||
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
|
||||
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
|
||||
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
|
||||
```
|
||||
```sh
|
||||
USER=ubuntu # customizable
|
||||
mkdir -p /etc/kubernetes/pki/etcd
|
||||
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
|
||||
mv /home/${USER}/sa.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
|
||||
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
|
||||
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
|
||||
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
1. Run the kubeadm phase commands to bootstrap the kubelet:
|
||||
|
||||
```sh
|
||||
kubeadm alpha phase certs all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet config write-to-disk --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet write-env-file --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubeconfig kubelet --config kubeadm-config.yaml
|
||||
systemctl start kubelet
|
||||
```
|
||||
```sh
|
||||
kubeadm alpha phase certs all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet config write-to-disk --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubelet write-env-file --config kubeadm-config.yaml
|
||||
kubeadm alpha phase kubeconfig kubelet --config kubeadm-config.yaml
|
||||
systemctl start kubelet
|
||||
```
|
||||
|
||||
1. Run the commands to add the node to the etcd cluster:
|
||||
|
||||
```sh
|
||||
export CP0_IP=10.0.0.7
|
||||
export CP0_HOSTNAME=cp0
|
||||
export CP2_IP=10.0.0.9
|
||||
export CP2_HOSTNAME=cp2
|
||||
```sh
|
||||
export CP0_IP=10.0.0.7
|
||||
export CP0_HOSTNAME=cp0
|
||||
export CP2_IP=10.0.0.9
|
||||
export CP2_HOSTNAME=cp2
|
||||
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
kubectl exec -n kube-system etcd-${CP0_HOSTNAME} -- etcdctl --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/peer.crt --key-file /etc/kubernetes/pki/etcd/peer.key --endpoints=https://${CP0_IP}:2379 member add ${CP2_HOSTNAME} https://${CP2_IP}:2380
|
||||
kubeadm alpha phase etcd local --config kubeadm-config.yaml
|
||||
```
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
kubectl exec -n kube-system etcd-${CP0_HOSTNAME} -- etcdctl --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/peer.crt --key-file /etc/kubernetes/pki/etcd/peer.key --endpoints=https://${CP0_IP}:2379 member add ${CP2_HOSTNAME} https://${CP2_IP}:2380
|
||||
kubeadm alpha phase etcd local --config kubeadm-config.yaml
|
||||
```
|
||||
|
||||
1. Deploy the control plane components and mark the node as a master:
|
||||
|
||||
```sh
|
||||
kubeadm alpha phase kubeconfig all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase controlplane all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase mark-master --config kubeadm-config.yaml
|
||||
```
|
||||
```sh
|
||||
kubeadm alpha phase kubeconfig all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase controlplane all --config kubeadm-config.yaml
|
||||
kubeadm alpha phase mark-master --config kubeadm-config.yaml
|
||||
```
|
||||
|
||||
## External etcd
|
||||
|
||||
|
||||
@@ -86,6 +86,7 @@ few commands. These solutions are actively developed and have active community s
|
||||
* [Tectonic by CoreOS](https://coreos.com/tectonic)
|
||||
* [CenturyLink Cloud](/docs/setup/turnkey/clc/)
|
||||
* [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer)
|
||||
* [IBM Cloud Private Running on Multiple Clouds](https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/W1559b1be149d_43b0_881e_9783f38faaff/page/IBM%20Cloud%20Private%20running%20on%20multiple%20clouds)
|
||||
* [Stackpoint.io](/docs/setup/turnkey/stackpoint/)
|
||||
* [Madcore.Ai](https://madcore.ai/)
|
||||
* [Kubermatic](https://cloud.kubermatic.io)
|
||||
@@ -183,6 +184,7 @@ Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madc
|
||||
Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial
|
||||
Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial
|
||||
Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial
|
||||
IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://console.bluemix.net/docs/containers/) | Commercial
|
||||
Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial
|
||||
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project
|
||||
Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial
|
||||
|
||||
@@ -5,7 +5,7 @@ content_template: templates/concept
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
[Documentation](https://docs.k8s.io) & [Examples](https://releases.k8s.io/release-1.11/examples)
|
||||
[Documentation](https://docs.k8s.io) & [Examples](https://github.com/kubernetes/examples)
|
||||
|
||||
## Downloads for v1.11.0
|
||||
|
||||
@@ -200,24 +200,26 @@ or `/etc/sysconfig/kubelet`, depending on the system you're running on.
|
||||
The following PRs changed the API spec:
|
||||
* In the new v1alpha2 kubeadm Configuration API, the `.CloudProvider` and `.PrivilegedPods` fields don't exist anymore. Instead, you should use the out-of-tree cloud provider implementations, which are beta in v1.11.
|
||||
* If you have to use the legacy in-tree cloud providers, you can rearrange your config like the example below. If you need the `cloud-config` file (located in `{cloud-config-path}`), you can mount it into the API Server and controller-manager containers using ExtraVolumes, as in:
|
||||
```yaml
|
||||
kind: MasterConfiguration
|
||||
apiVersion: kubeadm.k8s.io/v1alpha2
|
||||
apiServerExtraArgs:
|
||||
cloud-provider: "{cloud}"
|
||||
cloud-config: "{cloud-config-path}"
|
||||
apiServerExtraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "{cloud-config-path}"
|
||||
mountPath: "{cloud-config-path}"
|
||||
controllerManagerExtraArgs:
|
||||
cloud-provider: "{cloud}"
|
||||
cloud-config: "{cloud-config-path}"
|
||||
controllerManagerExtraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "{cloud-config-path}"
|
||||
mountPath: "{cloud-config-path}"
|
||||
```
|
||||
|
||||
|
||||
kind: MasterConfiguration
|
||||
apiVersion: kubeadm.k8s.io/v1alpha2
|
||||
apiServerExtraArgs:
|
||||
cloud-provider: "{cloud}"
|
||||
cloud-config: "{cloud-config-path}"
|
||||
apiServerExtraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "{cloud-config-path}"
|
||||
mountPath: "{cloud-config-path}"
|
||||
controllerManagerExtraArgs:
|
||||
cloud-provider: "{cloud}"
|
||||
cloud-config: "{cloud-config-path}"
|
||||
controllerManagerExtraVolumes:
|
||||
- name: cloud
|
||||
hostPath: "{cloud-config-path}"
|
||||
mountPath: "{cloud-config-path}"
|
||||
|
||||
|
||||
* If you need to use the `.PrivilegedPods` functionality, you can still edit the manifests in `/etc/kubernetes/manifests/`, and set `.SecurityContext.Privileged=true` for the apiserver and controller manager.
|
||||
([#63866](https://github.com/kubernetes/kubernetes/pull/63866), [@luxas](https://github.com/luxas))
|
||||
* kubeadm: The Token-related fields in the `MasterConfiguration` object have now been refactored. Instead of the top-level `.Token`, `.TokenTTL`, `.TokenUsages`, `.TokenGroups` fields, there is now a `BootstrapTokens` slice of `BootstrapToken` objects that support the same features under the `.Token`, `.TTL`, `.Usages`, `.Groups` fields. ([#64408](https://github.com/kubernetes/kubernetes/pull/64408), [@luxas](https://github.com/luxas))
|
||||
|
||||
@@ -465,7 +465,7 @@ traffic to the internet, but have no problem with them inside your GCE Project.
|
||||
|
||||
The previous steps all involved "conventional" system administration techniques for setting up
|
||||
machines. You may want to use a Configuration Management system to automate the node configuration
|
||||
process. There are examples of [Saltstack](/docs/setup/salt/), Ansible, Juju, and CoreOS Cloud Config in the
|
||||
process. There are examples of Ansible, Juju, and CoreOS Cloud Config in the
|
||||
various Getting Started Guides.
|
||||
|
||||
## Bootstrapping the Cluster
|
||||
@@ -865,7 +865,7 @@ pinging or SSH-ing from one node to another.
|
||||
### Getting Help
|
||||
|
||||
If you run into trouble, see the section on [troubleshooting](/docs/setup/turnkey/gce/#troubleshooting), post to the
|
||||
[kubernetes-users group](https://groups.google.com/forum/#!forum/kubernetes-users), or come ask questions on [Slack](/docs/troubleshooting#slack).
|
||||
[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting#slack).
|
||||
|
||||
## Support Level
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@ cluster/kube-up.sh
|
||||
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
|
||||
|
||||
If you run into trouble, please see the section on [troubleshooting](/docs/setup/turnkey/gce/#troubleshooting), post to the
|
||||
[kubernetes-users group](https://groups.google.com/forum/#!forum/kubernetes-users), or come ask questions on [Slack](/docs/troubleshooting/#slack).
|
||||
[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
|
||||
|
||||
The next few steps will show you:
|
||||
|
||||
|
||||
@@ -42,9 +42,9 @@ with the flag `--cluster-domain=<default-local-domain>`.
|
||||
The DNS server supports forward lookups (A records), port lookups (SRV records), reverse IP address lookups (PTR records),
|
||||
and more. For more information see [DNS for Services and Pods] (/docs/concepts/services-networking/dns-pod-service/).
|
||||
|
||||
When running a Pod, kubelet prepends the cluster DNS server and searches
|
||||
paths to the node's DNS settings. If the node is able to resolve DNS names
|
||||
specific to the larger environment, Pods should also be able to resolve.
|
||||
If a Pod's `dnsPolicy` is set to "`default`", it inherits the name resolution
|
||||
configuration from the node that the Pod runs on. The Pod's DNS resolution
|
||||
should behave the same as the node.
|
||||
But see [Known issues](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues).
|
||||
|
||||
If you don't want this, or if you want a different DNS config for pods, you can
|
||||
|
||||
+1
-1
@@ -33,7 +33,7 @@ Verify that the weave works.
|
||||
Enter the following command:
|
||||
|
||||
```shell
|
||||
kubectl get po -n kube-system -o wide
|
||||
kubectl get pods -n kube-system -o wide
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
@@ -65,7 +65,7 @@ Kubernetes cluster but inside the same GCP region.
|
||||
{{% capture prerequisites %}}
|
||||
This document assumes that you have a running Kubernetes Cluster
|
||||
Federation installation. If not, then see the
|
||||
[federation admin guide](/docs/admin/federation/) to learn how to
|
||||
[federation admin guide](/docs/tasks/federation/set-up-cluster-federation-kubefed/) to learn how to
|
||||
bring up a cluster federation (or have your cluster administrator do
|
||||
this for you). Other tutorials, for example
|
||||
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
|
||||
|
||||
@@ -193,7 +193,7 @@ myregistrykey kubernetes.io/.dockerconfigjson 1 1d
|
||||
Next, modify the default service account for the namespace to use this secret as an imagePullSecret.
|
||||
|
||||
```shell
|
||||
kubectl patch serviceaccount default -p '{\"imagePullSecrets\": [{\"name\": \"myregistrykey\"}]}'
|
||||
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
|
||||
```
|
||||
|
||||
Interactive version requiring manual edit:
|
||||
|
||||
@@ -181,7 +181,7 @@ crictl exec -i -t 1f73f2d81bf98 ls
|
||||
bin dev etc home proc root sys tmp usr var
|
||||
```
|
||||
|
||||
### Get a coontainer's logs
|
||||
### Get a container's logs
|
||||
|
||||
Get all container logs:
|
||||
|
||||
|
||||
@@ -623,7 +623,7 @@ us know, so we can help investigate!
|
||||
|
||||
Contact us on
|
||||
[Slack](/docs/troubleshooting/#slack) or
|
||||
[email](https://groups.google.com/forum/#!forum/kubernetes-users) or
|
||||
[Forum](https://discuss.kubernetes.io) or
|
||||
[GitHub](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -91,8 +91,10 @@ This video shows how to configure and run a Google Cloud Monitoring backed Heaps
|
||||
|
||||
### Dynatrace Kubernetes monitoring
|
||||
|
||||
With [Dynatrace Kubernetes monitoring](https://www.dynatrace.com/technologies/cloud-and-microservices/kubernetes-monitoring/), you can monitor application and cluster health in highly-dynamic Kubernetes environments.
|
||||
With [Dynatrace Kubernetes monitoring](https://www.dynatrace.com/technologies/kubernetes-monitoring/), you can monitor application and cluster health in highly-dynamic Kubernetes environments.
|
||||
|
||||
Dynatrace automatically discovers all containers running on Kubernetes and presents you with a real-time view of all the connections between your containerized processes, hosts, and cloud instances. Dynatrace includes root cause analysis and the ability to replay problems to see how they evolved over time.
|
||||
|
||||
{{< figure src="/images/docs/dynatrace.png" alt="Dynatrace Kubernetes monitoring dashboard example" title="Dynatrace Kubernetes monitoring dashboard example" caption="This dashboard shows a Node overview." >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -84,9 +84,9 @@ these channels for localized support and info:
|
||||
- Spain: `#es-users`
|
||||
- Turkey: `#tr-users`, `#tr-events`
|
||||
|
||||
### Mailing List
|
||||
### Forum
|
||||
|
||||
The Kubernetes / Google Kubernetes Engine mailing list is [kubernetes-users@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-users)
|
||||
The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io)
|
||||
|
||||
### Bugs and Feature requests
|
||||
|
||||
|
||||
@@ -134,7 +134,7 @@ For example, `KUBECTL_PLUGINS_GLOBAL_FLAG_NAMESPACE`, `KUBECTL_PLUGINS_GLOBAL_FL
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* Check the repository for [some more examples](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubectl/plugins/examples) of plugins.
|
||||
* Check the repository for [some more examples](https://github.com/kubernetes/kubernetes/tree/release-1.11/pkg/kubectl/plugins/examples) of plugins.
|
||||
* In case of any questions, feel free to reach out to the [CLI SIG team](https://github.com/kubernetes/community/tree/master/sig-cli).
|
||||
* Binary plugins is still an alpha feature, so this is the time to contribute ideas and improvements to the codebase. We're also excited to hear about what you're planning to implement with plugins, so [let us know](https://github.com/kubernetes/community/tree/master/sig-cli)!
|
||||
|
||||
|
||||
@@ -22,7 +22,6 @@ This page shows how to delete Pods which are part of a stateful set, and explain
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
## StatefulSet considerations
|
||||
|
||||
In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The StatefulSet controller is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
|
||||
@@ -79,8 +78,6 @@ Always perform force deletion of StatefulSet Pods carefully and with complete kn
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Learn more about [debugging a StatefulSet](/docs/tasks/manage-stateful-set/debugging-a-statefulset/).
|
||||
Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -13,29 +13,28 @@ weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
This page shows how to scale a StatefulSet.
|
||||
This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to increasing or decreasing the number of replicas.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* StatefulSets are only available in Kubernetes version 1.5 or later.
|
||||
* **Not all stateful applications scale nicely.** You need to understand your StatefulSets well before continuing. If you're unsure, remember that it might not be safe to scale your StatefulSets.
|
||||
* You should perform scaling only when you're sure that your stateful application
|
||||
To check your version of Kubernetes, run `kubectl version`.
|
||||
|
||||
* Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/) or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for futher information.
|
||||
|
||||
* You should perform scaling only when you are confident that your stateful application
|
||||
cluster is completely healthy.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Use `kubectl` to scale StatefulSets
|
||||
## Scaling StatefulSets
|
||||
|
||||
Make sure you have `kubectl` upgraded to Kubernetes version 1.5 or later before
|
||||
continuing. If you're unsure, run `kubectl version` and check `Client Version`
|
||||
for which kubectl you're using.
|
||||
### Use kubectl to scale StatefulSets
|
||||
|
||||
### `kubectl scale`
|
||||
|
||||
First, find the StatefulSet you want to scale. Remember, you need to first understand if you can scale it or not.
|
||||
First, find the StatefulSet you want to scale.
|
||||
|
||||
```shell
|
||||
kubectl get statefulsets <stateful-set-name>
|
||||
@@ -47,7 +46,7 @@ Change the number of replicas of your StatefulSet:
|
||||
kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>
|
||||
```
|
||||
|
||||
### Alternative: `kubectl apply` / `kubectl edit` / `kubectl patch`
|
||||
### Make in-place updates on your StatefulSets
|
||||
|
||||
Alternatively, you can do [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) on your StatefulSets.
|
||||
|
||||
@@ -72,32 +71,29 @@ kubectl patch statefulsets <stateful-set-name> -p '{"spec":{"replicas":<new-repl
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Scaling down doesn't work right
|
||||
### Scaling down does not work right
|
||||
|
||||
You cannot scale down a StatefulSet when any of the stateful Pods it manages is unhealthy. Scaling down only takes place
|
||||
after those stateful Pods become running and ready.
|
||||
|
||||
With a StatefulSet of size > 1, if there is an unhealthy Pod, there is no way
|
||||
for Kubernetes to know (yet) if it is due to a permanent fault or a transient
|
||||
one (upgrade/maintenance/node reboot). If the Pod is unhealthy due to a permanent fault, scaling
|
||||
If spec.replicas > 1, Kubernetes cannot determine the reason for an unhealthy Pod. It might be the result of a permanent fault or of a transient fault. A transient fault can be caused by a restart required by upgrading or maintenance.
|
||||
|
||||
If the Pod is unhealthy due to a permanent fault, scaling
|
||||
without correcting the fault may lead to a state where the StatefulSet membership
|
||||
drops below a certain minimum number of "replicas" that are needed to function
|
||||
drops below a certain minimum number of replicas that are needed to function
|
||||
correctly. This may cause your StatefulSet to become unavailable.
|
||||
|
||||
If the Pod is unhealthy due to a transient fault and the Pod might become available again,
|
||||
the transient error may interfere with your scale-up/scale-down operation. Some distributed
|
||||
the transient error may interfere with your scale-up or scale-down operation. Some distributed
|
||||
databases have issues when nodes join and leave at the same time. It is better
|
||||
to reason about scaling operations at the application level in these cases, and
|
||||
perform scaling only when you're sure that your stateful application cluster is
|
||||
perform scaling only when you are sure that your stateful application cluster is
|
||||
completely healthy.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Learn more about [deleting a StatefulSet](/docs/tasks/manage-stateful-set/deleting-a-statefulset/).
|
||||
* Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -99,8 +99,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
|
||||
|
||||
If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell.
|
||||
|
||||
To install:
|
||||
* Run the installation commands (making sure to specify a DownloadLocation):
|
||||
1. Run the installation commands (making sure to specify a `DownloadLocation`):
|
||||
|
||||
```
|
||||
Install-Script -Name install-kubectl -Scope CurrentUser -Force
|
||||
@@ -108,17 +107,21 @@ To install:
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you do not specify a DownloadLocation, kubectl will be installed in the user's temp Directory.
|
||||
**Note:** 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
|
||||
To update:
|
||||
* Run the update commands:
|
||||
|
||||
The installer creates `$HOME/.kube` and instructs it to create a config file
|
||||
|
||||
2. Test to ensure the version you installed is sufficiently up-to-date:
|
||||
|
||||
```
|
||||
re-run Install-Script to update the installer
|
||||
re-run install-kubectl.ps1 to install latest binaries
|
||||
kubectl version
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Updating the installation is performed by rerunning the two commands listed in step 1.
|
||||
{{< /note >}}
|
||||
|
||||
## Install with Chocolatey on Windows
|
||||
|
||||
If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install kubectl with Chocolatey.
|
||||
|
||||
@@ -24,7 +24,11 @@ weight: 20
|
||||
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Back to Kubernetes Basics<span class="btn__next">›</span></a>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user