You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

 Features of an Effective a Developer Environment

  • Convenience and Productive
    • Fast/Easy to install - everthing for development included by default
    • Fast/Easy to start/stop/update/teardown
    • Ability to reproduce and share environments
    • Easy to manipulate multiple instances/environments and operate simultaneously
      • (golden/dev/test/experimental), compare/contrast/diff environments
      • experiment with federation and multi-site deployments in DevEnv
    • Export/Import/shareable instances - reproducable in many contexts
      • Share with others, publish, reproducable environment as part of bug reports, ...
  • Reliability and Isolation
    • Instances isolated from each other and the developers system and from on-line requirements
    • Encapsulated - full environment enclused in the developer environment
      • Run multiple clusters in a laptop in an airplane disconnected from internet
    • Intentional upgrade process - avoid breaking auto-update
    •  (not automated),  encapsulated (minimal dependencies on external system/tools)
  • Accuracy and Portability
    • Represents the 'production' implementation of the system as closely as possible
    • Run in all popular developer laptops/system/OS combinations
      • Windows, Linux, Mac, ...
    • Developments in DevEnv are directly applicable to production systems
    • Support development at all-levels as closely as possible
      • system-level, operations-level, apps, user-facing, and development at all levels
  • Extensibility - Ability to extend and customize the platform as well as the developer environment
    • I.e.  no specific tool or model lock-in, freedom to change
    • Network - emulate multiple physical networks, ability to change k8s network plugins
    • Distributed - Emulate multi-site, multi-instance in dev
      • Federation, Distributed/federated/multi-site/edge-oriented development and testing

 

5 minutes to a running multi-node cluster that can run in your laptop.  VBox machines running CoreOS on host-local networking, not exposed to internet.  Notes below for other options.

Here is the recipe, adapted from the official instructions here: https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html

  1. Install VirtualBox
  2. Install Vagrant
    1. Check vagrant: "vagrant box list"
  3. Install kubectl
    1. curl -O https://storage.googleapis.com/kubernetes-release/release/v1.5.2/bin/linux/amd64/kubectl
    2. install in /usr/local/bin or your favorite spot in your PATH
  4. git clone https://github.com/coreos/coreos-kubernetes.git
  5. cd multinode/vagrant
  6. vagrant box add http://alpha.release.core-os.net/amd64-usr/current/coreos_production_virtualbox.json
    1. will download CoreOS for virtualbox
  7. cp config.rb.sample to config.rb and edit:
    1. Pick the channel and node sizes and counts according to your laptop resources (primarily memory), here's one example:
      $update_channel="alpha"
      $controller_count=1
      $controller_vm_memory=512
      $worker_count=2
      $worker_vm_memory=1024
      $etcd_count=1
      $etcd_vm_memory=512
  8. Good to check your networking for collisions on unrouted address ranges that you'll encounter at work, home, etc.
    1. The default VM network specs are in the Vagrantfile:  172.17.4/24
  9. vagrant up --provider virtualbox

  10. export KUBECONFIG="${KUBECONFIG}:$(pwd)/kubeconfig"

    1. Alt:   Add the config to any existing ~/.kube/config if you are working with multiple clusters and or namespaces (kubectl set-cluster, kubectl set-context, etc.)

  11. Should be operational, some useful commands (use in the multinode/vagrant path)

    1. vagrant ssh c1 (or the other names) to get into coreos

    2. vagrant status

    3. vagrant suspend/resume

      1. Once in a while net doesn't come back, and kubectl says:  

        The connection to the server 172.17.4.101:443 was refused - did you specify the right host or port?

      2. In this case you can vagrant halt, vagrant up

    4. vagrant destroy (obliterates)

      1. Just vagrant up and restart afresh

Enjoy,

D

Notes:

  1. Can be used for volume/fs work by adding VBox disks to nodes.   Kubernetes doesn't have a VBox/vagrant volume driver (yet), so you get raw disk on nodes like we have in OpenStack.

  2. Can be used for ingress/network by adding additional interface to the node to be LB.

  3. It can be left running, or vagrant suspend/resume can freeze/thaw the whole cluster in a few seconds if you want it toiling around in the background.  Can also vagrant halt/up to shutdown/reboot and cluster state (etcd) is preserved.

     

  • No labels