Merge branch 'master' into release-1.8
This commit is contained in:
steveperry-53
@@ -19,7 +19,7 @@ API server prior to persistence of the object, but after the request is authenti
|
||||
and authorized. The plug-in code is in the API server process
|
||||
and must be compiled into the binary in order to be used at this time.
|
||||
|
||||
Each admission control plug-in is run in sequence before a request is accepted into the cluster. If
|
||||
Each admission control plug-in runs in sequence before a request is accepted into the cluster. If
|
||||
any of the plug-ins in the sequence reject the request, the entire request is rejected immediately
|
||||
and an error is returned to the end-user.
|
||||
|
||||
|
||||
@@ -722,23 +722,23 @@ Finally, add the following parameters into API server start parameters:
|
||||
|
||||
1. Download, unpack, and initialize the patched version of easyrsa3.
|
||||
|
||||
curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
||||
tar xzf easy-rsa.tar.gz
|
||||
cd easy-rsa-master/easyrsa3
|
||||
./easyrsa init-pki
|
||||
curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
||||
tar xzf easy-rsa.tar.gz
|
||||
cd easy-rsa-master/easyrsa3
|
||||
./easyrsa init-pki
|
||||
1. Generate a CA. (`--batch` set automatic mode. `--req-cn` default CN to use.)
|
||||
|
||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||
1. Generate server certificate and key.
|
||||
(build-server-full [filename]: Generate a keypair and sign locally for a client or server)
|
||||
|
||||
./easyrsa --subject-alt-name="IP:${MASTER_IP}" build-server-full server nopass
|
||||
./easyrsa --subject-alt-name="IP:${MASTER_IP}" build-server-full server nopass
|
||||
1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory.
|
||||
1. Fill in and add the following parameters into the API server start parameters:
|
||||
|
||||
--client-ca-file=/yourdirectory/ca.crt
|
||||
--tls-cert-file=/yourdirectory/server.crt
|
||||
--tls-private-key-file=/yourdirectory/server.key
|
||||
--client-ca-file=/yourdirectory/ca.crt
|
||||
--tls-cert-file=/yourdirectory/server.crt
|
||||
--tls-private-key-file=/yourdirectory/server.key
|
||||
|
||||
#### openssl
|
||||
|
||||
@@ -746,22 +746,22 @@ Finally, add the following parameters into API server start parameters:
|
||||
|
||||
1. Generate a ca.key with 2048bit:
|
||||
|
||||
openssl genrsa -out ca.key 2048
|
||||
openssl genrsa -out ca.key 2048
|
||||
1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time):
|
||||
|
||||
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
||||
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
||||
1. Generate a server.key with 2048bit
|
||||
|
||||
openssl genrsa -out server.key 2048
|
||||
openssl genrsa -out server.key 2048
|
||||
1. According to the server.key generate a server.csr:
|
||||
|
||||
openssl req -new -key server.key -subj "/CN=${MASTER_IP}" -out server.csr
|
||||
openssl req -new -key server.key -subj "/CN=${MASTER_IP}" -out server.csr
|
||||
1. According to the ca.key, ca.crt and server.csr generate the server.crt:
|
||||
|
||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000
|
||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000
|
||||
1. View the certificate.
|
||||
|
||||
openssl x509 -noout -text -in ./server.crt
|
||||
openssl x509 -noout -text -in ./server.crt
|
||||
|
||||
Finally, do not forget to fill out and add the same parameters into the API server start parameters.
|
||||
|
||||
|
||||
@@ -648,7 +648,7 @@ Grants a `ClusterRole` across the entire cluster, including all namespaces. Exam
|
||||
|
||||
`kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp`
|
||||
|
||||
See the CLI help for detailed usage
|
||||
See the CLI help for detailed usage.
|
||||
|
||||
## Service Account Permissions
|
||||
|
||||
@@ -692,6 +692,7 @@ In order from most secure to least secure, the approaches are:
|
||||
|
||||
Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the "kube-system" namespace.
|
||||
To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the "kube-system" namespace.
|
||||
|
||||
NOTE: Enabling this means the "kube-system" namespace contains secrets that grant super-user access to the API.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -5,7 +5,7 @@ metadata:
|
||||
spec:
|
||||
hostNetwork: true
|
||||
containers:
|
||||
- image: gcr.io/google_containers/etcd:2.0.9
|
||||
- image: gcr.io/google_containers/etcd:3.0.17
|
||||
name: etcd-container
|
||||
command:
|
||||
- /usr/local/bin/etcd
|
||||
|
||||
@@ -99,6 +99,7 @@ for `${NODE_IP}` on each machine.
|
||||
#### Validating your cluster
|
||||
|
||||
Once you copy this into all three nodes, you should have a clustered etcd set up. You can validate on master with
|
||||
|
||||
```shell
|
||||
kubectl exec < pod_name > etcdctl member list
|
||||
```
|
||||
@@ -114,8 +115,8 @@ on a different node.
|
||||
|
||||
### Even more reliable storage
|
||||
|
||||
Of course, if you are interested in increased data reliability, there are further options which makes the place where etcd
|
||||
installs it's data even more reliable than regular disks (belts *and* suspenders, ftw!).
|
||||
Of course, if you are interested in increased data reliability, there are further options which make the place where etcd
|
||||
installs its data even more reliable than regular disks (belts *and* suspenders, ftw!).
|
||||
|
||||
If you use a cloud provider, then they usually provide this
|
||||
for you, for example [Persistent Disk](https://cloud.google.com/compute/docs/disks/persistent-disks) on the Google Cloud Platform. These
|
||||
@@ -126,7 +127,7 @@ Alternatively, you can run a clustered file system like Gluster or Ceph. Finall
|
||||
|
||||
Regardless of how you choose to implement it, if you chose to use one of these options, you should make sure that your storage is mounted
|
||||
to each machine. If your storage is shared between the three masters in your cluster, you should create a different directory on the storage
|
||||
for each node. Throughout these instructions, we assume that this storage is mounted to your machine in `/var/etcd/data`
|
||||
for each node. Throughout these instructions, we assume that this storage is mounted to your machine in `/var/etcd/data`.
|
||||
|
||||
## Replicated API Servers
|
||||
|
||||
@@ -164,7 +165,7 @@ in the file.
|
||||
At this point, you should have 3 apiservers all working correctly. If you set up a network load balancer, you should
|
||||
be able to access your cluster via that load balancer, and see traffic balancing between the apiserver instances. Setting
|
||||
up a load balancer will depend on the specifics of your platform, for example instructions for the Google Cloud
|
||||
Platform can be found [here](https://cloud.google.com/compute/docs/load-balancing/)
|
||||
Platform can be found [here](https://cloud.google.com/compute/docs/load-balancing/).
|
||||
|
||||
Note, if you are using authentication, you may need to regenerate your certificate to include the IP address of the balancer,
|
||||
in addition to the IP addresses of the individual nodes.
|
||||
@@ -194,8 +195,7 @@ touch /var/log/kube-scheduler.log
|
||||
touch /var/log/kube-controller-manager.log
|
||||
```
|
||||
|
||||
Next, set up the descriptions of the scheduler and controller manager pods on each node.
|
||||
by copying [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) and [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) into the `/etc/kubernetes/manifests/` directory.
|
||||
Next, set up the descriptions of the scheduler and controller manager pods on each node by copying [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) and [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) into the `/etc/kubernetes/manifests/` directory.
|
||||
|
||||
## Conclusion
|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ steps:
|
||||
is used to authenticate. The control plane will sign this CSR requested
|
||||
automatically.
|
||||
|
||||
1. kubeadm configures the local kubelet to connect to the API server
|
||||
1. kubeadm configures the local kubelet to connect to the API server.
|
||||
|
||||
## Usage
|
||||
|
||||
@@ -211,7 +211,7 @@ set up the Kubernetes master to automatically approve these signing requests.
|
||||
This token is passed in with the `--tls-bootstrap-token abcdef.1234567890abcdef`
|
||||
flag.
|
||||
|
||||
Often times the same token is use for both parts. In this case, the `--token` flag
|
||||
Often times the same token is used for both parts. In this case, the `--token` flag
|
||||
can be used instead of specifying the each token individually.
|
||||
|
||||
Here's an example on how to use it:
|
||||
|
||||
@@ -5,7 +5,7 @@ Initialize a federation control plane
|
||||
### Synopsis
|
||||
|
||||
|
||||
Init initializes a federation control plane.
|
||||
Initialize a federation control plane.
|
||||
|
||||
Federation control plane is hosted inside a Kubernetes
|
||||
cluster. The host cluster must be specified using the
|
||||
|
||||
@@ -70,7 +70,7 @@ kubelet
|
||||
--enable-custom-metrics Support for gathering custom metrics.
|
||||
--enable-debugging-handlers Enables server endpoints for log collection and local running of containers and commands (default true)
|
||||
--enable-server Enable the Kubelet's server (default true)
|
||||
--enforce-node-allocatable stringSlice A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptible options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md for more details. (default [pods])
|
||||
--enforce-node-allocatable stringSlice A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md for more details. (default [pods])
|
||||
--event-burst int32 Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10)
|
||||
--event-qps int32 If > 0, limit event creations per second to this value. If 0, unlimited. (default 5)
|
||||
--eviction-hard string A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default "memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%")
|
||||
|
||||
@@ -15,7 +15,7 @@ incomplete features are referred to in order to better describe service accounts
|
||||
|
||||
## User accounts vs service accounts
|
||||
|
||||
Kubernetes distinguished between the concept of a user account and a service accounts
|
||||
Kubernetes distinguishes between the concept of a user account and a service account
|
||||
for a number of reasons:
|
||||
|
||||
- User accounts are for humans. Service accounts are for processes, which
|
||||
@@ -60,9 +60,9 @@ It acts synchronously to modify pods as they are created or updated. When this p
|
||||
TokenController runs as part of controller-manager. It acts asynchronously. It:
|
||||
|
||||
- observes serviceAccount creation and creates a corresponding Secret to allow API access.
|
||||
- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets
|
||||
- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed
|
||||
- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed
|
||||
- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets.
|
||||
- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed.
|
||||
- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed.
|
||||
|
||||
You must pass a service account private key file to the token controller in the controller-manager by using
|
||||
the `--service-account-private-key-file` option. The private key will be used to sign generated service account tokens.
|
||||
|
||||
Reference in New Issue
Block a user