This is the start of an official admin guide.

DNS

The Labs Workbench service requires wildcard DNS entries and a wildcard TLS certificate.  Steps for requesting both can be found in Requesting wildcard DNS and TLS.

Scalable Multi-node Installation

Prerequisites:

  • Docker must be installed
  • You must be on the same network to which you are deploying
    • For example, in OpenStack you must be SSH'd into a node in the same project and on the same network

Before Deploying:

  • Request TLS certs / DNS
  • Verify MTU settings in roles/coreos-ndslabs-devsystem/files/10-docker0.conf
  • Verify volume sizes in inventory/group_vars/cluster.yml
  • Verify NGINX ConfigMap (for example, max body size)

Deployment Steps:

  • See  NDS-312 - Getting issue details... STATUS

After Deploying:

  • Import or mount existing data / configuration
  • Create any accounts necessary (i.e. for workshops)

    • See  NDS-898 - Getting issue details... STATUS

  • Cache all images on all nodes

    • docker pull <image_name>

Optional Steps for Large-Scale Deployments

Depending on the contents of your inventory, our deployment process can offer several ways to scale up the resulting cluster according to your current needs.

Enabling GlusterFS Shared Storage

In your inventory, defining a [glfs] group and adding 2 of your compute nodes to it will deploy GlusterFS shared storage across all cluster nodes. Without this group, no shared storage will be mounted to all compute nodes.

Deploying dedicated GLFS nodes

Instead of adding compute nodes to the [glfs] group, you can define unique nodes there. This will result in deploying dedicated nodes to run your GlusterFS server pods. 

Deploying a dedicated LoadBalancer node

By default, one compute node is used as the loadbalancer. If you wish to run a dedicated node for this critical service, you can define a [loadbal] group in your inventory and add a unique node to it. This will deploy an isolated node that will run the ingress loadbalancer.

NOTE: This node will be the only one given a public IP

Deploying a dedicated LMA node

In your inventory, defining a [lma] group and adding a unique node to it will deploy an isolated node that will run the ingress loadbalancer.

Resizing the Cluster

To create new nodes: Modify your inventory, and re-run all 3 playbooks to provision any nodes that were not already present
To delete old nodes: Piecewise deletions must be performed via the OpenStack Horizon dashboard
To delete ALL nodes: Run the openstack-delete.yml ansible playbook to clean up all resources created by the deployment scripts (no SSH keys will be automatically deleted)

Single-node via Hyperkube (Development Only)

Prerequisites:

  • Docker must be installed

Before Deployment:

  • Request TLS certs / DNS
  • Provision VM (volume-backed instance is best)
  • Provision and mount storage volume
    • Data for Workbench
    • /var/lib/kubelet, /var/lib/docker, /var/log

Deployment Steps:

After Deployment:

  • Import or mount existing data / configuration

  • Create any accounts necessary (i.e. for workshops)

    • See NDS-898 - Getting issue details... STATUS

  • Ensure that a basic auth secret exists for all accounts
    • kubectl get secret --all-namespaces

  • Cache all images

Verifying Cluster Configuration

  • Verify MTU settings.. docker0 / flannel should be ~50 lower than eth0
    • ifconfig | grep mtu
  • Verify NGINX ConfigMap (for example, max body size)
    • kubectl get -o yaml cm nginx-ingress-conf

  • Verify node labels and flavors/sizes

    • kubectl get nodes -o yaml | grep abel
  • Verify that all service specs expected are in the catalog
  • Verify that all catalog services have sane resource limits set 
  • Write some tutorials / examples for usage of the new instance
    • for example, is there anything new that is specific to this instance? new services, new features, etc

  • Smoke test all relevant services (run through the tutorials above)

  • No labels