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

Update allow-privileged info for Ubuntu, add docker registry section (#3207)

Browse Source 
* Update allow-privileged info for Ubuntu, add docker registry section

* Clean up wording in ubuntu/operational-considerations
This commit is contained in:
Cynerva
2017-04-06 15:40:28 -05:00
committed by Andrew Chen
parent 34cd28dbf6
commit e469ebe322
1 changed files with 28 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/getting-started-guides/ubuntu/operational-considerations.md
+27 -21
View File
@@ -116,42 +116,48 @@ juju switch default
### Running privileged containers ### Running privileged containers
By default juju-deployed clusters do not support running privileged containers. If you need them, you have to edit ```/etc/default/kube-apiserver``` on the master nodes, and ```/etc/default/kubelet``` on your worker nodes. By default, juju-deployed clusters do not support running privileged containers.
If you need them, you have to enable the ```allow-privileged``` config on both
On Kubernetes Core or on small deployment, run the following commands from the Juju client: kubernetes-master and kubernetes-worker:
#### Manually
1. Update the Master
``` ```
juju ssh kubernetes-master/0 "sudo sed -i 's/KUBE_API_ARGS=\"/KUBE_API_ARGS=\"--allow-privileged\ /' /etc/default/kube-apiserver && sudo systemctl restart kube-apiserver.service" juju config kubernetes-master allow-privileged=true
juju config kubernetes-worker allow-privileged=true
``` ```
2. Update the Worker(s) ### Private registry
With the registry action, you can easily create a private docker registry that
uses TLS authentication. However, note that a registry deployed with that action
is not HA; it uses storage tied to the kubernetes node where the pod is running.
Consequently, if the registry pod is migrated from one node to another, you will
need to re-publish the images.
#### Example usage
Create the relevant authentication files. Let's say you want user ```userA```
to authenticate with the password ```passwordA```. Then you'll do:
``` ```
juju ssh kubernetes-worker/0 "sudo sed -i 's/KUBELET_ARGS=\"/KUBELET_ARGS=\"--allow-privileged\ /' /etc/default/kubelet && sudo systemctl restart kubelet.service" echo "userA:passwordA" > htpasswd-plain
htpasswd -c -b -B htpasswd userA passwordA
``` ```
#### Programmatically (the `htpasswd` program comes with the ```apache2-utils``` package)
If the deployment is larger the following commands will run on all units successively: Assuming that your registry will be reachable at ```myregistry.company.com```,
you already have your TLS key in the ```registry.key``` file, and your TLS
1. Update all Masters certificate (with ```myregistry.company.com``` as Common Name) in the
```registry.crt``` file, you would then run:
``` ```
juju show-status kubernetes-master --format json | \ juju run-action kubernetes-worker/0 registry domain=myregistry.company.com htpasswd="$(base64 -w0 htpasswd)" htpasswd-plain="$(base64 -w0 htpasswd-plain)" tlscert="$(base64 -w0 registry.crt)" tlskey="$(base64 -w0 registry.key)" ingress=true
jq --raw-output '.applications."kubernetes-master".units | keys[]' | \
xargs -I UNIT juju ssh UNIT "sudo sed -i 's/KUBE_API_ARGS=\"/KUBE_API_ARGS=\"--allow-privileged\ /' /etc/default/kube-apiserver && sudo systemctl restart kube-apiserver.service"
``` ```
2. Update all workers If you then decide that you want do delete the registry, just run:
``` ```
juju show-status kubernetes-worker --format json | \ juju run-action kubernetes-worker/0 registry delete=true ingress=true
jq --raw-output '.applications."kubernetes-worker".units | keys[]' | \
xargs -I UNIT juju ssh UNIT "sudo sed -i 's/KUBELET_ARGS=\"/KUBELET_ARGS=\"--allow-privileged\ /' /etc/default/kubelet && sudo systemctl restart kubelet.service"
``` ```