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

resolving conflicts

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-06-16 17:08:15 -04:00
parent 3ad8c45b0b 13ca92d745
commit 7ddedb00a0
1497 changed files with 24525 additions and 14364 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/_index.md
+5 -5
View File
@@ -5,16 +5,16 @@ approvers:
linkTitle: "Reference"
main_menu: true
weight: 70
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
This section of the Kubernetes documentation contains references.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## API Reference
@@ -52,4 +52,4 @@ client libraries:
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).
{{% /capture %}}
content/en/docs/reference/access-authn-authz/abac.md
+5 -5
View File
@@ -5,15 +5,15 @@ reviewers:
- deads2k
- liggitt
title: Using ABAC Authorization
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Policy File Format
To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
@@ -152,5 +152,5 @@ privilege to the API using ABAC, you would add this line to your policy file:
The apiserver will need to be restarted to pickup the new policy lines.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/admission-controllers.md
+12 -10
View File
@@ -7,15 +7,15 @@ reviewers:
- janetkuo
- thockin
title: Using Admission Controllers
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of Admission Controllers.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## What are they?
An admission controller is a piece of code that intercepts requests to the
@@ -32,6 +32,8 @@ which are configured in the API.
Admission controllers may be "validating", "mutating", or both. Mutating
controllers may modify the objects they admit; validating controllers may not.
Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
The admission control process proceeds in two phases. In the first phase,
mutating admission controllers are run. In the second phase, validating
admission controllers are run. Note again that some of the controllers are
@@ -610,7 +612,7 @@ node selector.
2. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector`
plugin configuration file as the node selector.
3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection.
4. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file.
4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the plugin configuration file.
Conflicts result in rejection.
{{< note >}}
@@ -672,15 +674,15 @@ for more information.
The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace.
It rejects the pod request if there is a conflict.
It then merges the tolerations annotated on the namespace into the tolerations of the pod.
The resulting tolerations are checked against a whitelist of tolerations annotated to the namespace.
The resulting tolerations are checked against a list of allowed tolerations annotated to the namespace.
If the check succeeds, the pod request is admitted otherwise it is rejected.
If the namespace of the pod does not have any associated default tolerations or a whitelist of
tolerations annotated, the cluster-level default tolerations or cluster-level whitelist of tolerations are used
If the namespace of the pod does not have any associated default tolerations or allowed
tolerations annotated, the cluster-level default tolerations or cluster-level list of allowed tolerations are used
instead if they are specified.
Tolerations to a namespace are assigned via the `scheduler.alpha.kubernetes.io/defaultTolerations` annotation key.
The whitelist can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
The list of allowed tolerations can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
Example for namespace annotations:
@@ -773,4 +775,4 @@ in the mutating phase.
For earlier versions, there was no concept of validating versus mutating and the
admission controllers ran in the exact order specified.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/authentication.md
+5 -5
View File
@@ -6,15 +6,15 @@ reviewers:
- deads2k
- liggitt
title: Authenticating
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of authenticating.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Users in Kubernetes
All Kubernetes clusters have two categories of users: service accounts managed
@@ -840,4 +840,4 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
}
}
```
{{% /capture %}}
content/en/docs/reference/access-authn-authz/authorization.md
+8 -7
View File
@@ -5,16 +5,16 @@ reviewers:
- deads2k
- liggitt
title: Authorization Overview
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Learn more about Kubernetes authorization, including details about creating
policies using the supported authorization modules.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
In Kubernetes, you must be authenticated (logged in) before your request can be
authorized (granted permission to access). For information about authentication,
see [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
@@ -197,9 +197,10 @@ namespace can: read all secrets in the namespace; read all config maps in the
namespace; and impersonate any service account in the namespace and take any
action the account could take. This applies regardless of authorization mode.
{{< /caution >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
* To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
{{% /capture %}}
content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
+5 -5
View File
@@ -2,11 +2,11 @@
reviewers:
- jbeda
title: Authenticating with Bootstrap Tokens
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
@@ -16,9 +16,9 @@ to support [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), but can be u
for users that wish to start clusters without `kubeadm`. It is also built to
work, via RBAC policy, with the [Kubelet TLS
Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Bootstrap Tokens Overview
Bootstrap Tokens are defined with a specific type
@@ -188,4 +188,4 @@ client relying on the signature to bootstrap TLS trust.
Consult the [kubeadm implementation details](/docs/reference/setup-tools/kubeadm/implementation-details/)
section for more information.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
+8 -7
View File
@@ -4,11 +4,11 @@ reviewers:
- mikedanese
- munnerz
title: Certificate Signing Requests
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -21,9 +21,9 @@ A CertificateSigningRequest (CSR) resource is used to request that a certificate
by a denoted signer, after which the request may be approved or denied before
finally being signed.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Request signing process
The _CertificateSigningRequest_ resource type allows a client to ask for an X.509 certificate
@@ -317,9 +317,10 @@ subresource of the CSR to be signed.
As part of this request, the `status.certificate` field should be set to contain the
signed certificate.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read [Manage TLS Certificates in a Cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)
* View the source code for the kube-controller-manager built in [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
@@ -327,4 +328,4 @@ signed certificate.
* For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
* For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
{{% /capture %}}
content/en/docs/reference/access-authn-authz/controlling-access.md
+13 -12
View File
@@ -3,15 +3,15 @@ reviewers:
- erictune
- lavalamp
title: Controlling Access to the Kubernetes API
content_template: templates/concept
content_type: concept
weight: 5
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of controlling access to the Kubernetes API.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Users [access the API](/docs/tasks/access-application-cluster/access-cluster/) using `kubectl`,
client libraries, or by making REST requests. Both human users and
[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
@@ -23,7 +23,7 @@ following diagram:
## Transport Security
In a typical Kubernetes cluster, the API serves on port 6443.
In a typical Kubernetes cluster, the API serves on port 443.
The API server presents a certificate. This certificate is
often self-signed, so `$USER/.kube/config` on the user's machine typically
contains the root certificate for the API server's certificate, which when specified
@@ -63,9 +63,9 @@ users in its object store.
## Authorization
After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`:
@@ -97,7 +97,7 @@ If Bob makes the following request, the request is authorized because he is allo
}
}
```
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
@@ -110,10 +110,11 @@ To learn more about Kubernetes authorization, including details about creating p
Admission Control Modules are software modules that can modify or reject requests.
In addition to the attributes available to Authorization Modules, Admission
Control Modules can access the contents of the object that is being created or updated.
They act on objects being created, deleted, updated or connected (proxy), but not reads.
Control Modules can access the contents of the object that is being created or modified.
Multiple admission controllers can be configured. Each is called in order.
Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object.
Admission controllers do not act on requests that merely read objects.
When multiple admission controllers are configured, they are called in order.
This is shown as step **3** in the diagram.
@@ -161,4 +162,4 @@ When the cluster is created by `kube-up.sh`, on Google Compute Engine (GCE),
and on several other cloud providers, the API server serves on port 443. On
GCE, a firewall rule is configured on the project to allow external HTTPS
access to the API. Other cluster setup methods vary.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+4 -5
View File
@@ -7,18 +7,17 @@ reviewers:
- liggitt
- jpbetz
title: Dynamic Admission Control
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
In addition to [compiled-in admission plugins](/docs/reference/access-authn-authz/admission-controllers/),
admission plugins can be developed as extensions and run as webhooks configured at runtime.
This page describes how to build, configure, use, and monitor admission webhooks.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## What are admission webhooks?
Admission webhooks are HTTP callbacks that receive admission requests and do
@@ -1589,4 +1588,4 @@ If your admission webhooks don't intend to modify the behavior of the Kubernetes
plane, exclude the `kube-system` namespace from being intercepted using a
[`namespaceSelector`](#matching-requests-namespaceselector).
{{% /capture %}}
content/en/docs/reference/access-authn-authz/node.md
+5 -5
View File
@@ -5,15 +5,15 @@ reviewers:
- liggitt
- ericchiang
title: Using Node Authorization
content_template: templates/concept
content_type: concept
weight: 90
---
{{% capture overview %}}
<!-- overview -->
Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Overview
The Node authorizer allows a kubelet to perform API operations. This includes:
@@ -96,4 +96,4 @@ In 1.8, the binding will not be created at all.
When using RBAC, the `system:node` cluster role will continue to be created,
for compatibility with deployment methods that bind other users or groups to that role.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/rbac.md
+4 -6
View File
@@ -4,17 +4,17 @@ reviewers:
- deads2k
- liggitt
title: Using RBAC Authorization
content_template: templates/concept
content_type: concept
aliases: [/rbac/]
weight: 70
---
{{% capture overview %}}
<!-- overview -->
Role-based access control (RBAC) is a method of regulating access to computer or
network resources based on the roles of individual users within your organization.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
RBAC authorization uses the `rbac.authorization.k8s.io`
{{< glossary_tooltip text="API group" term_id="api-group" >}} to drive authorization
decisions, allowing you to dynamically configure policies through the Kubernetes API.
@@ -1209,5 +1209,3 @@ kubectl create clusterrolebinding permissive-binding \
After you have transitioned to use RBAC, you should adjust the access controls
for your cluster to ensure that these meet your information security needs.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+5 -5
View File
@@ -5,19 +5,19 @@ reviewers:
- lavalamp
- liggitt
title: Managing Service Accounts
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- 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).
Support for authorization and user accounts is planned but incomplete. Sometimes
incomplete features are referred to in order to better describe service accounts.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## User accounts versus service accounts
Kubernetes distinguishes between the concept of a user account and a service account
@@ -115,4 +115,4 @@ kubectl delete secret mysecretname
Service Account Controller manages ServiceAccount inside namespaces, and ensures
a ServiceAccount named "default" exists in every active namespace.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/webhook.md
+6 -9
View File
@@ -5,15 +5,15 @@ reviewers:
- deads2k
- liggitt
title: Webhook Mode
content_template: templates/concept
content_type: concept
weight: 95
---
{{% capture overview %}}
<!-- overview -->
A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
When specified, mode `Webhook` causes Kubernetes to query an outside REST
service when determining user privileges.
@@ -164,8 +164,8 @@ Access to non-resource paths are sent as:
}
```
Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
Non-resource paths include: `/api`, `/apis`, `/metrics`,
`/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and
`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
and `/version` to discover what resources and versions are present on the server.
Access to other non-resource paths can be disallowed without restricting access
@@ -174,6 +174,3 @@ to the REST api.
For further documentation refer to the authorization.v1beta1 API objects and
[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
+7 -5
View File
@@ -1,10 +1,11 @@
---
title: cloud-controller-manager
content_template: templates/tool-reference
content_type: tool-reference
weight: 30
---
{{% capture synopsis %}}
## {{% heading "synopsis" %}}
The Cloud controller manager is a daemon that embeds
@@ -14,9 +15,10 @@ the cloud specific control loops shipped with Kubernetes.
cloud-controller-manager [flags]
```
{{% /capture %}}
{{% capture options %}}
## {{% heading "options" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
@@ -534,5 +536,5 @@ cloud-controller-manager [flags]
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/feature-gates.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
weight: 10
title: Feature Gates
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
This page contains an overview of the various feature gates an administrator
can specify on different Kubernetes components.
See [feature stages](#feature-stages) for an explanation of the stages for a feature.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Overview
Feature gates are a set of key=value pairs that describe Kubernetes features.
@@ -512,8 +512,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
- `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* The [deprecation policy](/docs/reference/using-api/deprecation-policy/) for Kubernetes explains
the project's approach to removing features and components.
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
+7 -5
View File
@@ -1,10 +1,11 @@
---
title: kube-apiserver
content_template: templates/tool-reference
content_type: tool-reference
weight: 30
---
{{% capture synopsis %}}
## {{% heading "synopsis" %}}
The Kubernetes API server validates and configures data
@@ -16,9 +17,10 @@ cluster's shared state through which all other components interact.
kube-apiserver [flags]
```
{{% /capture %}}
{{% capture options %}}
## {{% heading "options" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
@@ -1082,5 +1084,5 @@ kube-apiserver [flags]
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
+7 -5
View File
@@ -1,10 +1,11 @@
---
title: kube-controller-manager
content_template: templates/tool-reference
content_type: tool-reference
weight: 30
---
{{% capture synopsis %}}
## {{% heading "synopsis" %}}
The Kubernetes controller manager is a daemon that embeds
@@ -20,9 +21,10 @@ controller, and serviceaccounts controller.
kube-controller-manager [flags]
```
{{% /capture %}}
{{% capture options %}}
## {{% heading "options" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
@@ -897,5 +899,5 @@ kube-controller-manager [flags]
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/kube-proxy.md
+7 -5
View File
@@ -1,10 +1,11 @@
---
title: kube-proxy
content_template: templates/tool-reference
content_type: tool-reference
weight: 30
---
{{% capture synopsis %}}
## {{% heading "synopsis" %}}
The Kubernetes network proxy runs on each node. This
@@ -19,9 +20,10 @@ with the apiserver API to configure the proxy.
kube-proxy [flags]
```
{{% /capture %}}
{{% capture options %}}
## {{% heading "options" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
@@ -336,5 +338,5 @@ kube-proxy [flags]
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
+7 -5
View File
@@ -1,10 +1,11 @@
---
title: kube-scheduler
content_template: templates/tool-reference
content_type: tool-reference
weight: 30
---
{{% capture synopsis %}}
## {{% heading "synopsis" %}}
The Kubernetes scheduler is a policy-rich, topology-aware,
@@ -20,9 +21,10 @@ for more information about scheduling and the kube-scheduler component.
kube-scheduler [flags]
```
{{% /capture %}}
{{% capture options %}}
## {{% heading "options" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
@@ -512,5 +514,5 @@ kube-scheduler [flags]
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
-1
View File
@@ -4,7 +4,6 @@ reviewers:
title: Kubelet authentication/authorization
---
{{< toc >}}
## Overview
content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
+17 -29
View File
@@ -5,28 +5,28 @@ reviewers:
- smarterclayton
- awly
title: TLS bootstrapping
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver.
In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly
recommend using client TLS certificates on nodes.
The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver,
can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work.
The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver,
can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work.
This in turn, can make it challenging to initialize or scale a cluster.
In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API to simplify the process. The proposal can be
found [here](https://github.com/kubernetes/kubernetes/pull/20439).
This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for
kubelets, and how it works.
kubelets, and how it works.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Initialization Process
When a worker node starts up, the kubelet does the following:
@@ -90,7 +90,7 @@ In addition, you need your Kubernetes Certificate Authority (CA).
As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used
to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes.
For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
We will refer to these as "Kubernetes CA certificate and key".
All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.
@@ -98,7 +98,7 @@ All Kubernetes components that use these certificates - kubelet, kube-apiserver,
## kube-apiserver configuration
The kube-apiserver has several requirements to enable TLS bootstrapping:
* Recognizing CA that signs the client certificate
* Recognizing CA that signs the client certificate
* Authenticating the bootstrapping kubelet to the `system:bootstrappers` group
* Authorize the bootstrapping kubelet to create a certificate signing request (CSR)
@@ -120,13 +120,13 @@ of provisioning.
1. [Bootstrap Tokens](#bootstrap-tokens)
2. [Token authentication file](#token-authentication-file)
Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12.
Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to:
1. create and retrieve CSRs
2. be automatically approved to request node client certificates, if automatic approval is enabled.
2. be automatically approved to request node client certificates, if automatic approval is enabled.
A kubelet authenticating using bootstrap tokens is authenticated as a user in the group `system:bootstrappers`, which is the standard method to use.
@@ -152,7 +152,7 @@ From the kube-apiserver's perspective, however, the bootstrap token is special.
and grants anyone authenticating with that token special bootstrap rights, notably treating them as a member of the `system:bootstrappers` group. This fulfills a basic requirement
for TLS bootstrapping.
The details for creating the secret are available [here](/docs/reference/access-authn-authz/bootstrap-tokens/).
The details for creating the secret are available [here](/docs/reference/access-authn-authz/bootstrap-tokens/).
If you want to use bootstrap tokens, you must enable it on kube-apiserver with the flag:
@@ -161,7 +161,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t
```
#### Token authentication file
kube-apiserver has an ability to accept tokens as authentication.
kube-apiserver has an ability to accept tokens as authentication.
These tokens are arbitrary but should represent at least 128 bits of entropy derived
from a secure random number generator (such as `/dev/urandom` on most modern Linux
systems). There are multiple ways you can generate a token. For example:
@@ -252,8 +252,8 @@ RBAC permissions to the correct group.
There are two distinct sets of permissions:
* `nodeclient`: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group `system:bootstrappers`.
* `selfnodeclient`: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group `system:nodes`.
* `nodeclient`: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group `system:bootstrappers`.
* `selfnodeclient`: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group `system:nodes`.
To enable the kubelet to request and receive a new certificate, create a `ClusterRoleBinding` that binds the group in which the bootstrapping node is a member `system:bootstrappers` to the `ClusterRole` that grants it permission, `system:certificates.k8s.io:certificatesigningrequests:nodeclient`:
@@ -273,7 +273,7 @@ roleRef:
apiGroup: rbac.authorization.k8s.io
```
To enable the kubelet to renew its own client certificate, create a `ClusterRoleBinding` that binds the group in which the fully functioning node is a member `system:nodes` to the `ClusterRole` that
To enable the kubelet to renew its own client certificate, create a `ClusterRoleBinding` that binds the group in which the fully functioning node is a member `system:nodes` to the `ClusterRole` that
grants it permission, `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`:
```yml
@@ -382,7 +382,7 @@ To secure these, the kubelet can do one of:
* request serving certificates from the cluster server, via the CSR API
The client certificate provided by TLS bootstrapping is signed, by default, for `client auth` only, and thus cannot
be used as serving certificates, or `server auth`.
be used as serving certificates, or `server auth`.
However, you _can_ enable its server certificate, at least partially, via certificate rotation.
@@ -443,15 +443,3 @@ also manually approve certificate requests using kubectl. An administrator can
list CSRs with `kubectl get csr` and describe one in detail with `kubectl
describe csr <name>`. An administrator can approve or deny a CSR with `kubectl
certificate approve <name>` and `kubectl certificate deny <name>`.
## Limits
Although Kubernetes supports running control plane master components like kube-apiserver and kube-controller-manager in containers, and even as `Pod`s in a kubelet, as of this writing, you cannot both TLS Bootstrap a kubelet and run master plane components on it.
The reason for this limitation is that the kubelet attempts to bootstrap communication with kube-apiserver _before_ starting any pods, even static ones define on disk and referenced via the kubelet option `--pod-manifest-path=<PATH>`. Trying to do both TLS Bootstrapping and master components in kubelet leads to a race condition: kubelet needs to communicate to kube-apiserver to request certificates, yet requires those certificates to be available to start kube-apiserver.
An issue is open referencing this [here](https://github.com/kubernetes/kubernetes/issues/68686).
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/kubelet.md
+7 -5
View File
@@ -1,10 +1,11 @@
---
title: kubelet
content_template: templates/tool-reference
content_type: tool-reference
weight: 28
---
{{% capture synopsis %}}
## {{% heading "synopsis" %}}
The kubelet is the primary "node agent" that runs on each
node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider.
@@ -24,10 +25,11 @@ HTTP server: The kubelet can also listen for HTTP and respond to a simple API (u
kubelet [flags]
```
{{% /capture %}}
{{% capture options %}}
## {{% heading "options" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
@@ -1265,4 +1267,4 @@ kubelet [flags]
</tbody>
</table>
{{% /capture %}}
content/en/docs/reference/glossary/aggregation-layer.md
+2 -2
View File
@@ -14,6 +14,6 @@ tags:
---
The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
<!--more-->
<!--more-->
When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.
When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/extend-kubernetes/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.
content/en/docs/reference/glossary/cronjob.md
+1 -1
View File
@@ -11,7 +11,7 @@ tags:
- core-object
- workload
---
Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule.
Manages a [Job](/docs/concepts/workloads/controllers/job/) that runs on a periodic schedule.
<!--more-->
content/en/docs/reference/glossary/customresourcedefinition.md
+3 -4
View File
@@ -2,7 +2,7 @@
title: CustomResourceDefinition
id: CustomResourceDefinition
date: 2018-04-12
full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/
full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
short_description: >
Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server.
@@ -14,7 +14,6 @@ tags:
---
Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server.
<!--more-->
Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.
<!--more-->
Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.
content/en/docs/reference/glossary/job.md
+1 -1
View File
@@ -2,7 +2,7 @@
title: Job
id: job
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion
full_link: /docs/concepts/workloads/controllers/job/
short_description: >
A finite or batch task that runs to completion.
content/en/docs/reference/issues-security/security.md
+5 -5
View File
@@ -6,15 +6,15 @@ reviewers:
- erictune
- philips
- jessfraz
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This page describes Kubernetes security and disclosure information.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Security Announcements
Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements.
@@ -56,4 +56,4 @@ As the security issue moves from triage, to identified fix, to release planning
## Public Disclosure Timing
A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date.
{{% /capture %}}
content/en/docs/reference/kubectl/cheatsheet.md
+8 -7
View File
@@ -4,21 +4,21 @@ reviewers:
- erictune
- krousey
- clove
content_template: templates/concept
content_type: concept
card:
name: reference
weight: 30
---
{{% capture overview %}}
<!-- overview -->
See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath).
This page is an overview of the `kubectl` command.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
# kubectl - Cheat Sheet
@@ -382,9 +382,10 @@ Verbosity | Description
`--v=8` | Display HTTP request contents.
`--v=9` | Display HTTP request contents without truncation of contents.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
@@ -394,4 +395,4 @@ Verbosity | Description
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
{{% /capture %}}
content/en/docs/reference/kubectl/conventions.md
+5 -5
View File
@@ -2,14 +2,14 @@
title: kubectl Usage Conventions
reviewers:
- janetkuo
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
Recommended usage conventions for `kubectl`.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Using `kubectl` in Reusable Scripts
@@ -59,4 +59,4 @@ You can generate the following resources with a kubectl command, `kubectl create
* You can use `kubectl apply` to create or update resources. For more information about using kubectl apply to update resources, see [Kubectl Book](https://kubectl.docs.kubernetes.io).
{{% /capture %}}
content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
+15 -9
View File
@@ -1,16 +1,16 @@
---
title: kubectl for Docker Users
content_template: templates/concept
content_type: concept
reviewers:
- brendandburns
- thockin
---
{{% capture overview %}}
<!-- overview -->
You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## docker run
To run an nginx Deployment and expose the Deployment, see [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-).
@@ -35,16 +35,22 @@ kubectl:
```shell
# start the pod running nginx
kubectl create deployment --image=nginx nginx-app --port=80
```
```
deployment.apps/nginx-app created
kubectl create deployment --image=nginx nginx-app
```
```shell
# add env to nginx-app
kubectl set env deployment/nginx-app DOMAIN=cluster
```
deployment.apps/nginx-app created
```
```
# add env to nginx-app
kubectl set env deployment/nginx-app DOMAIN=cluster
```
```
deployment.apps/nginx-app env updated
```
deployment.apps/nginx-app env updated
@@ -366,4 +372,4 @@ Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/servic
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
```
{{% /capture %}}
content/en/docs/reference/kubectl/jsonpath.md
+5 -5
View File
@@ -1,14 +1,14 @@
---
title: JSONPath Support
content_template: templates/concept
content_type: concept
weight: 25
---
{{% capture overview %}}
<!-- overview -->
Kubectl supports JSONPath template.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
JSONPath template is composed of JSONPath expressions enclosed by curly braces {}.
Kubectl uses JSONPath expressions to filter on specific fields in the JSON object and format the output.
@@ -98,4 +98,4 @@ kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.
```
{{< /note >}}
{{% /capture %}}
content/en/docs/reference/kubectl/kubectl.md
+10 -7
View File
@@ -1,10 +1,11 @@
---
title: kubectl
content_template: templates/tool-reference
content_type: tool-reference
weight: 30
---
{{% capture synopsis %}}
## {{% heading "synopsis" %}}
kubectl controls the Kubernetes cluster manager.
@@ -15,9 +16,10 @@ kubectl controls the Kubernetes cluster manager.
kubectl [flags]
```
{{% /capture %}}
{{% capture options %}}
## {{% heading "options" %}}
<table style="width: 100%; table-layout: fixed;">
<colgroup>
@@ -521,9 +523,10 @@ kubectl [flags]
{{% /capture %}}
{{% capture seealso %}}
## {{% heading "seealso" %}}
* [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha) - Commands for features in alpha
* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - Update the annotations on a resource
@@ -569,5 +572,5 @@ kubectl [flags]
* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Print the client and server version information
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Experimental: Wait for a specific condition on one or many resources.
{{% /capture %}}
content/en/docs/reference/kubectl/overview.md
+51 -39
View File
@@ -2,21 +2,21 @@
reviewers:
- hw-qiaolei
title: Overview of kubectl
content_template: templates/concept
content_type: concept
weight: 20
card:
name: reference
weight: 20
---
{{% capture overview %}}
Kubectl is a command line tool for controlling Kubernetes clusters. `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.
<!-- 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/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Syntax
@@ -32,11 +32,11 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
* `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
kubectl get pods pod1
kubectl get po pod1
```
```shell
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
```
* `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.
@@ -113,13 +113,13 @@ Operation | Syntax | Description
`version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.
`wait` | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | Experimental: Wait for a specific condition on one or many resources.
Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
To learn more about command operations, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation.
## Resource types
The following table includes a list of all the supported resource types and their abbreviated aliases.
(This output can be retrieved from `kubectl api-resources`, and is accurate as of Kubernetes 1.13.3.)
(This output can be retrieved from `kubectl api-resources`, and was accurate as of Kubernetes 1.13.3.)
| Resource Name | Short Names | API Group | Namespaced | Resource Kind |
|---|---|---|---|---|
@@ -175,7 +175,7 @@ The following table includes a list of all the supported resource types and thei
## Output options
Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation.
### Formatting output
@@ -234,9 +234,9 @@ where the `template.txt` file contains:
NAME RSRC
metadata.name metadata.resourceVersion
```
The result of running either command is:
The result of running either command is similar to:
```shell
```
NAME RSRC
submit-queue 610995
```
@@ -247,7 +247,7 @@ submit-queue 610995
This means that for any given resource, the server will return columns and rows relevant to that resource, for the client to print.
This allows for consistent human-readable output across clients used against the same cluster, by having the server encapsulate the details of printing.
This feature is enabled by default in `kubectl` 1.11 and higher. To disable it, add the
This feature is enabled by default. To disable it, add the
`--server-print=false` flag to the `kubectl get` command.
##### Examples
@@ -258,9 +258,9 @@ To print information about the status of a pod, use a command like the following
kubectl get pods <pod-name> --server-print=false
```
Output looks like this:
The output is similar to:
```shell
```
NAME AGE
pod-name 1m
```
@@ -405,19 +405,23 @@ Use the following set of examples to help you familiarize yourself with writing
# create a simple plugin in any language and name the resulting executable file
# so that it begins with the prefix "kubectl-"
cat ./kubectl-hello
#!/bin/bash
```
```shell
#!/bin/sh
# this plugin prints the words "hello world"
echo "hello world"
# with our plugin written, let's make it executable
sudo chmod +x ./kubectl-hello
```
With a plugin written, let's make it executable:
```bash
chmod a+x ./kubectl-hello
# and move it to a location in our PATH
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# we have now created and "installed" a kubectl plugin.
# we can begin using our plugin by invoking it from kubectl as if it were a regular command
# You have now created and "installed" a kubectl plugin.
# You can begin using this plugin by invoking it from kubectl as if it were a regular command
kubectl hello
```
```
@@ -425,16 +429,18 @@ hello world
```
```shell
# we can "uninstall" a plugin, by simply removing it from our PATH
# You can "uninstall" a plugin, by removing it from the folder in your
# $PATH where you placed it
sudo rm /usr/local/bin/kubectl-hello
```
In order to view all of the plugins that are available to `kubectl`, we can use
In order to view all of the plugins that are available to `kubectl`, use
the `kubectl plugin list` subcommand:
```shell
kubectl plugin list
```
The output is similar to:
```
The following kubectl-compatible plugins are available:
@@ -442,11 +448,11 @@ The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
```
`kubectl plugin list` also warns you about plugins that are not
executable, or that are shadowed by other plugins; for example:
```shell
# this command can also warn us about plugins that are
# not executable, or that are overshadowed by other
# plugins, for example
sudo chmod -x /usr/local/bin/kubectl-foo
sudo chmod -x /usr/local/bin/kubectl-foo # remove execute permission
kubectl plugin list
```
```
@@ -460,11 +466,15 @@ The following kubectl-compatible plugins are available:
error: one plugin warning was found
```
We can think of plugins as a means to build more complex functionality on top
You can think of plugins as a means to build more complex functionality on top
of the existing kubectl commands:
```shell
cat ./kubectl-whoami
```
The next few examples assume that you already made `kubectl-whoami` have
the following contents:
```shell
#!/bin/bash
# this plugin makes use of the `kubectl config` command in order to output
@@ -472,26 +482,28 @@ cat ./kubectl-whoami
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
```
Running the above plugin gives us an output containing the user for the currently selected
context in our KUBECONFIG file:
Running the above command gives you an output containing the user for the
current context in your KUBECONFIG file:
```shell
# make the file executable
sudo chmod +x ./kubectl-whoami
# and move it into our PATH
# and move it into your PATH
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
```
To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
{{% /capture %}}
{{% capture whatsnext %}}
Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
## {{% 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).
{{% /capture %}}
content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
title: Well-Known Labels, Annotations and Taints
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Kubernetes reserves all labels and annotations in the kubernetes.io namespace.
This document serves both as a reference to the values and as a coordination point for assigning values.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## kubernetes.io/arch
@@ -130,4 +130,4 @@ If `PersistentVolumeLabel` does not support automatic labeling of your Persisten
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
{{% /capture %}}
content/en/docs/reference/scheduling/policies.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: Scheduling Policies
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
A scheduling Policy can be used to specify the *predicates* and *priorities*
that the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
@@ -16,9 +16,9 @@ You can set a scheduling policy by running
`kube-scheduler --policy-configmap <ConfigMap>`
and using the [Policy type](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Predicates
@@ -117,9 +117,10 @@ The following *priorities* implement scoring:
- `EvenPodsSpreadPriority`: Implements preferred
[pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
* Learn about [kube-scheduler profiles](/docs/reference/scheduling/profiles/)
{{% /capture %}}
content/en/docs/reference/scheduling/profiles.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: Scheduling Profiles
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
@@ -20,9 +20,9 @@ or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@{{< param "fullversion"
The `v1alpha2` API allows you to configure kube-scheduler to run
[multiple profiles](#multiple-profiles).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Extension points
@@ -174,8 +174,9 @@ the same configuration parameters (if applicable). This is because the scheduler
only has one pending pods queue.
{{< /note >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+5 -5
View File
@@ -3,10 +3,10 @@ reviewers:
- luxas
- jbeda
title: Implementation details
content_template: templates/concept
content_type: concept
weight: 100
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
@@ -14,9 +14,9 @@ weight: 100
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.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Core design principles
The cluster that `kubeadm init` and `kubeadm join` set up should be:
@@ -531,4 +531,4 @@ 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`
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
+8 -7
View File
@@ -3,10 +3,10 @@ reviewers:
- luxas
- jbeda
title: kubeadm config
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- 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
`kubeadm join`, `kubeadm reset` and `kubeadm upgrade`. To view this ConfigMap call `kubeadm config view`.
@@ -19,9 +19,9 @@ 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.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## kubeadm config view {#cmd-config-view}
{{< include "generated/kubeadm_config_view.md" >}}
@@ -40,8 +40,9 @@ has to be used.
## kubeadm config images pull {#cmd-config-images-pull}
{{< include "generated/kubeadm_config_images_pull.md" >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+8 -7
View File
@@ -3,14 +3,14 @@ reviewers:
- luxas
- jbeda
title: kubeadm init
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This command initializes a Kubernetes control-plane node.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
{{< include "generated/kubeadm_init.md" >}}
@@ -255,12 +255,13 @@ 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/).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
`kubeadm init` phases
* [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`
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+8 -7
View File
@@ -3,14 +3,14 @@ reviewers:
- luxas
- jbeda
title: kubeadm join
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This command initializes a Kubernetes worker node and joins it to the cluster.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
{{< include "generated/kubeadm_join.md" >}}
### The join workflow {#join-workflow}
@@ -276,10 +276,11 @@ 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).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% 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`
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
+8 -7
View File
@@ -3,14 +3,14 @@ reviewers:
- luxas
- jbeda
title: kubeadm reset
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
{{< include "generated/kubeadm_reset.md" >}}
### Reset workflow {#reset-workflow}
@@ -35,9 +35,10 @@ etcdctl del "" --prefix
```
See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% 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
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md
+8 -7
View File
@@ -3,10 +3,10 @@ reviewers:
- luxas
- jbeda
title: kubeadm token
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
Bootstrap tokens are used for establishing bidirectional trust between a node joining
the cluster and a control-plane node, as described in [authenticating with bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/).
@@ -14,9 +14,9 @@ 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.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## kubeadm token create {#cmd-token-create}
{{< include "generated/kubeadm_token_create.md" >}}
@@ -28,8 +28,9 @@ such a token and also to create and manage new ones.
## kubeadm token list {#cmd-token-list}
{{< include "generated/kubeadm_token_list.md" >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
+8 -7
View File
@@ -3,15 +3,15 @@ reviewers:
- luxas
- jbeda
title: kubeadm upgrade
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
`kubeadm upgrade` is a user-friendly command that wraps complex upgrading logic
behind one command, with support for both planning an upgrade and actually performing it.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## kubeadm upgrade guidance
@@ -46,8 +46,9 @@ reports of unexpected results.
## kubeadm upgrade node {#cmd-upgrade-node}
{{< include "generated/kubeadm_upgrade_node.md" >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% 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`
{{% /capture %}}
content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md
+5 -5
View File
@@ -3,13 +3,13 @@ reviewers:
- luxas
- jbeda
title: kubeadm version
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
This command prints the version of kubeadm.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
{{< include "generated/kubeadm_version.md" >}}
{{% /capture %}}
content/en/docs/reference/tools.md
+5 -5
View File
@@ -2,14 +2,14 @@
reviewers:
- janetkuo
title: Tools
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
Kubernetes contains several built-in tools to help you work with the Kubernetes system.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Kubectl
[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
@@ -51,4 +51,4 @@ Use Kompose to:
* Translate a Docker Compose file into Kubernetes objects
* Go from local Docker development to managing your application via Kubernetes
* Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
{{% /capture %}}
content/en/docs/reference/using-api/api-concepts.md
+4 -4
View File
@@ -4,15 +4,15 @@ reviewers:
- smarterclayton
- lavalamp
- liggitt
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This page describes common concepts in the Kubernetes API.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
The Kubernetes API is a resource-based (RESTful) programmatic interface provided via HTTP. It supports retrieving, creating,
updating, and deleting primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET), includes additional subresources for many objects that allow fine grained authorization (such as binding a pod to a node), and can accept and serve those resources in different representations for convenience or efficiency. It also supports efficient change notifications on resources via "watches" and consistent lists to allow other components to effectively cache and synchronize the state of resources.
content/en/docs/reference/using-api/api-overview.md
+5 -5
View File
@@ -4,7 +4,7 @@ reviewers:
- erictune
- lavalamp
- jbeda
content_template: templates/concept
content_type: concept
weight: 10
card:
name: reference
@@ -12,11 +12,11 @@ card:
title: Overview of API
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of the Kubernetes API.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes
platform is treated as an API object and has a corresponding entry in the
[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
@@ -86,7 +86,7 @@ Currently, there are several API groups in use:
The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
- [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
- [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
for basic CRUD needs.
- [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) for a full set of Kubernetes API semantics to implement their own apiserver.
content/en/docs/reference/using-api/client-libraries.md
+5 -5
View File
@@ -2,16 +2,16 @@
title: Client Libraries
reviewers:
- ahmetb
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This page contains an overview of the client libraries for using the Kubernetes
API from various programming languages.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
To write applications using the [Kubernetes REST API](/docs/reference/using-api/api-overview/),
you do not need to implement the API calls and request/response types yourself.
You can use a client library for the programming language you are using.
@@ -75,6 +75,6 @@ their authors, not the Kubernetes team.
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
{{% /capture %}}
content/en/docs/reference/using-api/deprecation-policy.md
+5 -5
View File
@@ -4,15 +4,15 @@ reviewers:
- lavalamp
- thockin
title: Kubernetes Deprecation Policy
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
This document details the deprecation policy for various facets of the system.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Kubernetes is a large system with many components and many contributors. As
with any such software, the feature set naturally evolves over time, and
sometimes a feature may need to be removed. This could include an API, a flag,
@@ -425,4 +425,4 @@ leaders to find the best solutions for those specific cases, always bearing in
mind that Kubernetes is committed to being a stable system that, as much as
possible, never breaks users. Exceptions will always be announced in all
relevant release notes.
{{% /capture %}}