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

Merge master into dev-1.19 to keep in sync

Browse Source
This commit is contained in:
Anna Jung
2020-08-11 08:32:19 -05:00
parent d9784dc5b4 6b784ad586
commit 09d0f598fa
358 changed files with 16526 additions and 6800 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/_index.md
+4 -2
View File
@@ -35,7 +35,7 @@ client libraries:
## CLI Reference
* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
* [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
## Components Reference
@@ -50,6 +50,8 @@ client libraries:
## Design Docs
An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
An archive of the design docs for Kubernetes functionality. Good starting points are
[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and
[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
content/en/docs/reference/access-authn-authz/_index.md
-1
View File
@@ -1,5 +1,4 @@
---
title: Accessing the API
weight: 20
toc-hide: true
---
content/en/docs/reference/access-authn-authz/abac.md
+2 -2
View File
@@ -18,7 +18,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby
To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
The file format is [one JSON object per line](http://jsonlines.org/). There
The file format is [one JSON object per line](https://jsonlines.org/). There
should be no enclosing list or map, just one map per line.
Each line is a "policy object", where each such object is a map with the following
@@ -127,7 +127,7 @@ up the verbosity:
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
```
[Complete file example](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
[Complete file example](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
## A quick note on service accounts
content/en/docs/reference/access-authn-authz/admission-controllers.md
+27 -8
View File
@@ -25,8 +25,8 @@ is authenticated and authorized. The controllers consist of the
`kube-apiserver` binary, and may only be configured by the cluster
administrator. In that list, there are two special controllers:
MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the
mutating and validating (respectively) [admission control
webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
mutating and validating (respectively)
[admission control webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
which are configured in the API.
Admission controllers may be "validating", "mutating", or both. Mutating
@@ -351,7 +351,10 @@ plugins:
{{% /tab %}}
{{< /tabs >}}
The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
The ImagePolicyWebhook config file must reference a
[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
formatted file which sets up the connection to the backend.
It is required that the backend communicate over TLS.
The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
@@ -371,7 +374,8 @@ users:
client-key: /path/to/key.pem # key matching the cert
```
For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
For additional HTTP configuration, refer to the
[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation.
#### Request Payloads
@@ -454,7 +458,8 @@ your Kubernetes deployment, you MUST use this admission controller to enforce th
be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
applies a 0.1 CPU requirement to all Pods in the `default` namespace.
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) for more details.
### MutatingAdmissionWebhook {#mutatingadmissionwebhook}
@@ -731,16 +736,30 @@ for more information.
### SecurityContextDeny {#securitycontextdeny}
This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
This admission controller will deny any pod that attempts to set certain escalating
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
fields, as shown in the
[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
task.
This should be enabled if a cluster doesn't utilize
[pod security policies](/docs/concepts/policy/pod-security-policy/)
to restrict the set of values a security context can take.
### ServiceAccount {#serviceaccount}
This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
This admission controller implements automation for
[serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/).
We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
### StorageObjectInUseProtection
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection`
finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV).
In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed
from the PVC or PV by PVC or PV Protection Controller.
Refer to the
[Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)
for more detailed information.
### TaintNodesByCondition {#taintnodesbycondition}
content/en/docs/reference/access-authn-authz/authentication.md
+24 -9
View File
@@ -20,13 +20,24 @@ This page provides an overview of authenticating.
All Kubernetes clusters have two categories of users: service accounts managed
by Kubernetes, and normal users.
Normal users are assumed to be managed by an outside, independent service. An
admin distributing private keys, a user store like Keystone or Google Accounts,
even a file with a list of usernames and passwords. In this regard, _Kubernetes
does not have objects which represent normal user accounts._ Normal users
cannot be added to a cluster through an API call.
It is assumed that a cluster-independent service manages normal users in the following ways:
Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
- an administrator distributing private keys
- a user store like Keystone or Google Accounts
- a file with a list of usernames and passwords
In this regard, _Kubernetes does not have objects which represent normal user
accounts._ Normal users cannot be added to a cluster through an API call.
Even though normal user cannot be added via an API call, but any user that
presents a valid certificate signed by the cluster’s certificate authority
(CA) is considered authenticated. In this configuration, Kubernetes determines
the username from the common name field in the ‘subject’ of the cert (e.g.,
“/CN=bob”). From there, the role based access control (RBAC) sub-system would
determine whether the user is authorized to perform a specific operation on a
resource. For more details, refer to the normal users topic in
[certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
for more details about this.
In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
@@ -315,8 +326,12 @@ wish to utilize multiple OAuth clients should explore providers which support th
tokens on behalf of another.
Kubernetes does not provide an OpenID Connect Identity Provider.
You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak), CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
You can use an existing public OpenID Connect Identity Provider (such as Google, or
[others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
[Keycloak](https://github.com/keycloak/keycloak),
CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
For an identity provider to work with Kubernetes it must:
@@ -400,7 +415,7 @@ Webhook authentication is a hook for verifying bearer tokens.
* `--authentication-token-webhook-config-file` a configuration file describing how to access the remote webhook service.
* `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.
The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
The configuration file uses the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
file format. Within the file, `clusters` refers to the remote service and
`users` refers to the API server webhook. An example would be:
content/en/docs/reference/access-authn-authz/authorization.md
+3 -2
View File
@@ -138,8 +138,6 @@ field of the returned object is the result of the query.
```bash
kubectl create -f - -o yaml << EOF
```
```
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
@@ -149,7 +147,10 @@ spec:
verb: create
namespace: dev
EOF
```
The generated `SelfSubjectAccessReview` is:
```
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+1 -1
View File
@@ -589,7 +589,7 @@ Example of a response to forbid a request, customizing the HTTP status code and
When allowing a request, a mutating admission webhook may optionally modify the incoming object as well.
This is done using the `patch` and `patchType` fields in the response.
The only currently supported `patchType` is `JSONPatch`.
See [JSON patch](http://jsonpatch.com/) documentation for more details.
See [JSON patch](https://jsonpatch.com/) documentation for more details.
For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of JSON patch operations.
As an example, a single patch operation that would set `spec.replicas` would be `[{"op": "add", "path": "/spec/replicas", "value": 3}]`
content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+2 -2
View File
@@ -10,8 +10,8 @@ weight: 50
---
<!-- overview -->
This is a Cluster Administrator guide to service accounts. It assumes knowledge of
the [User Guide to Service Accounts](/docs/user-guide/service-accounts).
This is a Cluster Administrator guide to service accounts. You should be familiar with
[configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/).
Support for authorization and user accounts is planned but incomplete. Sometimes
incomplete features are referred to in order to better describe service accounts.
content/en/docs/reference/command-line-tools-reference/_index.md
-1
View File
@@ -1,5 +1,4 @@
---
title: Command line tools reference
weight: 60
toc-hide: true
---
content/en/docs/reference/command-line-tools-reference/feature-gates.md
+6 -3
View File
@@ -417,11 +417,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas.
- `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
- `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
- `CustomResourceValidation`: Enable schema based validation on resources created from
[CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
[CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
- `CustomResourceWebhookConversion`: Enable webhook-based conversion
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
troubleshoot a running Pod.
- `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/monitoring.md).
- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
@@ -475,6 +475,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
[local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for
[emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor
[emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
- `MountContainers`: Enable using utility containers on host as the volume mounter.
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
content/en/docs/reference/glossary/cri-o.md
+1 -1
View File
@@ -17,7 +17,7 @@ A tool that lets you use OCI container runtimes with Kubernetes CRI.
CRI-O is an implementation of the {{< glossary_tooltip term_id="cri" >}}
to enable using {{< glossary_tooltip text="container" term_id="container" >}}
runtimes that are compatible with the Open Container Initiative (OCI)
[runtime spec](http://www.github.com/opencontainers/runtime-spec).
[runtime spec](https://www.github.com/opencontainers/runtime-spec).
Deploying CRI-O allows Kubernetes to use any OCI-compliant runtime as the container
runtime for running {{< glossary_tooltip text="Pods" term_id="pod" >}}, and to fetch
content/en/docs/reference/glossary/managed-service.md
+6 -1
View File
@@ -14,4 +14,9 @@ tags:
<!--more-->
Some examples of Managed Services are AWS EC2, Azure SQL Database, and GCP Pub/Sub, but they can be any software offering that can be used by an application. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
Some examples of Managed Services are AWS EC2, Azure SQL Database, and
GCP Pub/Sub, but they can be any software offering that can be used by an application.
[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
list, provision, and bind with Managed Services offered by
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
content/en/docs/reference/glossary/platform-developer.md
+6 -1
View File
@@ -14,5 +14,10 @@ tags:
<!--more-->
A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application. Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions.
A platform developer may, for example, use [Custom Resources](/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) or
[Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)
to add functionality to their instance of Kubernetes, specifically for their application.
Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and
develop extensions which are contributed to the Kubernetes community.
Others develop closed-source commercial or site-specific extensions.
content/en/docs/reference/glossary/service-broker.md
+6 -1
View File
@@ -14,4 +14,9 @@ tags:
<!--more-->
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the [Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) and provide a standard interface for applications to use their Managed Services. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by Service Brokers.
{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the
[Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)
and provide a standard interface for applications to use their Managed Services.
[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
list, provision, and bind with Managed Services offered by Service Brokers.
content/en/docs/reference/issues-security/_index.md
-1
View File
@@ -1,5 +1,4 @@
---
title: Kubernetes Issues and Security
weight: 10
toc-hide: true
---
content/en/docs/reference/kubectl/cheatsheet.md
+7
View File
@@ -204,6 +204,13 @@ kubectl get events --sort-by=.metadata.creationTimestamp
# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.
kubectl diff -f ./my-manifest.yaml
# Produce a period-delimited tree of all keys returned for nodes
# Helpful when locating a key within a complex nested JSON structure
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# Produce a period-delimited tree of all keys returned for pods, etc
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
```
## Updating Resources
content/en/docs/reference/kubectl/overview.md
+18 -12
View File
@@ -10,11 +10,16 @@ card:
---
<!-- overview -->
The kubectl command line tool lets you control Kubernetes clusters. For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
The kubectl command line tool lets you control Kubernetes clusters.
For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
files by setting the KUBECONFIG environment variable or by setting the
[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
This overview covers `kubectl` syntax, describes the command operations, and provides common examples.
For details about each command, including all the supported flags and subcommands, see the
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation.
For installation instructions see [installing kubectl](/docs/tasks/tools/install-kubectl/).
<!-- body -->
@@ -28,9 +33,12 @@ kubectl [command] [TYPE] [NAME] [flags]
where `command`, `TYPE`, `NAME`, and `flags` are:
* `command`: Specifies the operation that you want to perform on one or more resources, for example `create`, `get`, `describe`, `delete`.
* `command`: Specifies the operation that you want to perform on one or more resources,
for example `create`, `get`, `describe`, `delete`.
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output:
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and
you can specify the singular, plural, or abbreviated forms.
For example, the following commands produce the same output:
```shell
kubectl get pod pod1
@@ -208,11 +216,13 @@ In this example, the following command outputs the details for a single pod as a
kubectl get pod web-pod-13je7 -o yaml
```
Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation for details about which output format is supported by each command.
Remember: See the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation
for details about which output format is supported by each command.
#### Custom columns
To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option. You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option.
You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
##### Examples
@@ -496,12 +506,8 @@ kubectl whoami
Current user: plugins-user
```
## {{% heading "whatsnext" %}}
* Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
* To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
content/en/docs/reference/setup-tools/_index.md
-1
View File
@@ -1,5 +1,4 @@
---
title: Setup tools reference
weight: 50
toc-hide: true
---
content/en/docs/reference/setup-tools/kubeadm/_index.md
+26 -1
View File
@@ -1,5 +1,30 @@
---
title: "Kubeadm"
weight: 10
toc-hide: true
no_list: true
content_type: concept
card:
name: reference
weight: 40
---
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
## How to install
To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+1 -3
View File
@@ -15,7 +15,6 @@ However, it might not be obvious _how_ kubeadm does that.
This document provides additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices.
<!-- body -->
## Core design principles
@@ -518,6 +517,7 @@ Please note that:
- The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process
### (optional) Write init kubelet configuration
{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
@@ -530,5 +530,3 @@ If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
Please note that:
1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
+3 -2
View File
@@ -3,8 +3,10 @@ reviewers:
- luxas
- jbeda
title: kubeadm alpha
content_type: concept
weight: 90
---
{{< caution >}}
`kubeadm alpha` provides a preview of a set of features made available for gathering feedback
from the community. Please try it out and give us feedback!
@@ -67,7 +69,6 @@ Use the following command to enable the DynamicKubeletConfiguration feature.
{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}}
{{< /tabs >}}
## kubeadm alpha selfhosting pivot {#cmd-selfhosting}
The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one.
@@ -79,8 +80,8 @@ The subcommand `pivot` can be used to convert a static Pod-hosted control plane
{{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
## What's next
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
+7 -5
View File
@@ -6,6 +6,7 @@ title: kubeadm config
content_type: concept
weight: 50
---
<!-- overview -->
During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during
@@ -19,30 +20,31 @@ In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the Core
the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
has to be used.
<!-- body -->
## kubeadm config view {#cmd-config-view}
{{< include "generated/kubeadm_config_view.md" >}}
## kubeadm config print init-defaults {#cmd-config-print-init-defaults}
{{< include "generated/kubeadm_config_print_init-defaults.md" >}}
## kubeadm config print join-defaults {#cmd-config-print-join-defaults}
{{< include "generated/kubeadm_config_print_join-defaults.md" >}}
## kubeadm config migrate {#cmd-config-migrate}
{{< include "generated/kubeadm_config_migrate.md" >}}
## kubeadm config images list {#cmd-config-images-list}
{{< include "generated/kubeadm_config_images_list.md" >}}
## kubeadm config images pull {#cmd-config-images-pull}
{{< include "generated/kubeadm_config_images_pull.md" >}}
## {{% heading "whatsnext" %}}
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
+4 -5
View File
@@ -1,7 +1,9 @@
---
title: kubeadm init phase
weight: 90
content_type: concept
---
`kubeadm init phase` enables you to invoke atomic steps of the bootstrap process.
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
@@ -80,7 +82,6 @@ Use the following phase to create a local etcd instance based on a static Pod fi
{{< tab name="local" include="generated/kubeadm_init_phase_etcd_local.md" />}}
{{< /tabs >}}
## kubeadm init phase upload-config {#cmd-phase-upload-config}
You can use this command to upload the kubeadm configuration to your cluster.
@@ -93,7 +94,6 @@ Alternatively, you can use [kubeadm config](/docs/reference/setup-tools/kubeadm/
{{< tab name="kubelet" include="generated/kubeadm_init_phase_upload-config_kubelet.md" />}}
{{< /tabs >}}
## kubeadm init phase upload-certs {#cmd-phase-upload-certs}
Use the following phase to upload control-plane certificates to the cluster.
@@ -103,7 +103,6 @@ By default the certs and encryption key expire after two hours.
{{< tab name="upload-certs" include="generated/kubeadm_init_phase_upload-certs.md" />}}
{{< /tabs >}}
## kubeadm init phase mark-control-plane {#cmd-phase-mark-control-plane}
Use the following phase to label and taint the node with the `node-role.kubernetes.io/master=""` key-value pair.
@@ -112,7 +111,6 @@ Use the following phase to label and taint the node with the `node-role.kubernet
{{< tab name="mark-control-plane" include="generated/kubeadm_init_phase_mark-control-plane.md" />}}
{{< /tabs >}}
## kubeadm init phase bootstrap-token {#cmd-phase-bootstrap-token}
Use the following phase to configure bootstrap tokens.
@@ -156,7 +154,8 @@ Please note that kube-dns usage with kubeadm is deprecated as of v1.18 and will
For more details on each field in the `v1beta2` configuration you can navigate to our
[API reference pages.] (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)
## What's next
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+17 -20
View File
@@ -9,12 +9,12 @@ weight: 20
<!-- overview -->
This command initializes a Kubernetes control-plane node.
<!-- body -->
{{< include "generated/kubeadm_init.md" >}}
### Init workflow {#init-workflow}
`kubeadm init` bootstraps a Kubernetes control-plane node by executing the
following steps:
@@ -166,7 +166,7 @@ to download the certificates when additional control-plane nodes are joining, by
The following phase command can be used to re-upload the certificates after expiration:
```
```shell
kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE
```
@@ -175,7 +175,7 @@ If the flag `--certificate-key` is not passed to `kubeadm init` and
The following command can be used to generate a new key on demand:
```
```shell
kubeadm alpha certs certificate-key
```
@@ -226,26 +226,26 @@ token distribution for easier automation. To implement this automation, you must
know the IP address that the control-plane node will have after it is started,
or use a DNS name or an address of a load balancer.
1. Generate a token. This token must have the form `<6 character string>.<16
character string>`. More formally, it must match the regex:
`[a-z0-9]{6}\.[a-z0-9]{16}`.
1. Generate a token. This token must have the form `<6 character string>.<16
character string>`. More formally, it must match the regex:
`[a-z0-9]{6}\.[a-z0-9]{16}`.
kubeadm can generate a token for you:
kubeadm can generate a token for you:
```shell
```shell
kubeadm token generate
```
```
1. Start both the control-plane node and the worker nodes concurrently with this token.
As they come up they should find each other and form the cluster. The same
`--token` argument can be used on both `kubeadm init` and `kubeadm join`.
1. Start both the control-plane node and the worker nodes concurrently with this token.
As they come up they should find each other and form the cluster. The same
`--token` argument can be used on both `kubeadm init` and `kubeadm join`.
1. Similar can be done for `--certificate-key` when joining additional control-plane
nodes. The key can be generated using:
1. Similar can be done for `--certificate-key` when joining additional control-plane
nodes. The key can be generated using:
```shell
kubeadm alpha certs certificate-key
```
```shell
kubeadm alpha certs certificate-key
```
Once the cluster is up, you can grab the admin credentials from the control-plane node
at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
@@ -255,8 +255,6 @@ it does not allow the root CA hash to be validated with
`--discovery-token-ca-cert-hash` (since it's not generated when the nodes are
provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/).
## {{% heading "whatsnext" %}}
* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
@@ -264,4 +262,3 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
+4 -1
View File
@@ -1,7 +1,9 @@
---
title: kubeadm join phase
weight: 90
content_type: concept
---
`kubeadm join phase` enables you to invoke atomic steps of the join process.
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
@@ -56,7 +58,8 @@ Using this phase you can join a node as a control-plane instance.
{{< tab name="mark-control-plane" include="generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md" />}}
{{< /tabs >}}
## What's next
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+32 -28
View File
@@ -9,7 +9,6 @@ weight: 30
<!-- overview -->
This command initializes a Kubernetes worker node and joins it to the cluster.
<!-- body -->
{{< include "generated/kubeadm_join.md" >}}
@@ -105,18 +104,18 @@ if the `kubeadm init` command was called with `--upload-certs`.
**Advantages:**
- Allows bootstrapping nodes to securely discover a root of trust for the
control-plane node even if other worker nodes or the network are compromised.
- Allows bootstrapping nodes to securely discover a root of trust for the
control-plane node even if other worker nodes or the network are compromised.
- Convenient to execute manually since all of the information required fits
into a single `kubeadm join` command that is easy to copy and paste.
- Convenient to execute manually since all of the information required fits
into a single `kubeadm join` command that is easy to copy and paste.
**Disadvantages:**
- The CA hash is not normally known until the control-plane node has been provisioned,
which can make it more difficult to build automated provisioning tools that
use kubeadm. By generating your CA in beforehand, you may workaround this
limitation.
- The CA hash is not normally known until the control-plane node has been provisioned,
which can make it more difficult to build automated provisioning tools that
use kubeadm. By generating your CA in beforehand, you may workaround this
limitation.
#### Token-based discovery without CA pinning
@@ -134,18 +133,18 @@ kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-ve
**Advantages:**
- Still protects against many network-level attacks.
- Still protects against many network-level attacks.
- The token can be generated ahead of time and shared with the control-plane node and
worker nodes, which can then bootstrap in parallel without coordination. This
allows it to be used in many provisioning scenarios.
- The token can be generated ahead of time and shared with the control-plane node and
worker nodes, which can then bootstrap in parallel without coordination. This
allows it to be used in many provisioning scenarios.
**Disadvantages:**
- If an attacker is able to steal a bootstrap token via some vulnerability,
they can use that token (along with network-level access) to impersonate the
control-plane node to other bootstrapping nodes. This may or may not be an appropriate
tradeoff in your environment.
- If an attacker is able to steal a bootstrap token via some vulnerability,
they can use that token (along with network-level access) to impersonate the
control-plane node to other bootstrapping nodes. This may or may not be an appropriate
tradeoff in your environment.
#### File or HTTPS-based discovery
@@ -158,21 +157,21 @@ In case the discovery file does not contain credentials, the TLS discovery token
**Example `kubeadm join` commands:**
- `kubeadm join --discovery-file path/to/file.conf` (local file)
- `kubeadm join --discovery-file path/to/file.conf` (local file)
- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
- `kubeadm join --discovery-file https://url/file.conf` (remote HTTPS URL)
**Advantages:**
- Allows bootstrapping nodes to securely discover a root of trust for the
control-plane node even if the network or other worker nodes are compromised.
- Allows bootstrapping nodes to securely discover a root of trust for the
control-plane node even if the network or other worker nodes are compromised.
**Disadvantages:**
- Requires that you have some way to carry the discovery information from
the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
you must keep it secret and transfer it over a secure channel. This might be possible with your
cloud provider or provisioning tool.
- Requires that you have some way to carry the discovery information from
the control-plane node to the bootstrapping nodes. If the discovery file contains credentials
you must keep it secret and transfer it over a secure channel. This might be possible with your
cloud provider or provisioning tool.
### Securing your installation even more {#securing-more}
@@ -194,7 +193,9 @@ After that, `kubeadm join` will block until the admin has manually approved the
```shell
kubectl get csr
```
The output is similar to this:
```
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending
@@ -203,7 +204,9 @@ node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstra
```shell
kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
```
The output is similar to this:
```
certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
```
@@ -211,7 +214,9 @@ certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ"
```shell
kubectl get csr
```
The output is similar to this:
```
NAME AGE REQUESTOR CONDITION
node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued
@@ -232,7 +237,9 @@ it off regardless. Doing so will disable the ability to use the `--discovery-tok
```shell
kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml
```
The output is similar to this:
```
apiVersion: v1
kind: Config
@@ -276,11 +283,8 @@ kubeadm config print join-defaults
For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration).
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join`
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
+4 -1
View File
@@ -1,7 +1,9 @@
---
title: kubeadm reset phase
weight: 90
content_type: concept
---
`kubeadm reset phase` enables you to invoke atomic steps of the node reset process.
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
@@ -47,7 +49,8 @@ Using this phase you can perform cleanup on this node.
{{< tab name="cleanup-node" include="generated/kubeadm_reset_phase_cleanup-node.md" />}}
{{< /tabs >}}
## What's next
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
-3
View File
@@ -9,7 +9,6 @@ weight: 60
<!-- overview -->
Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`.
<!-- body -->
{{< include "generated/kubeadm_reset.md" >}}
@@ -36,9 +35,7 @@ etcdctl del "" --prefix
See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information.
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
-4
View File
@@ -14,8 +14,6 @@ the cluster and a control-plane node, as described in [authenticating with boots
`kubeadm init` creates an initial token with a 24-hour TTL. The following commands allow you to manage
such a token and also to create and manage new ones.
<!-- body -->
## kubeadm token create {#cmd-token-create}
{{< include "generated/kubeadm_token_create.md" >}}
@@ -29,8 +27,6 @@ such a token and also to create and manage new ones.
## kubeadm token list {#cmd-token-list}
{{< include "generated/kubeadm_token_list.md" >}}
## {{% heading "whatsnext" %}}
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
+3 -1
View File
@@ -1,6 +1,7 @@
---
title: kubeadm upgrade phase
weight: 90
content_type: concept
---
In v1.15.0, kubeadm introduced preliminary support for `kubeadm upgrade node` phases.
Phases for other `kubeadm upgrade` sub-commands such as `apply`, could be added in the
@@ -18,7 +19,8 @@ be called on a primary control-plane node.
{{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
{{< /tabs >}}
## What's next
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
-2
View File
@@ -47,8 +47,6 @@ reports of unexpected results.
{{< include "generated/kubeadm_upgrade_node.md" >}}
## {{% heading "whatsnext" %}}
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
-2
View File
@@ -9,7 +9,5 @@ weight: 80
<!-- overview -->
This command prints the version of kubeadm.
<!-- body -->
{{< include "generated/kubeadm_version.md" >}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm.md
-30
View File
@@ -1,30 +0,0 @@
---
reviewers:
- luxas
- jbeda
title: Overview of kubeadm
weight: 10
card:
name: reference
weight: 40
---
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
## How to install
To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
## What's next
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
content/en/docs/reference/using-api/_index.md
-1
View File
@@ -1,5 +1,4 @@
---
title: Using the Kubernetes API
weight: 10
toc-hide: true
---
content/en/docs/reference/using-api/api-overview.md
+1 -1
View File
@@ -84,7 +84,7 @@ Currently, there are several API groups in use:
* The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
(for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/).
The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
The two paths that support extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are:
- [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
for basic CRUD needs.
content/en/docs/reference/using-api/client-libraries.md
+3 -3
View File
@@ -19,13 +19,13 @@ You can use a client library for the programming language you are using.
Client libraries often handle common tasks such as authentication for you.
Most client libraries can discover and use the Kubernetes Service Account to
authenticate if the API client is running inside the Kubernetes cluster, or can
understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
format to read the credentials and the API Server address.
## Officially-supported Kubernetes client libraries
The following client libraries are officially maintained by [Kubernetes SIG API
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
The following client libraries are officially maintained by
[Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
| Language | Client Library | Sample Programs |
content/en/docs/reference/using-api/deprecation-policy.md
+1 -2
View File
@@ -289,8 +289,7 @@ API versions are supported in a series of subsequent releases.
### REST resources (aka API objects)
Consider a hypothetical REST resource named Widget, which was present in API v1
in the above timeline, and which needs to be deprecated. We
[document](/docs/reference/deprecation-policy/) and
in the above timeline, and which needs to be deprecated. We document and
[announce](https://groups.google.com/forum/#!forum/kubernetes-announce) the
deprecation in sync with release X+1. The Widget resource still exists in API
version v1 (deprecated) but not in v2alpha1. The Widget resource continues to