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-07-08 16:01:48 -04:00
parent 754c6b1a64 0ce44ec17f
commit 0ebc16c10c
421 changed files with 10650 additions and 8434 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/_index.md
-4
View File
@@ -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/).
content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
+2 -2
View File
@@ -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.
content/en/docs/tasks/administer-cluster/kms-provider.md
+90 -86
View File
@@ -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 -
```
content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+2 -2
View File
@@ -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)
content/en/docs/tasks/configure-pod-container/security-context.md
+10 -13
View File
@@ -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)
content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+1 -1
View File
@@ -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.
content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+1 -3
View File
@@ -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).
content/en/docs/tasks/example-task-template.md
-52
View File
@@ -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).
content/en/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
+78
View File
@@ -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).
content/en/docs/tasks/inject-data-application/podpreset.md
+3 -5
View File
@@ -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
```
content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: Manual Rotation of CA Certificates
min-kubernetes-server-version: v1.13
content_template: templates/task
content_type: task
---
<!-- overview -->
content/en/docs/tasks/tools/install-minikube.md
+1 -1
View File
@@ -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 >}}