Merge main into dev-1.22 to keep in sync
This commit is contained in:
Christopher Negus
@@ -116,6 +116,9 @@ manually through `easyrsa`, `openssl` or `cfssl`.
|
||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
|
||||
-CAcreateserial -out server.crt -days 10000 \
|
||||
-extensions v3_ext -extfile csr.conf
|
||||
1. View the certificate signing request:
|
||||
|
||||
openssl req -noout -text -in ./server.csr
|
||||
1. View the certificate:
|
||||
|
||||
openssl x509 -noout -text -in ./server.crt
|
||||
|
||||
@@ -10,7 +10,7 @@ aliases: [ '/docs/tasks/administer-cluster/highly-available-master/' ]
|
||||
|
||||
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
|
||||
|
||||
You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine.
|
||||
You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine. However this scripts are not suitable for any sort of production use, it's widely used in the project's CI.
|
||||
This document describes how to use kube-up/down scripts to manage a highly available (HA) control plane and how HA control planes are implemented for use with GCE.
|
||||
|
||||
|
||||
@@ -156,14 +156,14 @@ and the IP address of the first replica will be promoted to IP address of load b
|
||||
Similarly, after removal of the penultimate control plane node, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
|
||||
Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate.
|
||||
|
||||
### Master service & kubelets
|
||||
### Control plane service & kubelets
|
||||
|
||||
Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service,
|
||||
the system directs all traffic to the external IP:
|
||||
|
||||
* in case of a single node control plane, the IP points to the control plane node,
|
||||
|
||||
* in case of an HA control plane, the IP points to the load balancer in-front of the masters.
|
||||
* in case of an HA control plane, the IP points to the load balancer in-front of the control plane nodes.
|
||||
|
||||
Similarly, the external IP will be used by kubelets to communicate with the control plane.
|
||||
|
||||
|
||||
@@ -78,7 +78,8 @@ A namespace can be in one of two phases:
|
||||
* `Active` the namespace is in use
|
||||
* `Terminating` the namespace is being deleted, and can not be used for new objects
|
||||
|
||||
See the [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) for more details.
|
||||
For more details, see [Namespace](/docs/reference/kubernetes-api/cluster-resources/namespace-v1/)
|
||||
in the API reference.
|
||||
|
||||
## Creating a new namespace
|
||||
|
||||
|
||||
@@ -380,5 +380,5 @@ JWKS URI is required to use the `https` scheme.
|
||||
See also:
|
||||
|
||||
- [Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
|
||||
- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
|
||||
- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)
|
||||
|
||||
@@ -24,7 +24,7 @@ a Pod or Container. Security context settings include, but are not limited to:
|
||||
|
||||
* [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs.
|
||||
|
||||
* [Seccomp](https://en.wikipedia.org/wiki/Seccomp): Filter a process's system calls.
|
||||
* [Seccomp](/docs/tutorials/clusters/seccomp/): Filter a process's system calls.
|
||||
|
||||
* AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has `CAP_SYS_ADMIN`.
|
||||
|
||||
|
||||
+8
-4
@@ -154,22 +154,26 @@ from the YAML you used to create it:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: List
|
||||
items:
|
||||
- apiVersion: stable.example.com/v1
|
||||
kind: CronTab
|
||||
metadata:
|
||||
creationTimestamp: 2017-05-31T12:56:35Z
|
||||
annotations:
|
||||
kubectl.kubernetes.io/last-applied-configuration: |
|
||||
{"apiVersion":"stable.example.com/v1","kind":"CronTab","metadata":{"annotations":{},"name":"my-new-cron-object","namespace":"default"},"spec":{"cronSpec":"* * * * */5","image":"my-awesome-cron-image"}}
|
||||
creationTimestamp: "2021-06-20T07:35:27Z"
|
||||
generation: 1
|
||||
name: my-new-cron-object
|
||||
namespace: default
|
||||
resourceVersion: "285"
|
||||
uid: 9423255b-4600-11e7-af6a-28d2447dc82b
|
||||
resourceVersion: "1326"
|
||||
uid: 9aab1d66-628e-41bb-a422-57b8b3b1f5a9
|
||||
spec:
|
||||
cronSpec: '* * * * */5'
|
||||
image: my-awesome-cron-image
|
||||
kind: List
|
||||
metadata:
|
||||
resourceVersion: ""
|
||||
selfLink: ""
|
||||
```
|
||||
|
||||
## Delete a CustomResourceDefinition
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
reviewers:
|
||||
- rickypai
|
||||
- thockin
|
||||
title: Adding entries to Pod /etc/hosts with HostAliases
|
||||
content_type: task
|
||||
weight: 60
|
||||
min-kubernetes-server-version: 1.7
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec.
|
||||
|
||||
Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart.
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Default hosts file content
|
||||
|
||||
Start an Nginx Pod which is assigned a Pod IP:
|
||||
|
||||
```shell
|
||||
kubectl run nginx --image nginx
|
||||
```
|
||||
|
||||
```
|
||||
pod/nginx created
|
||||
```
|
||||
|
||||
Examine a Pod IP:
|
||||
|
||||
```shell
|
||||
kubectl get pods --output=wide
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
||||
```
|
||||
|
||||
The hosts file content would look like this:
|
||||
|
||||
```shell
|
||||
kubectl exec nginx -- cat /etc/hosts
|
||||
```
|
||||
|
||||
```
|
||||
# Kubernetes-managed hosts file.
|
||||
127.0.0.1 localhost
|
||||
::1 localhost ip6-localhost ip6-loopback
|
||||
fe00::0 ip6-localnet
|
||||
fe00::0 ip6-mcastprefix
|
||||
fe00::1 ip6-allnodes
|
||||
fe00::2 ip6-allrouters
|
||||
10.200.0.4 nginx
|
||||
```
|
||||
|
||||
By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like
|
||||
`localhost` and its own hostname.
|
||||
|
||||
## Adding additional entries with hostAliases
|
||||
|
||||
In addition to the default boilerplate, you can add additional entries to the
|
||||
`hosts` file.
|
||||
For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
|
||||
`bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under
|
||||
`.spec.hostAliases`:
|
||||
|
||||
{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
|
||||
|
||||
You can start a Pod with that configuration by running:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml
|
||||
```
|
||||
|
||||
```
|
||||
pod/hostaliases-pod created
|
||||
```
|
||||
|
||||
Examine a Pod's details to see its IPv4 address and its status:
|
||||
|
||||
```shell
|
||||
kubectl get pod --output=wide
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0
|
||||
```
|
||||
|
||||
The `hosts` file content looks like this:
|
||||
|
||||
```shell
|
||||
kubectl logs hostaliases-pod
|
||||
```
|
||||
|
||||
```
|
||||
# Kubernetes-managed hosts file.
|
||||
127.0.0.1 localhost
|
||||
::1 localhost ip6-localhost ip6-loopback
|
||||
fe00::0 ip6-localnet
|
||||
fe00::0 ip6-mcastprefix
|
||||
fe00::1 ip6-allnodes
|
||||
fe00::2 ip6-allrouters
|
||||
10.200.0.5 hostaliases-pod
|
||||
|
||||
# Entries added by HostAliases.
|
||||
127.0.0.1 foo.local bar.local
|
||||
10.1.2.3 foo.remote bar.remote
|
||||
```
|
||||
|
||||
with the additional entries specified at the bottom.
|
||||
|
||||
## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file}
|
||||
|
||||
The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
|
||||
`hosts` file for each container of the Pod to prevent Docker from
|
||||
[modifying](https://github.com/moby/moby/issues/17190) the file after the
|
||||
containers have already been started.
|
||||
|
||||
{{< caution >}}
|
||||
Avoid making manual changes to the hosts file inside a container.
|
||||
|
||||
If you make manual changes to the hosts file,
|
||||
those changes are lost when the container exits.
|
||||
{{< /caution >}}
|
||||
@@ -82,6 +82,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
||||
If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory:
|
||||
|
||||
```bash
|
||||
chmod +x kubectl
|
||||
mkdir -p ~/.local/bin/kubectl
|
||||
mv ./kubectl ~/.local/bin/kubectl
|
||||
# and then add ~/.local/bin/kubectl to $PATH
|
||||
|
||||
Reference in New Issue
Block a user