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

Merge master into dev-1.22 to keep in sync

Browse Source
This commit is contained in:
Victor Palade
2021-08-04 19:43:06 +02:00
parent afeca102eb a54e81ece4
commit 61ac44bb11
31 changed files with 417 additions and 149 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+2 -2
View File
@@ -163,7 +163,7 @@ Instructions to do so are available at [Install Docker Engine - Enterprise on Wi
#### Install wins, kubelet, and kubeadm
```PowerShell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
@@ -206,7 +206,7 @@ If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2")
#### Install wins, kubelet, and kubeadm
```PowerShell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
```
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+12 -1
View File
@@ -126,7 +126,18 @@ command. In that case, you should explicitly set `--certificate-renewal=true`.
You can renew your certificates manually at any time with the `kubeadm certs renew` command.
This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
After running the command you should restart the control plane Pods. This is required since
dynamic certificate reload is currently not supported for all components and certificates.
[Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet
and not by the API Server, thus kubectl cannot be used to delete and restart them.
To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/`
and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/
reference/config-api/kubelet-config.v1beta1/).
The kubelet will terminate the Pod if it's no longer in the manifest directory.
You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate
the Pod and the certificate renewal for the component can complete.
{{< warning >}}
If you are running an HA cluster, this command needs to be executed on all the control-plane nodes.
content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+39 -25
View File
@@ -24,45 +24,59 @@ For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.
## Deploying Cilium on Minikube for Basic Testing
To get familiar with Cilium easily you can follow the
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/)
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)
to perform a basic DaemonSet installation of Cilium in minikube.
To start minikube, minimal version required is >= v1.3.1, run the with the
To start minikube, minimal version required is >= v1.5.2, run the with the
following arguments:
```shell
minikube version
```
```
minikube version: v1.3.1
minikube version: v1.5.2
```
```shell
minikube start --network-plugin=cni --memory=4096
minikube start --network-plugin=cni
```
Mount the BPF filesystem:
For minikube you can install Cilium using its CLI tool. Cilium will
automatically detect the cluster configuration and will install the appropriate
components for a successful installation:
```shell
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
```
For minikube you can deploy this simple ''all-in-one'' YAML file that includes
DaemonSet configurations for Cilium as well as appropriate RBAC settings:
```shell
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz
cilium install
```
```
configmap/cilium-config created
serviceaccount/cilium created
serviceaccount/cilium-operator created
clusterrole.rbac.authorization.k8s.io/cilium created
clusterrole.rbac.authorization.k8s.io/cilium-operator created
clusterrolebinding.rbac.authorization.k8s.io/cilium created
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
daemonset.apps/cilium create
deployment.apps/cilium-operator created
🔮 Auto-detected Kubernetes kind: minikube
✨ Running "minikube" validation checks
✅ Detected minikube version "1.20.0"
ℹ️ Cilium version not set, using default version "v1.10.0"
🔮 Auto-detected cluster name: minikube
🔮 Auto-detected IPAM mode: cluster-pool
🔮 Auto-detected datapath mode: tunnel
🔑 Generating CA...
2021/05/27 02:54:44 [INFO] generate received request
2021/05/27 02:54:44 [INFO] received CSR
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
2021/05/27 02:54:44 [INFO] encoded CSR
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
🔑 Generating certificates for Hubble...
2021/05/27 02:54:44 [INFO] generate received request
2021/05/27 02:54:44 [INFO] received CSR
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
2021/05/27 02:54:44 [INFO] encoded CSR
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
🚀 Creating Service accounts...
🚀 Creating Cluster roles...
🚀 Creating ConfigMap...
🚀 Creating Agent DaemonSet...
🚀 Creating Operator Deployment...
⌛ Waiting for Cilium to be installed...
```
The remainder of the Getting Started Guide explains how to enforce both L3/L4
@@ -85,14 +99,14 @@ Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
this list of Pods run:
```shell
kubectl get pods --namespace=kube-system
kubectl get pods --namespace=kube-system -l k8s-app=cilium
```
You'll see a list of Pods similar to this:
```console
NAME READY STATUS RESTARTS AGE
cilium-6rxbd 1/1 Running 0 1m
NAME READY STATUS RESTARTS AGE
cilium-kkdhz 1/1 Running 0 3m23s
...
```
content/en/docs/tasks/administer-cluster/securing-a-cluster.md
+15 -13
View File
@@ -26,7 +26,7 @@ and provides recommendations on overall security.
## Controlling access to the Kubernetes API
As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions
As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions
they are allowed to perform is the first line of defense.
### Use Transport Layer Security (TLS) for all API traffic
@@ -40,7 +40,7 @@ potentially unsecured traffic.
### API Authentication
Choose an authentication mechanism for the API servers to use that matches the common access patterns
when you install a cluster. For instance, small single user clusters may wish to use a simple certificate
when you install a cluster. For instance, small, single-user clusters may wish to use a simple certificate
or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that
allow users to be subdivided into groups.
@@ -54,7 +54,7 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships
an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a
set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
resources (pods, services, nodes) and can be namespace-scoped or cluster-scoped. A set of out-of-the-box
roles are provided that offer reasonable default separation of responsibility depending on what
actions a client might want to perform. It is recommended that you use the
[Node](/docs/reference/access-authn-authz/node/) and
@@ -69,8 +69,8 @@ With authorization, it is important to understand how updates on one object may
other places. For instance, a user may not be able to create pods directly, but allowing them to
create a deployment, which creates pods on their behalf, will let them create those pods
indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node
being terminated and recreated on other nodes. The out of the box roles represent a balance
between flexibility and the common use cases, but more limited roles should be carefully reviewed
being terminated and recreated on other nodes. The out-of-the box roles represent a balance
between flexibility and common use cases, but more limited roles should be carefully reviewed
to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.
Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
@@ -104,7 +104,7 @@ reserved resources like memory, or to provide default limits when none are speci
### Controlling what privileges containers run with
A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/)
that allows it to request access to running as a specific Linux user on a node (like root),
that allows it to request access to run as a specific Linux user on a node (like root),
access to run privileged or access the host network, and other controls that would otherwise
allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
@@ -155,10 +155,10 @@ within their namespaces. Many of the supported [Kubernetes networking providers]
now respect network policy.
Quota and limit ranges can also be used to control whether users may request node ports or
load balanced services, which on many clusters can control whether those users applications
load-balanced services, which on many clusters can control whether those users applications
are visible outside of the cluster.
Additional protections may be available that control network rules on a per plugin or per
Additional protections may be available that control network rules on a per-plugin or per-
environment basis, such as per-node firewalls, physically separating cluster nodes to
prevent cross talk, or advanced networking policy.
@@ -169,7 +169,7 @@ By default these APIs are accessible by pods running on an instance and can cont
credentials for that node, or provisioning data such as kubelet credentials. These credentials
can be used to escalate within the cluster or to other cloud services under the same account.
When running Kubernetes on a cloud platform limit permissions given to instance credentials, use
When running Kubernetes on a cloud platform, limit permissions given to instance credentials, use
[network policies](/docs/tasks/administer-cluster/declare-network-policy/) to restrict pod access
to the metadata API, and avoid using provisioning data to deliver secrets.
@@ -177,7 +177,7 @@ to the metadata API, and avoid using provisioning data to deliver secrets.
By default, there are no restrictions on which nodes may run a pod. Kubernetes offers a
[rich set of policies for controlling placement of pods onto nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
and the [taint based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
and the [taint-based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
that are available to end users. For many clusters use of these policies to separate workloads
can be a convention that authors adopt or enforce via tooling.
@@ -223,8 +223,9 @@ do not use.
The shorter the lifetime of a secret or credential the harder it is for an attacker to make
use of that credential. Set short lifetimes on certificates and automate their rotation. Use
an authentication provider that can control how long issued tokens are available and use short
lifetimes where possible. If you use service account tokens in external integrations, plan to
rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed.
lifetimes where possible. If you use service-account tokens in external integrations, plan to
rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap
token used for setting up nodes should be revoked or its authorization removed.
### Review third party integrations before enabling them
@@ -246,7 +247,8 @@ and may grant an attacker significant visibility into the state of your cluster.
your backups using a well reviewed backup and encryption solution, and consider using full disk
encryption where possible.
Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature
introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
parties that gain access to your etcd backups from viewing the content of those secrets. While
this feature is currently beta, it offers an additional level of defense when backups
are not encrypted or an attacker gains read access to etcd.
content/en/docs/tasks/network/validate-dual-stack.md
+1 -1
View File
@@ -16,7 +16,7 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico)
* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Calico, Cilium or Kubenet)
* [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster
{{< version-check >}}
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -189,7 +189,7 @@ by making use of the `autoscaling/v2beta2` API version.
First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:
```shell
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
```
Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
content/en/docs/tasks/tools/install-kubectl-macos.md
+1 -1
View File
@@ -185,7 +185,7 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
1. Validate the binary (optional)
Download the kubectl checksum file:
Download the kubectl-convert checksum file:
{{< tabs name="download_convert_checksum_macos" >}}
{{< tab name="Intel" codelang="bash" >}}