Restructure the Ubuntu Getting Started Section.

- This supercedes PR #1770
 - This breaks up the section from one huge installation page into:
   - A new index page.
   - New support grid with commercial and community support options.
   - Move to lifecycle-based pages based on operational tasks.
     - Add support for local deployments via LXD.
       - Added screenshots to images/docs/ubuntu
     - Add backup page.
     - Add decommissioning page.
     - Add a glossary of terms page.
     - Rewritten installation page.
     - Add logging page.
     - Add monitoring page.
     - Add networking page, flannel only for now, calico in progress.
     - Add a scaling page.
     - Add a security page.
     - Add a storage page.
     - Add a troubleshooting page.
     - Add an upgrade page.
     - Add a cluster validation page.
     - Add new ubuntu content to the index page.
       - Add Ubuntu to _data TOC.
     - Add warning about choosing ipv6 with LXD, thanks Ed Baluf.
     - Template-ize all the pages per jaredb's review.
This commit is contained in:
Jorge O. Castro
2016-11-30 16:59:07 -05:00
parent 586656c027
commit ec5d9b0ec6
25 changed files with 1293 additions and 100 deletions
@@ -0,0 +1,28 @@
---
Title: Glossary and Terminology
---
{% capture overview %}
This page explains some of the terminology used in deploying Kubernetes with Juju.
{% endcapture %}
{% capture prerequisites %}
This page assumes you have a working Juju deployed cluster.
{% endcapture %}
{% capture steps %}
controller - The management node of a cloud environment. Typically you have one controller per cloud region, or more in HA environments. The controller is responsible for managing all subsequent models in a given environment. It contains the Juju API server and its underlying database.
model - A collection of charms and their relationships that define a deployment. This includes machines and units. A controller can host multiple models. It is recommended to seperate Kubernetes clusters into individual models for management and isolation reasons.
charm - The definition of a service, including its metadata, dependencies with other services, required packages, and application management logic. It contains all the operational knowledge of deploying a Kubernetes cluster. Included charm examples are `kubernetes-core`, `easy-rsa`, `kibana`, and `etcd`.
unit - A given instance of a service. These may or may not use up a whole machine, and may be colocated on the same machine. So for example you might have a `kubernetes-worker`, and `filebeat`, and `topbeat` units running on a single machine, but they are three distinct units of different services.
machine - A physical node, these can either be bare metal nodes, or virtual machines provided by a cloud.
{% endcapture %}
{% include templates/task.md %}