kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #48401 from windsonsea/nodefor 

Clean up best-practices: certificates and node-conformance
pull/48612/head
Kubernetes Prow Robot 2024-11-01 03:03:26 +00:00 committed by GitHub
parent 6d4ef645b1 1d24167b04
commit 17119b9b6a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 63 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
content/en/docs/setup/best-practices/certificates.md
View File

@ -42,15 +42,19 @@ Kubernetes requires PKI for the following operations:
### Kubelet's server and client certificates
To establish a secure connection and authenticate itself to the kubelet, the API Server
requires a client certificate and key pair.
To establish a secure connection and authenticate itself to the kubelet, the API Server
requires a client certificate and key pair.
In this scenario, there are two approaches for certificate usage:
using shared certificates or separate certificates;
In this scenario, there are two approaches for certificate usage:
* Shared Certificates: The kube-apiserver can utilize the same certificate and key pair it uses to authenticate its clients. This means that the existing certificates, such as `apiserver.crt` and `apiserver.key`, can be used for communicating with the kubelet servers.
* Shared Certificates: The kube-apiserver can utilize the same certificate and key pair it uses
to authenticate its clients. This means that the existing certificates, such as `apiserver.crt`
and `apiserver.key`, can be used for communicating with the kubelet servers.
* Separate Certificates: Alternatively, the kube-apiserver can generate a new client certificate and key pair to authenticate its communication with the kubelet servers. In this case, a distinct certificate named `kubelet-client.crt` and its corresponding private key, `kubelet-client.key` are created.
* Separate Certificates: Alternatively, the kube-apiserver can generate a new client certificate
and key pair to authenticate its communication with the kubelet servers. In this case,
a distinct certificate named `kubelet-client.crt` and its corresponding private key,
`kubelet-client.key` are created.
{{< note >}}
`front-proxy` certificates are required only if you run kube-proxy to support
@ -80,7 +84,7 @@ multiple intermediate CAs, and delegate all further creation to Kubernetes itsel
Required CAs:
| path | Default CN | description |
| Path | Default CN | Description |
|------------------------|---------------------------|----------------------------------|
| ca.crt,key | kubernetes-ca | Kubernetes general CA |
| etcd/ca.crt,key | etcd-ca | For all etcd-related functions |
@ -111,7 +115,7 @@ Required certificates:
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
| kube-etcd-healthcheck-client | etcd-ca | | client | |
| kube-apiserver-etcd-client | etcd-ca | | client | |
| kube-apiserver | kubernetes-ca | | server | `<hostname>`, `<Host_IP>`, `<advertise_IP>`, `[1]` |
| kube-apiserver | kubernetes-ca | | server | `<hostname>`, `<Host_IP>`, `<advertise_IP>`[^1] |
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
@ -121,7 +125,7 @@ a less privileged group can be used. kubeadm uses the `kubeadm:cluster-admins` g
that purpose.
{{< /note >}}
[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)
[^1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)
the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
@ -155,22 +159,22 @@ For kubeadm users only:
Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)).
Paths should be specified using the given argument regardless of location.
| Default CN | recommended key path | recommended cert path | command | key argument | cert argument |
|------------------------------|------------------------------|-----------------------------|-------------------------|------------------------------|-------------------------------------------|
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
| kube-apiserver-kubelet-client| apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file |
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
| etcd-ca | | etcd/ca.crt | etcdctl | | --cacert |
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
| DefaultCN | recommendedkeypath | recommendedcertpath | command | keyargument | certargument |
| --------- | ------------------ | ------------------- | ------- | ----------- | ------------ |
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file,--root-ca-file,--cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt| kube-apiserver | --tls-private-key-file | --tls-cert-file |
| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file,--peer-trusted-ca-file |
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
| etcd-ca| | etcd/ca.crt | etcdctl | | --cacert |
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
Same considerations apply for the service account key pair:
@ -206,11 +210,12 @@ you need to provide if you are generating all of your own keys and certificates:
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub
```
## Configure certificates for user accounts
You must manually configure these administrator account and service accounts:
You must manually configure these administrator accounts and service accounts:
| filename | credential name | Default CN | O (in Subject) |
| Filename | Credential name | Default CN | O (in Subject) |
|-------------------------|----------------------------|-------------------------------------|------------------------|
| admin.conf | default-admin | kubernetes-admin | `<admin-group>` |
| super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters |
@ -240,20 +245,21 @@ Another is in `super-admin.conf` that has `Subject: O = system:masters, CN = kub
This file is generated only on the node where `kubeadm init` was called.
{{< /note >}}
1. For each config, generate an x509 cert/key pair with the given CN and O.
1. For each configuration, generate an x509 certificate/key pair with the
given Common Name (CN) and Organization (O).
1. Run `kubectl` as follows for each config:
1. Run `kubectl` as follows for each configuration:
```
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system
```
```
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system
```
These files are used as follows:
| filename | command | comment |
| Filename | Command | Comment |
|-------------------------|-------------------------|-----------------------------------------------------------------------|
| admin.conf | kubectl | Configures administrator user for the cluster |
| super-admin.conf | kubectl | Configures super administrator user for the cluster |

40
content/en/docs/setup/best-practices/node-conformance.md
View File

@ -5,7 +5,6 @@ title: Validate node setup
weight: 30
---
## Node Conformance Test
*Node conformance test* is a containerized test framework that provides a system
@ -19,40 +18,42 @@ To run node conformance test, a node must satisfy the same prerequisites as a
standard Kubernetes node. At a minimum, the node should have the following
daemons installed:
* CRI-compatible container runtimes such as Docker, Containerd and CRI-O
* Kubelet
* CRI-compatible container runtimes such as Docker, containerd and CRI-O
* kubelet
## Running Node Conformance Test
To run the node conformance test, perform the following steps:
1. Work out the value of the `--kubeconfig` option for the kubelet; for example:
`--kubeconfig=/var/lib/kubelet/config.yaml`.
Because the test framework starts a local control plane to test the kubelet,
use `http://localhost:8080` as the URL of the API server.
There are some other kubelet command line parameters you may want to use:
* `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
remove the flag to run the test.
* `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
remove the flag to run the test.
2. Run the node conformance test with command:
1. Run the node conformance test with command:
```shell
# $CONFIG_DIR is the pod manifest path of your Kubelet.
# $LOG_DIR is the test output path.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
registry.k8s.io/node-test:0.2
```
```shell
# $CONFIG_DIR is the pod manifest path of your kubelet.
# $LOG_DIR is the test output path.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
registry.k8s.io/node-test:0.2
```
## Running Node Conformance Test for Other Architectures
Kubernetes also provides node conformance test docker images for other
architectures:
Arch | Image |
--------|:-----------------:|
amd64 | node-test-amd64 |
arm | node-test-arm |
arm64 | node-test-arm64 |
| Arch | Image |
|--------|:-----------------:|
| amd64 | node-test-amd64 |
| arm | node-test-arm |
| arm64 | node-test-arm64 |
## Running Selected Test
@ -76,7 +77,8 @@ sudo docker run -it --rm --privileged --net=host \
registry.k8s.io/node-test:0.2
```
Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md).
Node conformance test is a containerized version of
[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md).
By default, it runs all conformance tests.
Theoretically, you can run any node e2e test if you configure the container and