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

Merge master into dev-1.21

Browse Source
This commit is contained in:
Rey Lejano
2021-01-19 12:39:27 -08:00
parent 14d97e0177 a5630c5dde
commit abef338c9d
144 changed files with 1849 additions and 2419 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/cluster-administration/certificates.md
+3 -3
View File
@@ -130,11 +130,11 @@ Finally, add the same parameters into the API server start parameters.
Note that you may need to adapt the sample commands based on the hardware
architecture and cfssl version you are using.
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 -o cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssljson_1.4.1_linux_amd64 -o cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl-certinfo_1.4.1_linux_amd64 -o cfssl-certinfo
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
1. Create a directory to hold the artifacts and initialize cfssl:
content/en/docs/concepts/cluster-administration/system-metrics.md
-1
View File
@@ -156,5 +156,4 @@ endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1
## {{% heading "whatsnext" %}}
* 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](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
content/en/docs/concepts/configuration/secret.md
+10 -1
View File
@@ -24,6 +24,16 @@ a password, a token, or a key. Such information might otherwise be put in a
Pod specification or in an image. Users can create Secrets and the system
also creates some Secrets.
{{< caution >}}
Kubernetes Secrets are, by default, stored as unencrypted base64-encoded
strings. By default they can be retrieved - as plain text - by anyone with API
access, or anyone with access to Kubernetes' underlying data store, etcd. In
order to safely use Secrets, we recommend you (at a minimum):
1. [Enable Encryption at Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) for Secrets.
2. [Enable RBAC rules that restrict reading and writing the Secret](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod.
{{< /caution >}}
<!-- body -->
## Overview of Secrets
@@ -795,7 +805,6 @@ See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-contai
Manually created secrets (for example, one containing a token for accessing a GitHub account)
can be automatically attached to pods based on their service account.
See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset/) for a detailed explanation of that process.
## Details
content/en/docs/concepts/services-networking/ingress-controllers.md
+2 -1
View File
@@ -26,6 +26,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
* [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress
controller.
* [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller.
* [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provides L4-L7 load-balancing using [VMware NSX Advanced Load Balancer](https://avinetworks.com/).
* The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with
Citrix Application Delivery Controller.
@@ -42,7 +43,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
is an [Istio](https://istio.io/) based ingress controller.
* The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)
is an ingress controller driving [Kong Gateway](https://konghq.com/kong/).
* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)
works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy).
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy.
* The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an
content/en/docs/concepts/services-networking/service.md
+2 -2
View File
@@ -134,7 +134,7 @@ For example:
* You want to point your Service to a Service in a different
{{< glossary_tooltip term_id="namespace" >}} or on another cluster.
* You are migrating a workload to Kubernetes. While evaluating the approach,
you run only a proportion of your backends in Kubernetes.
you run only a portion of your backends in Kubernetes.
In any of these scenarios you can define a Service _without_ a Pod selector.
For example:
@@ -238,7 +238,7 @@ There are a few reasons for using proxying for Services:
### User space proxy mode {#proxy-mode-userspace}
In this mode, kube-proxy watches the Kubernetes master for the addition and
In this mode, kube-proxy watches the Kubernetes control plane for the addition and
removal of Service and Endpoint objects. For each Service it opens a
port (randomly chosen) on the local node. Any connections to this "proxy port"
are proxied to one of the Service's backend Pods (as reported via
content/en/docs/concepts/storage/persistent-volumes.md
+1 -1
View File
@@ -231,7 +231,7 @@ the following types of volumes:
* Azure Disk
* Portworx
* FlexVolumes
* CSI
* {{< glossary_tooltip text="CSI" term_id="csi" >}}
You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true.
content/en/docs/reference/access-authn-authz/admission-controllers.md
-7
View File
@@ -669,13 +669,6 @@ allowVolumeExpansion: true
For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
### PodPreset {#podpreset}
This admission controller injects a pod with the fields specified in a matching PodPreset.
See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and
[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset)
for more information.
### PodSecurityPolicy {#podsecuritypolicy}
This admission controller acts on creation and modification of the pod and determines if it should be admitted
content/en/docs/reference/access-authn-authz/rbac.md
+1
View File
@@ -86,6 +86,7 @@ Because ClusterRoles are cluster-scoped, you can also use them to grant access t
* cluster-scoped resources (like {{< glossary_tooltip text="nodes" term_id="node" >}})
* non-resource endpoints (like `/healthz`)
* namespaced resources (like Pods), across all namespaces
For example: you can use a ClusterRole to allow a particular user to run
`kubectl get pods --all-namespaces`
content/en/docs/reference/glossary/podpreset.md
-18
View File
@@ -1,18 +0,0 @@
---
title: PodPreset
id: podpreset
date: 2018-04-12
full_link:
short_description: >
An API object that injects information such as secrets, volume mounts, and environment variables into pods at creation time.
aka:
tags:
- operation
---
An API object that injects information such as secrets, volume mounts, and environment variables into {{< glossary_tooltip text="Pods" term_id="pod" >}} at creation time.
<!--more-->
This object chooses the Pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration.
content/en/docs/setup/production-environment/container-runtimes.md
+26 -11
View File
@@ -210,7 +210,7 @@ sudo yum update -y && sudo yum install -y containerd.io
```shell
## Configure containerd
sudo mkdir -p /etc/containerd
sudo containerd config default > /etc/containerd/config.toml
sudo containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
@@ -268,13 +268,12 @@ Use the following commands to install CRI-O on your system:
{{< note >}}
The CRI-O major and minor versions must match the Kubernetes major and minor versions.
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o).
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes).
{{< /note >}}
Install and configure prerequisites:
```shell
# Create the .conf file to load the modules at bootup
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
@@ -307,9 +306,9 @@ to the appropriate value from the following table:
<br />
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
You can pin your installation to a specific release.
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
<br />
Then run
@@ -343,9 +342,9 @@ To install on the following operating systems, set the environment variable `OS`
<br />
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
You can pin your installation to a specific release.
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
<br />
Then run
@@ -377,9 +376,9 @@ To install on the following operating systems, set the environment variable `OS`
<br />
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
You can pin your installation to a specific release.
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
<br />
Then run
@@ -400,7 +399,7 @@ sudo zypper install cri-o
{{% tab name="Fedora" %}}
Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, `VERSION=1.20`.
You can find available versions with:
```shell
@@ -424,10 +423,26 @@ sudo systemctl daemon-reload
sudo systemctl start crio
```
Refer to the [CRI-O installation guide](https://github.com/kubernetes-sigs/cri-o#getting-started)
Refer to the [CRI-O installation guide](https://github.com/cri-o/cri-o/blob/master/install.md)
for more information.
#### cgroup driver
CRI-O uses the systemd cgroup driver per default. To switch to the `cgroupfs`
cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in
configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
```toml
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
```
Please also note the changed `conmon_cgroup`, which has to be set to the value
`pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the
cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
in sync.
### Docker
content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+2 -2
View File
@@ -21,8 +21,8 @@ For information how to create a cluster with kubeadm once you have performed thi
* One or more machines running one of:
- Ubuntu 16.04+
- Debian 9+
- CentOS 7
- Red Hat Enterprise Linux (RHEL) 7
- CentOS 7+
- Red Hat Enterprise Linux (RHEL) 7+
- Fedora 25+
- HypriotOS v1.0.1+
- Flatcar Container Linux (tested with 2512.3.0)
content/en/docs/setup/release/version-skew-policy.md
+5
View File
@@ -140,6 +140,11 @@ Pre-requisites:
Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
{{< note >}}
Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node.
In-place minor version `kubelet` upgrades are not supported.
{{</ note >}}
{{< warning >}}
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+51 -40
View File
@@ -1,22 +1,24 @@
---
title: Connect a Front End to a Back End Using a Service
title: Connect a Frontend to a Backend Using Services
content_type: tutorial
weight: 70
---
<!-- overview -->
This task shows how to create a frontend and a backend
microservice. The backend microservice is a hello greeter. The
frontend and backend are connected using a Kubernetes
{{< glossary_tooltip term_id="service" >}} object.
This task shows how to create a _frontend_ and a _backend_ microservice. The backend
microservice is a hello greeter. The frontend exposes the backend using nginx and a
Kubernetes {{< glossary_tooltip term_id="service" >}} object.
## {{% heading "objectives" %}}
* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object.
* Route traffic to the backend using a frontend.
* Use a Service object to connect the frontend application to the
backend application.
* Create and run a sample `hello` backend microservice using a
{{< glossary_tooltip term_id="deployment" >}} object.
* Use a Service object to send traffic to the backend microservice's multiple replicas.
* Create and run a `nginx` frontend microservice, also using a Deployment object.
* Configure the frontend microservice to send traffic to the backend microservice.
* Use a Service object of `type=LoadBalancer` to expose the frontend microservice
outside the cluster.
## {{% heading "prerequisites" %}}
@@ -34,24 +36,24 @@ require a supported environment. If your environment does not support this, you
The backend is a simple hello greeter microservice. Here is the configuration
file for the backend Deployment:
{{< codenew file="service/access/hello.yaml" >}}
{{< codenew file="service/access/backend-deployment.yaml" >}}
Create the backend Deployment:
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello.yaml
kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml
```
View information about the backend Deployment:
```shell
kubectl describe deployment hello
kubectl describe deployment backend
```
The output is similar to this:
```
Name: hello
Name: backend
Namespace: default
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
Labels: app=hello
@@ -59,7 +61,7 @@ Labels: app=hello
track=stable
Annotations: deployment.kubernetes.io/revision=1
Selector: app=hello,tier=backend,track=stable
Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
@@ -80,14 +82,14 @@ Conditions:
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: hello-3621623197 (7/7 replicas created)
NewReplicaSet: hello-3621623197 (3/3 replicas created)
Events:
...
```
## Creating the backend Service object
## Creating the `hello` Service object
The key to connecting a frontend to a backend is the backend
The key to sending requests from a frontend to a backend is the backend
Service. A Service creates a persistent IP address and DNS name entry
so that the backend microservice can always be reached. A Service uses
{{< glossary_tooltip text="selectors" term_id="selector" >}} to find
@@ -95,42 +97,51 @@ the Pods that it routes traffic to.
First, explore the Service configuration file:
{{< codenew file="service/access/hello-service.yaml" >}}
{{< codenew file="service/access/backend-service.yaml" >}}
In the configuration file, you can see that the Service routes traffic to Pods
that have the labels `app: hello` and `tier: backend`.
In the configuration file, you can see that the Service, named `hello` routes
traffic to Pods that have the labels `app: hello` and `tier: backend`.
Create the `hello` Service:
Create the backend Service:
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml
```
At this point, you have a backend Deployment running, and you have a
Service that can route traffic to it.
At this point, you have a `backend` Deployment running three replicas of your `hello`
application, and you have a Service that can route traffic to them. However, this
service is neither available nor resolvable outside the cluster.
## Creating the frontend
Now that you have your backend, you can create a frontend that connects to the backend.
The frontend connects to the backend worker Pods by using the DNS name
given to the backend Service. The DNS name is "hello", which is the value
of the `name` field in the preceding Service configuration file.
Now that you have your backend running, you can create a frontend that is accessible
outside the cluster, and connects to the backend by proxying requests to it.
The Pods in the frontend Deployment run an nginx image that is configured
to find the hello backend Service. Here is the nginx configuration file:
The frontend sends requests to the backend worker Pods by using the DNS name
given to the backend Service. The DNS name is `hello`, which is the value
of the `name` field in the `examples/service/access/backend-service.yaml`
configuration file.
{{< codenew file="service/access/frontend.conf" >}}
The Pods in the frontend Deployment run a nginx image that is configured
to proxy requests to the `hello` backend Service. Here is the nginx configuration file:
Similar to the backend, the frontend has a Deployment and a Service. The
configuration for the Service has `type: LoadBalancer`, which means that
the Service uses the default load balancer of your cloud provider.
{{< codenew file="service/access/frontend-nginx.conf" >}}
{{< codenew file="service/access/frontend.yaml" >}}
Similar to the backend, the frontend has a Deployment and a Service. An important
difference to notice between the backend and frontend services, is that the
configuration for the frontend Service has `type: LoadBalancer`, which means that
the Service uses a load balancer provisioned by your cloud provider and will be
accessible from outside the cluster.
{{< codenew file="service/access/frontend-service.yaml" >}}
{{< codenew file="service/access/frontend-deployment.yaml" >}}
Create the frontend Deployment and Service:
```shell
kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml
```
The output verifies that both resources were created:
@@ -178,7 +189,7 @@ cluster.
## Send traffic through the frontend
The frontend and backends are now connected. You can hit the endpoint
The frontend and backend are now connected. You can hit the endpoint
by using the curl command on the external IP of your frontend Service.
```shell
@@ -196,17 +207,17 @@ The output shows the message generated by the backend:
To delete the Services, enter this command:
```shell
kubectl delete services frontend hello
kubectl delete services frontend backend
```
To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command:
```shell
kubectl delete deployment frontend hello
kubectl delete deployment frontend backend
```
## {{% heading "whatsnext" %}}
* Learn more about [Services](/docs/concepts/services-networking/service/)
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
* Learn more about [DNS for Service and Pods](/docs/concepts/services-networking/dns-pod-service/)
content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
+12 -1
View File
@@ -314,7 +314,18 @@ CustomResourceDefinitions store validated resource data in the cluster's persist
{{< note >}}
CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`.
For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is set, pruning is _not_ enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set `spec.preserveUnknownFields` to true for the CustomResourceDefinition itself.
For legacy CustomResourceDefinition objects created as
`apiextensions.k8s.io/v1beta1` with `spec.preserveUnknownFields` set to
`true`, the following is also true:
* Pruning is not enabled.
* You can store arbitrary data.
For compatibility with `apiextensions.k8s.io/v1`, update your custom
resource definitions to:
1. Use a structural OpenAPI schema.
2. Set `spec.preserveUnknownFields` to `false`.
{{< /note >}}
If you save the following YAML to `my-crontab.yaml`:
content/en/docs/tasks/inject-data-application/podpreset.md
-323
View File
@@ -1,323 +0,0 @@
---
reviewers:
- jessfraz
title: Inject Information into Pods Using a PodPreset
min-kubernetes-server-version: v1.6
content_type: task
weight: 60
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time.
## {{% heading "prerequisites" %}}
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](https://minikube.sigs.k8s.io/docs/).
Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster.
<!-- steps -->
## Use Pod presets to inject environment variables and volumes
In this step, you create a preset that has a volume mount and one environment variable.
Here is the manifest for the PodPreset:
{{< codenew file="podpreset/preset.yaml" >}}
The name of a PodPreset object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
In the manifest, you can see that the preset has an environment variable definition called `DB_PORT`
and a volume mount definition called `cache-volume` which is mounted under `/cache`. The {{< glossary_tooltip text="selector" term_id="selector" >}} specifies that
the preset will act upon any Pod that is labeled `role:frontend`.
Create the PodPreset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
Verify that the PodPreset has been created:
```shell
kubectl get podpreset
```
```
NAME CREATED AT
allow-database 2020-01-24T08:54:29Z
```
This manifest defines a Pod labelled `role: frontend` (matching the PodPreset's selector):
{{< codenew file="podpreset/pod.yaml" >}}
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
Verify that the Pod is running:
```shell
kubectl get pods
```
The output shows that the Pod is running:
```
NAME READY STATUS RESTARTS AGE
website 1/1 Running 0 4m
```
View the Pod spec altered by the admission controller in order to see the effects of the preset
having been applied:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/merged.yaml" >}}
The `DB_PORT` environment variable, the `volumeMount` and the `podpreset.admission.kubernetes.io` annotation
of the Pod verify that the preset has been applied.
## Pod spec with ConfigMap example
This is an example to show how a Pod spec is modified by a Pod preset
that references a ConfigMap containing environment variables.
Here is the manifest containing the definition of the ConfigMap:
{{< codenew file="podpreset/configmap.yaml" >}}
Create the ConfigMap:
```shell
kubectl create -f https://k8s.io/examples/podpreset/configmap.yaml
```
Here is a PodPreset manifest referencing that ConfigMap:
{{< codenew file="podpreset/allow-db.yaml" >}}
Create the preset that references the ConfigMap:
```shell
kubectl create -f https://k8s.io/examples/podpreset/allow-db.yaml
```
The following manifest defines a Pod matching the PodPreset for this example:
{{< codenew file="podpreset/pod.yaml" >}}
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
View the Pod spec altered by the admission controller in order to see the effects of the preset
having been applied:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/allow-db-merged.yaml" >}}
The `DB_PORT` environment variable and the `podpreset.admission.kubernetes.io` annotation of the Pod
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
like ReplicaSets or Deployments are unaffected.
Here is the manifest for the PodPreset for this example:
{{< codenew file="podpreset/preset.yaml" >}}
Create the preset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
This manifest defines a ReplicaSet that manages three application Pods:
{{< codenew file="podpreset/replicaset.yaml" >}}
Create the ReplicaSet:
```shell
kubectl create -f https://k8s.io/examples/podpreset/replicaset.yaml
```
Verify that the Pods created by the ReplicaSet are running:
```shell
kubectl get pods
```
The output shows that the Pods are running:
```
NAME READY STATUS RESTARTS AGE
frontend-2l94q 1/1 Running 0 2m18s
frontend-6vdgn 1/1 Running 0 2m18s
frontend-jzt4p 1/1 Running 0 2m18s
```
View the `spec` of the ReplicaSet:
```shell
kubectl get replicasets frontend -o yaml
```
{{< note >}}
The ReplicaSet object's `spec` was not changed, nor does the ReplicaSet contain a
`podpreset.admission.kubernetes.io` annotation. This is because a PodPreset only
applies to Pod objects.
To see the effects of the preset having been applied, you need to look at individual Pods.
{{< /note >}}
The command to view the specs of the affected Pods is:
```shell
kubectl get pod --selector=role=frontend -o yaml
```
{{< codenew file="podpreset/replicaset-merged.yaml" >}}
Again the `podpreset.admission.kubernetes.io` annotation of the Pods
verifies that the preset has been applied.
## Multiple Pod presets example
This is an example to show how a Pod spec is modified by multiple Pod presets.
Here is the manifest for the first PodPreset:
{{< codenew file="podpreset/preset.yaml" >}}
Create the first PodPreset for this example:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
Here is the manifest for the second PodPreset:
{{< codenew file="podpreset/proxy.yaml" >}}
Create the second preset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/proxy.yaml
```
Here's a manifest containing the definition of an applicable Pod (matched by two PodPresets):
{{< codenew file="podpreset/pod.yaml" >}}
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
View the Pod spec altered by the admission controller in order to see the effects of both presets
having been applied:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/multi-merged.yaml" >}}
The `DB_PORT` environment variable, the `proxy-volume` VolumeMount and the two `podpreset.admission.kubernetes.io`
annotations of the Pod verify that both presets have been applied.
## Conflict example
This is an example to show how a Pod spec is not modified by a Pod preset when there is a conflict.
The conflict in this example consists of a `VolumeMount` in the PodPreset conflicting with a Pod that defines the same `mountPath`.
Here is the manifest for the PodPreset:
{{< codenew file="podpreset/conflict-preset.yaml" >}}
Note the `mountPath` value of `/cache`.
Create the preset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/conflict-preset.yaml
```
Here is the manifest for the Pod:
{{< codenew file="podpreset/conflict-pod.yaml" >}}
Note the volumeMount element with the same path as in the PodPreset.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/conflict-pod.yaml
```
View the Pod spec:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/conflict-pod.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](/docs/reference/access-authn-authz/admission-controllers/#podpreset)
logs a warning containing details of the conflict.
You can view the warning using `kubectl`:
```shell
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:
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:""}
in container
```
Note the conflict message on the path for the VolumeMount.
## Deleting a PodPreset
Once you don't need a PodPreset anymore, you can delete it with `kubectl`:
```shell
kubectl delete podpreset allow-database
```
The output shows that the PodPreset was deleted:
```
podpreset "allow-database" deleted
```
content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+5 -4
View File
@@ -392,8 +392,8 @@ spec:
containers:
- name: my-nginx
resources:
limits:
memory: 512Mi
limits:
memory: 512Mi
EOF
cat <<EOF >./kustomization.yaml
@@ -424,11 +424,12 @@ spec:
spec:
containers:
- image: nginx
limits:
memory: 512Mi
name: my-nginx
ports:
- containerPort: 80
resources:
limits:
memory: 512Mi
```
Not all Resources or fields support strategic merge patches. To support modifying arbitrary fields in arbitrary Resources,
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+1 -1
View File
@@ -60,7 +60,7 @@ This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://
## Download and install CFSSL
The cfssl tools used in this example can be downloaded at
[https://pkg.cfssl.org/](https://pkg.cfssl.org/).
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases).
## Create a Certificate Signing Request
content/en/docs/tasks/tools/install-kubectl.md
+152 -52
View File
@@ -32,34 +32,73 @@ Using the latest version of kubectl helps avoid unforeseen issues.
1. Download the latest release with the command:
```
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
```bash
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
{{< note >}}
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on Linux, type:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
For example, to download version {{< param "fullversion" >}} on Linux, type:
2. Make the kubectl binary executable.
```bash
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
{{< /note >}}
```
chmod +x ./kubectl
```
1. Validate the binary (optional)
3. Move the binary in to your PATH.
Download the kubectl checksum file:
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. Test to ensure the version you installed is up-to-date:
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
```
```
kubectl version --client
```
Validate the kubectl binary against the checksum file:
```bash
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
```
If valid, the output is:
```bash
kubectl: OK
```
If the check fails, `sha256` exits with nonzero status and prints output similar to:
```bash
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Download the same version of the binary and checksum.
{{< /note >}}
1. Install kubectl
```bash
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
```
{{< note >}}
If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory:
```bash
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# and then add ~/.local/bin/kubectl to $PATH
```
{{< /note >}}
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
```
### Install using native package management
@@ -120,30 +159,65 @@ kubectl version --client
1. Download the latest release:
```bash
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
{{< note >}}
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on macOS, type:
```bash
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
Make the kubectl binary executable.
{{< /note >}}
1. Validate the binary (optional)
Download the kubectl checksum file:
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
```
Validate the kubectl binary against the checksum file:
```bash
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
```
If valid, the output is:
```bash
kubectl: OK
```
If the check fails, `shasum` exits with nonzero status and prints output similar to:
```bash
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Download the same version of the binary and checksum.
{{< /note >}}
1. Make the kubectl binary executable.
```bash
chmod +x ./kubectl
```
3. Move the binary in to your PATH.
1. Move the kubectl binary to a file location on your system `PATH`.
```bash
sudo mv ./kubectl /usr/local/bin/kubectl
sudo mv ./kubectl /usr/local/bin/kubectl && \
sudo chown root: /usr/local/bin/kubectl
```
4. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
@@ -165,7 +239,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
brew install kubernetes-cli
```
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
@@ -182,7 +256,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
sudo port install kubectl
```
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
@@ -192,47 +266,72 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
### Install kubectl binary with curl on Windows
1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
1. Download the [latest release {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
Or if you have `curl` installed, use this command:
```bash
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```powershell
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
{{< note >}}
To find out the latest stable version (for example, for scripting), take a look at [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).
{{< /note >}}
2. Add the binary in to your PATH.
1. Validate the binary (optional)
3. Test to ensure the version of `kubectl` is the same as downloaded:
Download the kubectl checksum file:
```bash
```powershell
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
```
Validate the kubectl binary against the checksum file:
- Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
```cmd
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
```
- Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result:
```powershell
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
```
1. Add the binary in to your `PATH`.
1. Test to ensure the version of `kubectl` is the same as downloaded:
```cmd
kubectl version --client
```
{{< note >}}
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH.
If you have installed Docker Desktop before, you may need to place your PATH entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`.
If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
{{< /note >}}
### Install with Powershell from PSGallery
### Install with PowerShell from PSGallery
If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell.
If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell.
1. Run the installation commands (making sure to specify a `DownloadLocation`):
```powershell
Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
```
```
{{< note >}}
If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory.
{{< /note >}}
The installer creates `$HOME/.kube` and instructs it to create a config file.
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```powershell
kubectl version --client
@@ -260,32 +359,32 @@ Updating the installation is performed by rerunning the two commands listed in s
{{< /tabs >}}
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```powershell
kubectl version --client
```
3. Navigate to your home directory:
1. Navigate to your home directory:
```powershell
# If you're using cmd.exe, run: cd %USERPROFILE%
cd ~
```
4. Create the `.kube` directory:
1. Create the `.kube` directory:
```powershell
mkdir .kube
```
5. Change to the `.kube` directory you just created:
1. Change to the `.kube` directory you just created:
```powershell
cd .kube
```
6. Configure kubectl to use a remote Kubernetes cluster:
1. Configure kubectl to use a remote Kubernetes cluster:
```powershell
New-Item config -type file
@@ -301,13 +400,13 @@ You can install kubectl as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Run the `kubectl` installation command:
1. Run the `kubectl` installation command:
```shell
gcloud components install kubectl
```
3. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```shell
kubectl version --client
@@ -385,11 +484,13 @@ You now need to ensure that the kubectl completion script gets sourced in all yo
```bash
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- Add the completion script to the `/etc/bash_completion.d` directory:
```bash
kubectl completion bash >/etc/bash_completion.d/kubectl
```
If you have an alias for kubectl, you can extend shell completion to work with that alias:
```bash
@@ -470,7 +571,6 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
```bash
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
- Add the completion script to the `/usr/local/etc/bash_completion.d` directory: