resolving conflicts
This commit is contained in:
@@ -7,6 +7,7 @@ weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
Lower-level detail relevant to creating or administering a Kubernetes cluster.
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -40,14 +40,14 @@ Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes
|
||||
If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
|
||||
For example:
|
||||
```
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: prometheus
|
||||
rules:
|
||||
- nonResourceURLs:
|
||||
- "/metrics"
|
||||
verbs:
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: prometheus
|
||||
rules:
|
||||
- nonResourceURLs:
|
||||
- "/metrics"
|
||||
verbs:
|
||||
- get
|
||||
```
|
||||
|
||||
@@ -130,5 +130,4 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
|
||||
* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
|
||||
* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
|
||||
* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
|
||||
* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
|
||||
|
||||
@@ -126,25 +126,32 @@ spec:
|
||||
configMap:
|
||||
# Provide the name of the ConfigMap you want to mount.
|
||||
name: game-demo
|
||||
# An array of keys from the ConfigMap to create as files
|
||||
items:
|
||||
- key: "game.properties"
|
||||
path: "game.properties"
|
||||
- key: "user-interface.properties"
|
||||
path: "user-interface.properties"
|
||||
```
|
||||
|
||||
|
||||
A ConfigMap doesn't differentiate between single line property values and
|
||||
multi-line file-like values.
|
||||
What matters is how Pods and other objects consume those values.
|
||||
|
||||
For this example, defining a volume and mounting it inside the `demo`
|
||||
container as `/config` creates four files:
|
||||
container as `/config` creates two files,
|
||||
`/config/game.properties` and `/config/user-interface.properties`,
|
||||
even though there are four keys in the ConfigMap. This is because the Pod
|
||||
definition specifies an `items` array in the `volumes` section.
|
||||
If you omit the `items` array entirely, every key in the ConfigMap becomes
|
||||
a file with the same name as the key, and you get 4 files.
|
||||
|
||||
- `/config/player_initial_lives`
|
||||
- `/config/ui_properties_file_name`
|
||||
- `/config/game.properties`
|
||||
- `/config/user-interface.properties`
|
||||
## Using ConfigMaps
|
||||
|
||||
If you want to make sure that `/config` only contains files with a
|
||||
`.properties` extension, use two different ConfigMaps, and refer to both
|
||||
ConfigMaps in the `spec` for a Pod. The first ConfigMap defines
|
||||
`player_initial_lives` and `ui_properties_file_name`. The second
|
||||
ConfigMap defines the files that the kubelet places into `/config`.
|
||||
ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
|
||||
parts of the system, without being directly exposed to the Pod. For example,
|
||||
ConfigMaps can hold data that other parts of the system should use for configuration.
|
||||
|
||||
{{< note >}}
|
||||
The most common way to use ConfigMaps is to configure settings for
|
||||
@@ -157,12 +164,6 @@ or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
|
||||
adjust their behavior based on a ConfigMap.
|
||||
{{< /note >}}
|
||||
|
||||
## Using ConfigMaps
|
||||
|
||||
ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
|
||||
parts of the system, without being directly exposed to the Pod. For example,
|
||||
ConfigMaps can hold data that other parts of the system should use for configuration.
|
||||
|
||||
### Using ConfigMaps as files from a Pod
|
||||
|
||||
To consume a ConfigMap in a volume in a Pod:
|
||||
|
||||
@@ -227,7 +227,7 @@ locally-attached writeable devices or, sometimes, by RAM.
|
||||
|
||||
Pods use ephemeral local storage for scratch space, caching, and for logs.
|
||||
The kubelet can provide scratch space to Pods using local ephemeral storage to
|
||||
mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir)
|
||||
mount [`emptyDir`](/docs/concepts/storage/volumes/#emptydir)
|
||||
{{< glossary_tooltip term_id="volume" text="volumes" >}} into containers.
|
||||
|
||||
The kubelet also uses this kind of storage to hold
|
||||
@@ -657,7 +657,7 @@ Allocated resources:
|
||||
(Total limits may be over 100 percent, i.e., overcommitted.)
|
||||
CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
------------ ---------- --------------- -------------
|
||||
680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
|
||||
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
|
||||
```
|
||||
|
||||
In the preceding output, you can see that if a Pod requests more than 1120m
|
||||
@@ -758,5 +758,3 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
|
||||
* Read the [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API reference
|
||||
|
||||
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
|
||||
|
||||
|
||||
|
||||
@@ -87,7 +87,7 @@ spec:
|
||||
memory: 100Mi
|
||||
```
|
||||
|
||||
At admission time the RuntimeClass [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
|
||||
At admission time the RuntimeClass [admission controller](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined,
|
||||
the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
|
||||
to include an `overhead`.
|
||||
@@ -195,5 +195,3 @@ from source in the meantime.
|
||||
|
||||
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
|
||||
* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
|
||||
|
||||
@@ -6,6 +6,7 @@ reviewers:
|
||||
- erictune
|
||||
- thockin
|
||||
content_type: concept
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -65,7 +65,7 @@ When `imagePullPolicy` is defined without a specific value, it is also set to `A
|
||||
|
||||
## Multi-architecture Images with Manifests
|
||||
|
||||
As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
|
||||
As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
|
||||
|
||||
Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
|
||||
|
||||
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: Example Concept Template
|
||||
reviewers:
|
||||
- chenopis
|
||||
content_type: concept
|
||||
toc_hide: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
|
||||
{{< /note >}}
|
||||
|
||||
This page explains ...
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Understanding ...
|
||||
|
||||
Kubernetes provides ...
|
||||
|
||||
## Using ...
|
||||
|
||||
To use ...
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
**[Optional Section]**
|
||||
|
||||
* Learn more about [Writing a New Topic](/docs/home/contribute/style/write-new-topic/).
|
||||
* See [Page Content Types - Concept](/docs/home/contribute/style/page-concept-types/#concept).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -8,6 +8,7 @@ reviewers:
|
||||
- cheftako
|
||||
- chenopis
|
||||
content_type: concept
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -232,6 +232,6 @@ Here are some examples of device plugin implementations:
|
||||
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
|
||||
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
|
||||
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
|
||||
* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
|
||||
* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
|
||||
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ page will help you learn about scheduling.
|
||||
|
||||
## kube-scheduler
|
||||
|
||||
[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
is the default scheduler for Kubernetes and runs as part of the
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
|
||||
kube-scheduler is designed so that, if you want and need to, you can
|
||||
@@ -95,4 +95,3 @@ of the scheduler:
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
|
||||
* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
|
||||
provided and supported by VMware.
|
||||
* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
|
||||
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
|
||||
for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
|
||||
for the [F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/).
|
||||
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy.
|
||||
* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
|
||||
|
||||
@@ -91,7 +91,7 @@ Different [Ingress controller](/docs/concepts/services-networking/ingress-contro
|
||||
The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
|
||||
has all the information needed to configure a load balancer or proxy server. Most importantly, it
|
||||
contains a list of rules matched against all incoming requests. Ingress resource only supports rules
|
||||
for directing HTTP traffic.
|
||||
for directing HTTP(S) traffic.
|
||||
|
||||
### Ingress rules
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Managing storage is a distinct problem from managing compute instances. The Pers
|
||||
|
||||
A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
|
||||
|
||||
A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).
|
||||
A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany, see [AccessModes](#access-modes)).
|
||||
|
||||
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource.
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@ content_type: concept
|
||||
title: Contribute to Kubernetes docs
|
||||
linktitle: Contribute
|
||||
main_menu: true
|
||||
no_list: true
|
||||
weight: 80
|
||||
card:
|
||||
name: contribute
|
||||
@@ -23,8 +24,6 @@ Kubernetes documentation contributors:
|
||||
|
||||
Kubernetes documentation welcomes improvements from all contributors, new and experienced!
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Getting started
|
||||
@@ -74,5 +73,3 @@ SIG Docs communicates with different methods:
|
||||
- Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more.
|
||||
- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
|
||||
- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
|
||||
|
||||
|
||||
|
||||
@@ -97,10 +97,12 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
|
||||
|
||||
### Create a local clone and set the upstream
|
||||
|
||||
3. In a terminal window, clone your fork:
|
||||
3. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme):
|
||||
|
||||
```bash
|
||||
git clone git@github.com/<github_username>/website
|
||||
cd website
|
||||
git submodule update --init --recursive --depth 1
|
||||
```
|
||||
|
||||
4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
|
||||
@@ -261,18 +263,26 @@ The commands below use Docker as default container engine. Set the `CONTAINER_EN
|
||||
|
||||
Alternately, install and use the `hugo` command on your computer:
|
||||
|
||||
5. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
|
||||
1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
|
||||
|
||||
6. In a terminal, go to your Kubernetes website repository and start the Hugo server:
|
||||
2. If you have not updated your website repository, the `website/themes/docsy` directory is empty.
|
||||
The site cannot build without a local copy of the theme. To update the website theme, run:
|
||||
|
||||
```bash
|
||||
git submodule update --init --recursive --depth 1
|
||||
```
|
||||
|
||||
3. In a terminal, go to your Kubernetes website repository and start the Hugo server:
|
||||
|
||||
```bash
|
||||
cd <path_to_your_repo>/website
|
||||
hugo server
|
||||
hugo server --buildFuture
|
||||
```
|
||||
|
||||
7. In your browser’s address bar, enter `https://localhost:1313`.
|
||||
4. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
|
||||
changes and rebuilds the site as needed.
|
||||
|
||||
8. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
|
||||
5. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
|
||||
or close the terminal window.
|
||||
|
||||
{{% /tab %}}
|
||||
@@ -496,6 +506,6 @@ the templates with as much detail as possible when you file issues or PRs.
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
|
||||
- Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process.
|
||||
|
||||
|
||||
|
||||
@@ -9,10 +9,10 @@ weight: 10
|
||||
|
||||
This page contains guidelines for Kubernetes documentation.
|
||||
|
||||
If you have questions about what's allowed, join the #sig-docs channel in
|
||||
[Kubernetes Slack](http://slack.k8s.io/) and ask!
|
||||
If you have questions about what's allowed, join the #sig-docs channel in
|
||||
[Kubernetes Slack](http://slack.k8s.io/) and ask!
|
||||
|
||||
You can register for Kubernetes Slack at http://slack.k8s.io/.
|
||||
You can register for Kubernetes Slack at http://slack.k8s.io/.
|
||||
|
||||
For information on creating new content for the Kubernetes
|
||||
docs, follow the [style guide](/docs/contribute/style/style-guide).
|
||||
@@ -28,7 +28,7 @@ Source for the Kubernetes website, including the docs, resides in the
|
||||
|
||||
Located in the `kubernetes/website/content/<language_code>/docs` folder, the
|
||||
majority of Kubernetes documentation is specific to the [Kubernetes
|
||||
project](https://github.com/kubernetes/kubernetes).
|
||||
project](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
## What's allowed
|
||||
|
||||
@@ -41,12 +41,12 @@ Kubernetes docs allow content for third-party projects only when:
|
||||
### Third party content
|
||||
|
||||
Kubernetes documentation includes applied examples of projects in the Kubernetes project—projects that live in the [kubernetes](https://github.com/kubernetes) and
|
||||
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations.
|
||||
[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations.
|
||||
|
||||
Links to active content in the Kubernetes project are always allowed.
|
||||
Links to active content in the Kubernetes project are always allowed.
|
||||
|
||||
Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker),
|
||||
[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), and [logging](https://kubernetes.io/docs/concepts/cluster-administration/logging/).
|
||||
Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker),
|
||||
[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/), and [logging](/docs/concepts/cluster-administration/logging/).
|
||||
|
||||
Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function.
|
||||
|
||||
@@ -60,7 +60,7 @@ and grows stale more quickly.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
If you're a maintainer for a Kubernetes project and need help hosting your own docs,
|
||||
If you're a maintainer for a Kubernetes project and need help hosting your own docs,
|
||||
ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/).
|
||||
|
||||
{{< /note >}}
|
||||
@@ -75,5 +75,3 @@ If you have questions about allowed content, join the [Kubernetes Slack](http://
|
||||
|
||||
|
||||
* Read the [Style guide](/docs/contribute/style/style-guide).
|
||||
|
||||
|
||||
|
||||
@@ -28,9 +28,17 @@ Task | A task page shows how to do a single thing. The idea is to give readers a
|
||||
Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
|
||||
{{< /table >}}
|
||||
|
||||
### Creating a new page
|
||||
|
||||
Use a [content type](/docs/contribute/style/page-content-types/) for each new page
|
||||
that you write. Using page type helps ensure
|
||||
consistency among topics of a given type.
|
||||
that you write. The docs site provides templates or
|
||||
[Hugo archetypes](https://gohugo.io/content-management/archetypes/) to create
|
||||
new content pages. To create a new type of page, run `hugo new` with the path to the file
|
||||
you want to create. For example:
|
||||
|
||||
```
|
||||
hugo new docs/concepts/my-first-concept.md
|
||||
```
|
||||
|
||||
## Choosing a title and filename
|
||||
|
||||
|
||||
@@ -416,10 +416,8 @@ signed certificate.
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Read [Manage TLS Certificates in a Cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)
|
||||
* Read [Manage TLS Certificates in a Cluster](/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)
|
||||
* View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
|
||||
* 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)
|
||||
|
||||
|
||||
|
||||
@@ -134,6 +134,8 @@ different Kubernetes components.
|
||||
| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ServerSideApply` | `true` | Beta | 1.16 | |
|
||||
| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
|
||||
| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
|
||||
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
|
||||
| `ServiceTopology` | `false` | Alpha | 1.17 | |
|
||||
| `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | |
|
||||
@@ -441,7 +443,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
|
||||
to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
|
||||
- `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint.
|
||||
See [Support Device Monitoring](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md) for more details.
|
||||
See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md) for more details.
|
||||
- `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.
|
||||
- `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.
|
||||
@@ -481,11 +483,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller.
|
||||
- `SCTPSupport`: Enables the _SCTP_ `protocol` value in Pod, Service, Endpoints, EndpointSlice, and NetworkPolicy definitions.
|
||||
- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server.
|
||||
- `ServiceAccountIssuerDiscovery`: Enable OIDC discovery endpoints (issuer and JWKS URLs) for the service account issuer in the API server. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) for more details.
|
||||
- `ServiceAppProtocol`: Enables the `AppProtocol` field on Services and Endpoints.
|
||||
- `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
|
||||
- `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
|
||||
A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key or `node.kubernetes.io/exclude-from-external-load-balancers`.
|
||||
- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) for more details.
|
||||
- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details.
|
||||
- `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain Name(FQDN) as hostname of pod. See [Pod's `setHostnameAsFQDN` field](/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field).
|
||||
- `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet.
|
||||
- `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
|
||||
@@ -526,4 +529,3 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
|
||||
* The [deprecation policy](/docs/reference/using-api/deprecation-policy/) for Kubernetes explains
|
||||
the project's approach to removing features and components.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ and capacity. The scheduler needs to take into account individual and collective
|
||||
resource requirements, quality of service requirements, hardware/software/policy
|
||||
constraints, affinity and anti-affinity specifications, data locality, inter-workload
|
||||
interference, deadlines, and so on. Workload-specific requirements will be exposed
|
||||
through the API as necessary. See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/)
|
||||
through the API as necessary. See [scheduling](/docs/concepts/scheduling-eviction/)
|
||||
for more information about scheduling and the kube-scheduler component.
|
||||
|
||||
```
|
||||
@@ -511,8 +511,3 @@ kube-scheduler [flags]
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Endpoints
|
||||
id: endpoints
|
||||
date: 2020-04-23
|
||||
full_link:
|
||||
short_description: >
|
||||
Endpoints track the IP addresses of Pods with matching Service selectors.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
Endpoints track the IP addresses of Pods with matching {{< glossary_tooltip text="selectors" term_id="selector" >}}.
|
||||
|
||||
<!--more-->
|
||||
Endpoints can be configured manually for {{< glossary_tooltip text="Services" term_id="service" >}} without selectors specified.
|
||||
The {{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} resource provides a scalable and extensible alternative to Endpoints.
|
||||
@@ -6,15 +6,15 @@ full_link: /docs/concepts/storage/volumes/
|
||||
short_description: >
|
||||
A directory containing data, accessible to the containers in a pod.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
A directory containing data, accessible to the {{< glossary_tooltip text="containers" term_id="container" >}} in a {{< glossary_tooltip term_id="pod" >}}.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
A Kubernetes volume lives as long as the Pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data in the volume is preserved across container restarts.
|
||||
|
||||
See [storage](https://kubernetes.io/docs/concepts/storage/) for more information.
|
||||
See [storage](/docs/concepts/storage/) for more information.
|
||||
|
||||
@@ -706,9 +706,9 @@ Resource versions are strings that identify the server's internal version of an
|
||||
|
||||
Clients find resource versions in resources, including the resources in watch events, and list responses returned from the server:
|
||||
|
||||
[v1.meta/ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
|
||||
[v1.meta/ObjectMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
|
||||
|
||||
[v1.meta/ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
|
||||
[v1.meta/ListMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
|
||||
|
||||
### The ResourceVersion Parameter
|
||||
|
||||
|
||||
@@ -20,35 +20,20 @@ card:
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This section covers different options to set up and run Kubernetes.
|
||||
|
||||
Different Kubernetes solutions meet different requirements: ease of maintenance, security, control, available resources, and expertise required to operate and manage a cluster.
|
||||
|
||||
You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. You can also create custom solutions across a wide range of cloud providers, or bare metal environments.
|
||||
|
||||
More simply, you can create a Kubernetes cluster in learning and production environments.
|
||||
|
||||
This section lists the different ways to set up and run Kubernetes.
|
||||
When you install Kubernetes, choose an installation type based on: ease of maintenance, security,
|
||||
control, available resources, and expertise required to operate and manage a cluster.
|
||||
|
||||
You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. There are also custom solutions across a wide range of cloud providers, or bare metal environments.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Learning environment
|
||||
|
||||
If you're learning Kubernetes, use the Docker-based solutions: tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine.
|
||||
|
||||
{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}}
|
||||
|
||||
|Community |Ecosystem |
|
||||
| ------------ | -------- |
|
||||
| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
|
||||
| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)|
|
||||
| | [MicroK8s](https://microk8s.io/)|
|
||||
|
||||
If you're learning Kubernetes, use the tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine.
|
||||
|
||||
## Production environment
|
||||
|
||||
When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider.
|
||||
|
||||
[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers.
|
||||
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ kops is an automated provisioning system:
|
||||
|
||||
* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.
|
||||
|
||||
* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them.
|
||||
* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).
|
||||
|
||||
|
||||
|
||||
|
||||
+2
-4
@@ -42,7 +42,7 @@ To follow this guide, you need:
|
||||
You also need to use a version of `kubeadm` that can deploy the version
|
||||
of Kubernetes that you want to use in your new cluster.
|
||||
|
||||
[Kubernetes' version and version skew support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall.
|
||||
[Kubernetes' version and version skew support policy](/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall.
|
||||
Check that policy to learn about what versions of Kubernetes and `kubeadm`
|
||||
are supported. This page is written for Kubernetes {{< param "version" >}}.
|
||||
|
||||
@@ -287,7 +287,7 @@ Several external projects provide Kubernetes Pod networks using CNI, some of whi
|
||||
support [Network Policy](/docs/concepts/services-networking/networkpolicies/).
|
||||
|
||||
See the list of available
|
||||
[networking and network policy add-ons](https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
|
||||
[networking and network policy add-ons](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
|
||||
|
||||
You can install a Pod network add-on with the following command on the
|
||||
control-plane node or a node that has the kubeconfig credentials:
|
||||
@@ -644,5 +644,3 @@ supports your chosen platform.
|
||||
## Troubleshooting {#troubleshooting}
|
||||
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
|
||||
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ sudo sysctl --system
|
||||
|
||||
Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`.
|
||||
|
||||
For more details please see the [Network Plugin Requirements](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page.
|
||||
For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page.
|
||||
|
||||
## Check required ports
|
||||
|
||||
@@ -218,7 +218,7 @@ sudo systemctl enable --now kubelet
|
||||
You have to do this until SELinux support is improved in the kubelet.
|
||||
|
||||
- You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Fedora CoreOS" %}}
|
||||
Install CNI plugins (required for most pod network):
|
||||
@@ -310,4 +310,3 @@ If you are running into difficulties with kubeadm, please consult our [troublesh
|
||||
|
||||
|
||||
* [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
|
||||
|
||||
@@ -80,13 +80,13 @@ Server-side Apply was promoted to Beta in 1.16, but is now introducing a second
|
||||
|
||||
### Extending Ingress with and replacing a deprecated annotation with IngressClass
|
||||
|
||||
In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types.
|
||||
In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types.
|
||||
|
||||
The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation.
|
||||
|
||||
### SIG CLI introduces kubectl debug
|
||||
|
||||
SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
|
||||
SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable. This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
|
||||
|
||||
### Introducing Windows CSI support alpha for Kubernetes
|
||||
|
||||
@@ -126,7 +126,7 @@ No Known Issues Reported
|
||||
|
||||
#### kubectl:
|
||||
- `kubectl` and k8s.io/client-go no longer default to a server address of `http://localhost:8080`. If you own one of these legacy clusters, you are *strongly* encouraged to secure your server. If you cannot secure your server, you can set the `$KUBERNETES_MASTER` environment variable to `http://localhost:8080` to continue defaulting the server address. `kubectl` users can also set the server address using the `--server` flag, or in a kubeconfig file specified via `--kubeconfig` or `$KUBECONFIG`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
|
||||
- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods.
|
||||
- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods.
|
||||
([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, CLI and Testing]
|
||||
- The deprecated command `kubectl rolling-update` has been removed ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing]
|
||||
|
||||
@@ -193,13 +193,13 @@ No Known Issues Reported
|
||||
- node_memory_working_set_bytes --> node_memory_working_set_bytes
|
||||
- container_cpu_usage_seconds_total --> container_cpu_usage_seconds
|
||||
- container_memory_working_set_bytes --> container_memory_working_set_bytes
|
||||
- scrape_error --> scrape_error
|
||||
- scrape_error --> scrape_error
|
||||
([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) [SIG Node]
|
||||
- In a future release, kubelet will no longer create the CSI NodePublishVolume target directory, in accordance with the CSI specification. CSI drivers may need to be updated accordingly to properly create and process the target path. ([#75535](https://github.com/kubernetes/kubernetes/issues/75535)) [SIG Storage]
|
||||
|
||||
#### kube-proxy:
|
||||
- `--healthz-port` and `--metrics-port` flags are deprecated, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
|
||||
- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
|
||||
- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
|
||||
|
||||
#### kubeadm:
|
||||
- command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
|
||||
@@ -245,7 +245,7 @@ No Known Issues Reported
|
||||
- The alpha feature `ServiceAccountIssuerDiscovery` enables publishing OIDC discovery information and service account token verification keys at `/.well-known/openid-configuration` and `/openid/v1/jwks` endpoints by API servers configured to issue service account tokens. ([#80724](https://github.com/kubernetes/kubernetes/pull/80724), [@cceckman](https://github.com/cceckman)) [SIG API Machinery, Auth, Cluster Lifecycle and Testing]
|
||||
- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing]
|
||||
- CustomResourceDefinition schemas that use `x-kubernetes-list-type: map` or `x-kubernetes-list-type: set` now enable validation that the list items in the corresponding custom resources are unique. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
|
||||
|
||||
|
||||
#### Configuration file changes:
|
||||
|
||||
#### kube-apiserver:
|
||||
@@ -257,7 +257,7 @@ No Known Issues Reported
|
||||
- Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.schedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing]
|
||||
- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
|
||||
- The PostFilter of scheduler framework is renamed to PreScore in kubescheduler.config.k8s.io/v1alpha2. ([#87751](https://github.com/kubernetes/kubernetes/pull/87751), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling and Testing]
|
||||
|
||||
|
||||
#### kube-proxy:
|
||||
- Added kube-proxy flags `--ipvs-tcp-timeout`, `--ipvs-tcpfin-timeout`, `--ipvs-udp-timeout` to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cluster Lifecycle and Network]
|
||||
- Added optional `--detect-local-mode` flag to kube-proxy. Valid values are "ClusterCIDR" (default matching previous behavior) and "NodeCIDR" ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling]
|
||||
@@ -689,8 +689,8 @@ filename | sha512 hash
|
||||
|
||||
- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
|
||||
- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
|
||||
- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver.
|
||||
After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect.
|
||||
- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver.
|
||||
After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect.
|
||||
The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.
|
||||
Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
|
||||
- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
|
||||
@@ -739,7 +739,7 @@ filename | sha512 hash
|
||||
- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability]
|
||||
- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
|
||||
- Specifying PluginConfig for the same plugin more than once fails scheduler startup.
|
||||
|
||||
|
||||
Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
|
||||
- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI]
|
||||
- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing]
|
||||
@@ -806,18 +806,18 @@ filename | sha512 hash
|
||||
If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node]
|
||||
|
||||
- Yes.
|
||||
|
||||
|
||||
Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster.
|
||||
|
||||
|
||||
Changes in Pull Request:
|
||||
|
||||
|
||||
1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources.
|
||||
2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature.
|
||||
3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature.
|
||||
4. Related unit tests.
|
||||
|
||||
|
||||
None.
|
||||
|
||||
|
||||
User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider]
|
||||
|
||||
## Changes by Kind
|
||||
@@ -833,8 +833,8 @@ filename | sha512 hash
|
||||
- Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage]
|
||||
- AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
|
||||
- Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
|
||||
- Introduces optional --detect-local flag to kube-proxy.
|
||||
Currently the only supported value is "cluster-cidr",
|
||||
- Introduces optional --detect-local flag to kube-proxy.
|
||||
Currently the only supported value is "cluster-cidr",
|
||||
which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling]
|
||||
- Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing]
|
||||
- Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows]
|
||||
@@ -1048,9 +1048,9 @@ filename | sha512 hash
|
||||
|
||||
- aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery]
|
||||
- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form
|
||||
|
||||
|
||||
Throttling request took 1.50705208s, request: GET:<URL>
|
||||
|
||||
|
||||
The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery]
|
||||
- kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
|
||||
- disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
|
||||
|
||||
@@ -146,3 +146,16 @@ Running a cluster with `kubelet` instances that are persistently two minor versi
|
||||
* they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
|
||||
* it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
|
||||
{{</ warning >}}
|
||||
|
||||
### kube-proxy
|
||||
|
||||
* `kube-proxy` must be the same minor version as `kubelet` on the node.
|
||||
* `kube-proxy` must not be newer than `kube-apiserver`.
|
||||
* `kube-proxy` must be at most two minor versions older than `kube-apiserver.`
|
||||
|
||||
Example:
|
||||
|
||||
If `kube-proxy` version is **{{< skew latestVersion >}}**:
|
||||
|
||||
* `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**.
|
||||
* `kube-apiserver` version must be between **{{ skew oldestMinorVersion }}** and **{{ skew latestVersion }}**, inclusive.
|
||||
|
||||
@@ -11,9 +11,5 @@ This section of the Kubernetes documentation contains pages that
|
||||
show how to do individual tasks. A task page shows how to do a
|
||||
single thing, typically by giving a short sequence of steps.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
If you would like to write a task page, see
|
||||
[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
|
||||
|
||||
@@ -17,7 +17,7 @@ DNS resolution process in your cluster.
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
Your cluster must be running the CoreDNS add-on.
|
||||
[Migrating to CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/#migrating-to-coredns)
|
||||
[Migrating to CoreDNS](/docs/tasks/administer-cluster/coredns/#migrating-to-coredns)
|
||||
explains how to use `kubeadm` to migrate from `kube-dns`.
|
||||
|
||||
{{% version-check %}}
|
||||
@@ -117,7 +117,7 @@ You can modify the default CoreDNS behavior by modifying the ConfigMap.
|
||||
|
||||
### Configuration of Stub-domain and upstream nameserver using CoreDNS
|
||||
|
||||
CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/).
|
||||
CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/).
|
||||
|
||||
#### Example
|
||||
If a cluster operator has a [Consul](https://www.consul.io/) domain server located at 10.150.0.1, and all Consul names have the suffix .consul.local. To configure it in CoreDNS, the cluster administrator creates the following stanza in the CoreDNS ConfigMap.
|
||||
|
||||
@@ -7,10 +7,8 @@ content_type: task
|
||||
<!-- overview -->
|
||||
This page shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* Kubernetes version 1.10.0 or later is required
|
||||
@@ -19,8 +17,6 @@ This page shows how to configure a Key Management Service (KMS) provider and plu
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS
|
||||
@@ -30,10 +26,12 @@ plugin. The KMS plugin, which is implemented as a gRPC server and deployed on th
|
||||
|
||||
To configure a KMS provider on the API server, include a provider of type ```kms``` in the providers array in the encryption configuration file and set the following properties:
|
||||
|
||||
* `name`: Display name of the KMS plugin.
|
||||
* `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket.
|
||||
* `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap.
|
||||
* `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds).
|
||||
* `name`: Display name of the KMS plugin.
|
||||
* `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket.
|
||||
* `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear.
|
||||
When cached, DEKs can be used without another call to the KMS;
|
||||
whereas DEKs that are not cached require a call to the KMS to unwrap.
|
||||
* `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds).
|
||||
|
||||
See [Understanding the encryption at rest configuration.](/docs/tasks/administer-cluster/encrypt-data)
|
||||
|
||||
@@ -57,17 +55,18 @@ Then use the functions and data structures in the stub file to develop the serve
|
||||
|
||||
* kms plugin version: `v1beta1`
|
||||
|
||||
In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version
|
||||
In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version.
|
||||
|
||||
* message version: `v1beta1`
|
||||
|
||||
All messages from KMS provider have the version field set to current version v1beta1
|
||||
All messages from KMS provider have the version field set to current version v1beta1.
|
||||
|
||||
* protocol: UNIX domain socket (`unix`)
|
||||
|
||||
The gRPC server should listen at UNIX domain socket
|
||||
The gRPC server should listen at UNIX domain socket.
|
||||
|
||||
### Integrating a KMS plugin with the remote KMS
|
||||
|
||||
The KMS plugin can communicate with the remote KMS using any protocol supported by the KMS.
|
||||
All configuration data, including authentication credentials the KMS plugin uses to communicate with the remote KMS,
|
||||
are stored and managed by the KMS plugin independently. The KMS plugin can encode the ciphertext with additional metadata that may be required before sending it to the KMS for decryption.
|
||||
@@ -80,108 +79,113 @@ To encrypt the data:
|
||||
|
||||
1. Create a new encryption configuration file using the appropriate properties for the `kms` provider:
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- kms:
|
||||
name: myKmsPlugin
|
||||
endpoint: unix:///tmp/socketfile.sock
|
||||
cachesize: 100
|
||||
timeout: 3s
|
||||
- identity: {}
|
||||
```
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- kms:
|
||||
name: myKmsPlugin
|
||||
endpoint: unix:///tmp/socketfile.sock
|
||||
cachesize: 100
|
||||
timeout: 3s
|
||||
- identity: {}
|
||||
```
|
||||
|
||||
2. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file.
|
||||
3. Restart your API server.
|
||||
|
||||
Note:
|
||||
The alpha version of the encryption feature prior to 1.13 required a config file with
|
||||
`kind: EncryptionConfig` and `apiVersion: v1`, and used the `--experimental-encryption-provider-config` flag.
|
||||
1. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file.
|
||||
1. Restart your API server.
|
||||
|
||||
## Verifying that the data is encrypted
|
||||
Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To verify, you can use the etcdctl command line program to retrieve the contents of your secret.
|
||||
|
||||
Data is encrypted when written to etcd. After restarting your `kube-apiserver`,
|
||||
any newly created or updated secret should be encrypted when stored. To verify,
|
||||
you can use the `etcdctl` command line program to retrieve the contents of your secret.
|
||||
|
||||
1. Create a new secret called secret1 in the default namespace:
|
||||
```
|
||||
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
|
||||
```
|
||||
2. Using the etcdctl command line, read that secret out of etcd:
|
||||
```
|
||||
ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
|
||||
```
|
||||
where `[...]` must be the additional arguments for connecting to the etcd server.
|
||||
```
|
||||
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
|
||||
```
|
||||
1. Using the etcdctl command line, read that secret out of etcd:
|
||||
```
|
||||
ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
|
||||
```
|
||||
where `[...]` must be the additional arguments for connecting to the etcd server.
|
||||
|
||||
3. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data.
|
||||
1. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data.
|
||||
|
||||
4. Verify that the secret is correctly decrypted when retrieved via the API:
|
||||
```
|
||||
kubectl describe secret secret1 -n default
|
||||
```
|
||||
should match `mykey: mydata`
|
||||
1. Verify that the secret is correctly decrypted when retrieved via the API:
|
||||
```
|
||||
kubectl describe secret secret1 -n default
|
||||
```
|
||||
should match `mykey: mydata`
|
||||
|
||||
## Ensuring all secrets are encrypted
|
||||
|
||||
Because secrets are encrypted on write, performing an update on a secret encrypts that content.
|
||||
|
||||
The following command reads all secrets and then updates them to apply server side encryption. If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
|
||||
The following command reads all secrets and then updates them to apply server side encryption.
|
||||
If an error occurs due to a conflicting write, retry the command.
|
||||
For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
|
||||
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
|
||||
```
|
||||
|
||||
## Switching from a local encryption provider to the KMS provider
|
||||
|
||||
To switch from a local encryption provider to the `kms` provider and re-encrypt all of the secrets:
|
||||
|
||||
1. Add the `kms` provider as the first entry in the configuration file as shown in the following example.
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- kms:
|
||||
name : myKmsPlugin
|
||||
endpoint: unix:///tmp/socketfile.sock
|
||||
cachesize: 100
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: <BASE 64 ENCODED SECRET>
|
||||
```
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- kms:
|
||||
name : myKmsPlugin
|
||||
endpoint: unix:///tmp/socketfile.sock
|
||||
cachesize: 100
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: <BASE 64 ENCODED SECRET>
|
||||
```
|
||||
|
||||
2. Restart all kube-apiserver processes.
|
||||
1. Restart all kube-apiserver processes.
|
||||
|
||||
3. Run the following command to force all secrets to be re-encrypted using the `kms` provider.
|
||||
1. Run the following command to force all secrets to be re-encrypted using the `kms` provider.
|
||||
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json| kubectl replace -f -
|
||||
```
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json| kubectl replace -f -
|
||||
```
|
||||
|
||||
## Disabling encryption at rest
|
||||
|
||||
To disable encryption at rest:
|
||||
|
||||
1. Place the `identity` provider as the first entry in the configuration file:
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- identity: {}
|
||||
- kms:
|
||||
name : myKmsPlugin
|
||||
endpoint: unix:///tmp/socketfile.sock
|
||||
cachesize: 100
|
||||
```
|
||||
2. Restart all kube-apiserver processes.
|
||||
3. Run the following command to force all secrets to be decrypted.
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
|
||||
```
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- identity: {}
|
||||
- kms:
|
||||
name : myKmsPlugin
|
||||
endpoint: unix:///tmp/socketfile.sock
|
||||
cachesize: 100
|
||||
```
|
||||
1. Restart all kube-apiserver processes.
|
||||
1. Run the following command to force all secrets to be decrypted.
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
|
||||
```
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
|
||||
or v1.17; other combinations
|
||||
[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
|
||||
|
||||
Some of the examples use the commandline tool
|
||||
Some of the examples use the command line tool
|
||||
[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task,
|
||||
because there are manual alternatives.
|
||||
|
||||
@@ -380,4 +380,4 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
|
||||
|
||||
- For more information on configuring the kubelet via a configuration file, see
|
||||
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
|
||||
- See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
|
||||
- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
|
||||
|
||||
@@ -30,8 +30,8 @@ a Pod or Container. Security context settings include, but are not limited to:
|
||||
|
||||
* readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
|
||||
|
||||
The above bullets are not a complete set of security context settings -- please see
|
||||
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
The above bullets are not a complete set of security context settings -- please see
|
||||
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
for a comprehensive list.
|
||||
|
||||
For more information about security mechanisms in Linux, see
|
||||
@@ -59,11 +59,11 @@ Here is a configuration file for a Pod that has a `securityContext` and an `empt
|
||||
{{< codenew file="pods/security/security-context.yaml" >}}
|
||||
|
||||
In the configuration file, the `runAsUser` field specifies that for any Containers in
|
||||
the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for
|
||||
the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for
|
||||
all processes within any containers of the Pod. If this field is omitted, the primary group ID of the containers
|
||||
will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified.
|
||||
Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000.
|
||||
The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000.
|
||||
will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified.
|
||||
Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000.
|
||||
The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000.
|
||||
|
||||
Create the Pod:
|
||||
|
||||
@@ -138,7 +138,7 @@ $ id
|
||||
uid=1000 gid=3000 groups=2000
|
||||
```
|
||||
You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was omitted the gid would
|
||||
remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
|
||||
remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
|
||||
the required group permissions for root(0) group.
|
||||
|
||||
Exit your shell:
|
||||
@@ -180,9 +180,9 @@ This is an alpha feature. To use it, enable the [feature gate](/docs/reference/c
|
||||
|
||||
{{< note >}}
|
||||
This field has no effect on ephemeral volume types such as
|
||||
[`secret`](https://kubernetes.io/docs/concepts/storage/volumes/#secret),
|
||||
[`configMap`](https://kubernetes.io/docs/concepts/storage/volumes/#configmap),
|
||||
and [`emptydir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir).
|
||||
[`secret`](/docs/concepts/storage/volumes/#secret),
|
||||
[`configMap`](/docs/concepts/storage/volumes/#configmap),
|
||||
and [`emptydir`](/docs/concepts/storage/volumes/#emptydir).
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -423,6 +423,3 @@ kubectl delete pod security-context-demo-4
|
||||
* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
|
||||
* [AllowPrivilegeEscalation design
|
||||
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -78,7 +78,7 @@ only the termination message:
|
||||
## Customizing the termination message
|
||||
|
||||
Kubernetes retrieves termination messages from the termination message file
|
||||
specified in the `terminationMessagePath` field of a Container, which as a default
|
||||
specified in the `terminationMessagePath` field of a Container, which has a default
|
||||
value of `/dev/termination-log`. By customizing this field, you can tell Kubernetes
|
||||
to use a different file. Kubernetes use the contents from the specified file to
|
||||
populate the Container's status message on both success and failure.
|
||||
|
||||
@@ -41,7 +41,7 @@ The API requires metrics server to be deployed in the cluster. Otherwise it will
|
||||
|
||||
### CPU
|
||||
|
||||
CPU is reported as the average usage, in [CPU cores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation.
|
||||
CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation.
|
||||
|
||||
### Memory
|
||||
|
||||
@@ -60,5 +60,3 @@ Metrics Server is registered with the main API server through
|
||||
[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/).
|
||||
|
||||
Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
|
||||
|
||||
|
||||
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
title: Example Task Template
|
||||
reviewers:
|
||||
- chenopis
|
||||
content_type: task
|
||||
toc_hide: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
Be sure to also [create an entry in the table of contents](/docs/contribute/style/write-new-topic/#placing-your-topic-in-the-table-of-contents) for your new document.
|
||||
{{< /note >}}
|
||||
|
||||
This page shows how to ...
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* Do this.
|
||||
* Do this too.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Doing ...
|
||||
|
||||
1. Do this.
|
||||
1. Do this next. Possibly read this [related explanation](#).
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Understanding ...
|
||||
**[Optional Section]**
|
||||
|
||||
Here's an interesting thing to know about the steps you just did.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
**[Optional Section]**
|
||||
|
||||
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
|
||||
* Learn about [Page Content Types - Task](/docs/home/contribute/style/page-content-types/#task).
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: Define Dependent Environment Variables
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to define dependent environment variables for a container
|
||||
in a Kubernetes Pod.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Define an environment dependent variable for a container
|
||||
|
||||
When you create a Pod, you can set dependent environment variables for the containers that run in the Pod. To set dependent environment variables, you can use $(VAR_NAME) in the `value` of `env` in the configuration file.
|
||||
|
||||
In this exercise, you create a Pod that runs one container. The configuration
|
||||
file for the Pod defines an dependent environment variable with common usage defined. Here is the configuration manifest for the
|
||||
Pod:
|
||||
|
||||
{{< codenew file="pods/inject/dependent-envars.yaml" >}}
|
||||
|
||||
1. Create a Pod based on that manifest:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
|
||||
```
|
||||
```
|
||||
pod/dependent-envars-demo created
|
||||
```
|
||||
|
||||
2. List the running Pods:
|
||||
|
||||
```shell
|
||||
kubectl get pods dependent-envars-demo
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
dependent-envars-demo 1/1 Running 0 9s
|
||||
```
|
||||
|
||||
3. Check the logs for the container running in your Pod:
|
||||
|
||||
```shell
|
||||
kubectl logs pod/dependent-envars-demo
|
||||
```
|
||||
```
|
||||
|
||||
UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
|
||||
SERVICE_ADDRESS=https://172.17.0.1:80
|
||||
ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
|
||||
```
|
||||
|
||||
As shown above, you have defined the correct dependency reference of `SERVICE_ADDRESS`, bad dependency reference of `UNCHANGED_REFERENCE` and skip dependent references of `ESCAPED_REFERENCE`.
|
||||
|
||||
When an environment variable is already defined when being referenced,
|
||||
the reference can be correctly resolved, such as in the `SERVICE_ADDRESS` case.
|
||||
|
||||
When the environment variable is undefined or only includes some variables, the undefined environment variable is treated as a normal string, such as `UNCHANGED_REFERENCE`. Note that incorrectly parsed environment variables, in general, will not block the container from starting.
|
||||
|
||||
The `$(VAR_NAME)` syntax can be escaped with a double `$`, ie: `$$(VAR_NAME)`.
|
||||
Escaped references are never expanded, regardless of whether the referenced variable
|
||||
is defined or not. This can be seen from the `ESCAPED_REFERENCE` case above.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
|
||||
|
||||
@@ -140,7 +140,7 @@ verify that the preset has been applied.
|
||||
|
||||
## ReplicaSet with Pod spec example
|
||||
|
||||
This is an example to show that only Pod specs are modified by Pod presets. Other workload types
|
||||
This is an example to show that only Pod specs are modified by Pod presets. Other workload types
|
||||
like ReplicaSets or Deployments are unaffected.
|
||||
|
||||
Here is the manifest for the PodPreset for this example:
|
||||
@@ -290,7 +290,7 @@ kubectl get pod website -o yaml
|
||||
You can see there is no preset annotation (`podpreset.admission.kubernetes.io`). Seeing no annotation tells you that no preset has not been applied to the Pod.
|
||||
|
||||
However, the
|
||||
[PodPreset admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podpreset)
|
||||
[PodPreset admission controller](/docs/reference/access-authn-authz/admission-controllers/#podpreset)
|
||||
logs a warning containing details of the conflict.
|
||||
You can view the warning using `kubectl`:
|
||||
|
||||
@@ -301,7 +301,7 @@ kubectl -n kube-system logs -l=component=kube-apiserver
|
||||
The output should look similar to:
|
||||
|
||||
```
|
||||
W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache:
|
||||
W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache:
|
||||
v1.VolumeMount{Name:"other-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil), SubPathExpr:""}
|
||||
does not match
|
||||
core.VolumeMount{Name:"cache-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*core.MountPropagationMode)(nil), SubPathExpr:""}
|
||||
@@ -321,5 +321,3 @@ The output shows that the PodPreset was deleted:
|
||||
```
|
||||
podpreset "allow-database" deleted
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Manual Rotation of CA Certificates
|
||||
min-kubernetes-server-version: v1.13
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -206,7 +206,7 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru
|
||||
|
||||
{{< note >}}
|
||||
|
||||
For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
|
||||
For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -235,7 +235,6 @@ link target in parentheses. [Link to Kubernetes.io](https://kubernetes.io/) or
|
||||
You can also use HTML, but it is not preferred.
|
||||
<a href="https://kubernetes.io/">Link to Kubernetes.io</a>
|
||||
|
||||
|
||||
## Images
|
||||
|
||||
To format an image, use similar syntax to [links](#links), but add a leading `!`
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: Tutorials
|
||||
main_menu: true
|
||||
no_list: true
|
||||
weight: 60
|
||||
content_type: concept
|
||||
---
|
||||
@@ -14,8 +15,6 @@ each of which has a sequence of steps.
|
||||
Before walking through each tutorial, you may want to bookmark the
|
||||
[Standardized Glossary](/docs/reference/glossary/) page for later references.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Basics
|
||||
@@ -64,13 +63,8 @@ Before walking through each tutorial, you may want to bookmark the
|
||||
|
||||
* [Using Source IP](/docs/tutorials/services/source-ip/)
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
If you would like to write a tutorial, see
|
||||
[Content Page Types](/docs/contribute/style/page-content-types/)
|
||||
for information about the tutorial page type.
|
||||
|
||||
|
||||
|
||||
@@ -447,6 +447,4 @@ kubectl delete deployment source-ip-app
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [connecting applications via services](/docs/concepts/services-networking/connect-applications-service/)
|
||||
* Read how to [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
|
||||
|
||||
|
||||
* Read how to [Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
|
||||
|
||||
Reference in New Issue
Block a user