modified: docs/getting-started-guides/ubuntu/index.md

* adding Operational Considerations section
modified:   docs/getting-started-guides/ubuntu/logging.md
	* Moving logging section from operational-considerations.md to logging.md
renamed:    docs/getting-started-guides/ubuntu/operations.md -> docs/getting-started-guides/ubuntu/operational-considerations.md
	* mapping to the proposed name
	* ditched CDK naming in favor of k8s or cluster
	* add whitelines for titles
This commit is contained in:
Samuel Cozannet
2017-01-24 10:28:24 +01:00
committed by Andrew Chen
parent 6f1c745bb6
commit 147bb4cf02
3 changed files with 49 additions and 44 deletions
@@ -43,6 +43,7 @@ These are more in-depth guides for users choosing to run Kubernetes in productio
- [Storage](/docs/getting-started-guides/ubuntu/storage)
- [Troubleshooting](/docs/getting-started-guides/ubuntu/troubleshooting)
- [Decommissioning](/docs/getting-started-guides/ubuntu/decommissioning)
- [Operational Considerations](/docs/getting-started-guides/ubuntu/operational-considerations)
- [Glossary](/docs/getting-started-guides/ubuntu/glossary)
## Developer Guides
@@ -18,3 +18,43 @@ The `juju debug-log` will show all of the consolidated logs of all the Juju agen
See the [Juju documentation](https://jujucharms.com/docs/stable/troubleshooting-logs) for more information.
## Managing log verbosity
Log verbosity in Juju is set at the model level. You can adjust it at any time:
```
juju add-model k8s-development --config logging-config='<root>=DEBUG;unit=DEBUG'
```
and later
```
juju config-model k8s-production --config logging-config='<root>=ERROR;unit=ERROR'
```
In addition, the jujud daemon is started in debug mode by default on all controllers. To remove that behavior edit ```/var/lib/juju/init/jujud-machine-0/exec-start.sh``` on the controller node and comment the ```--debug``` section.
It then contains:
```
#!/usr/bin/env bash
# Set up logging.
touch '/var/log/juju/machine-0.log'
chown syslog:syslog '/var/log/juju/machine-0.log'
chmod 0600 '/var/log/juju/machine-0.log'
exec >> '/var/log/juju/machine-0.log'
exec 2>&1
# Run the script.
'/var/lib/juju/tools/machine-0/jujud' machine --data-dir '/var/lib/juju' --machine-id 0 # --debug
```
Then restart the service with:
```
sudo systemctl restart jujud-machine-0.service
```
See the [official documentation](https://jujucharms.com/docs/stable/models-config) for more information about logging and other model settings in Juju.
@@ -1,16 +1,18 @@
---
title: Operations
title: Operational Considerations
---
{% capture overview %}
This page gives recommendations and hints for people managing long lived CDK clusters
This page gives recommendations and hints for people managing long lived clusters
{% endcapture %}
{% capture prerequisites %}
This page assumes you understand the basics of Juju and Kubernetes.
{% endcapture %}
{% capture steps %}
## Managing Juju
### Sizing your controller node
The Juju Controller:
@@ -27,6 +29,8 @@ juju bootstrap --contraints "mem=8GB cpu-cores=4 root-disk=128G"
Juju will elect the cheapest instance type matching your constraints on your target cloud. You can also use the ```instance-type``` constraint in conjunction with ```root-disk``` for strict control. For more information about the constraints available, refer to the [official documentation](https://jujucharms.com/docs/stable/reference-constraints)
Additional information about logging can be found in the [logging section](/docs/getting-started-guides/ubuntu/logging)
### Connecting on the Controller Node
By default, Juju will create a pair of SSH key that it will use to automate the connection to units. They are stored on the client node in ```~/.local/share/juju/ssh/```
@@ -39,51 +43,11 @@ ssh -i ./.local/share/juju/ssh/juju_id_rsa ubuntu@<public-ip-of-juju-controller>
where ```public-ip-of-juju-controller``` can be found in ```~/.local/share/juju/controllers.yaml``` in the ```api-endpoints``` section.
### Restricting log verbosity
Log verbosity in Juju is set at the model level. You can adjust it at any time:
```
juju add-model cdk-development --config logging-config='<root>=DEBUG;unit=DEBUG'
```
and later
```
juju config-model cdk-production --config logging-config='<root>=ERROR;unit=ERROR'
```
In addition, the jujud daemon is started in debug mode by default on all controllers. To remove that behavior edit ```/var/lib/juju/init/jujud-machine-0/exec-start.sh``` on the controller node and comment the ```--debug``` section.
It will then look like:
```
#!/usr/bin/env bash
# Set up logging.
touch '/var/log/juju/machine-0.log'
chown syslog:syslog '/var/log/juju/machine-0.log'
chmod 0600 '/var/log/juju/machine-0.log'
exec >> '/var/log/juju/machine-0.log'
exec 2>&1
# Run the script.
'/var/lib/juju/tools/machine-0/jujud' machine --data-dir '/var/lib/juju' --machine-id 0 # --debug
```
Then restart the service with:
```
sudo systemctl restart jujud-machine-0.service
```
See the [official documentation](https://jujucharms.com/docs/stable/models-config) for more information about logging and other model settings in Juju.
## Managing your Kubernetes cluster
### Running privileged containers
By default CDK does 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 edit ```/etc/default/kube-apiserver``` on the master nodes, and ```/etc/default/kubelet``` on your worker nodes.
On Kubernetes Core or on small deployment, run the following commands from the Juju client: