Home • Explore • Blog • CI
☰



kubernetes
2nd chunk of `content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout.md`
4bdde6284a2b5fb10aab3b2ccfd1061ec433296682237fd90000000100000c95
        * Uses a jinja2 template
	* Create machines with minimal software, then use ansible to get that machine into a runnable state
        * Sets up all of the add-ons
    * Eliminates the provisioner shell scripts
    * Full cluster setup currently takes about 6 minutes
        * CentOS with some packages
        * Redeploy to the cluster takes 25 seconds
    * Questions for Eric
        * Where does the provider-specific configuration go?
            * The only network setup that the ansible config does is flannel; you can turn it off
        * What about init vs. systemd?
            * Should be able to support in the code w/o any trouble (not yet implemented)
    * Discussion
        * Why not push the setup work into containers or kubernetes config?
            * To bootstrap a cluster drop a kubelet and a manifest
        * Running a kubelet and configuring the network should be the only things required. We can cut a machine image that is preconfigured minus the data package (certs, etc)
            * The ansible scripts install kubelet & docker if they aren’t already installed
        * Each OS (RedHat, Debian, Ubuntu) could have a different image. We could view this as part of the build process instead of the install process.
        * There needs to be solution for bare metal as well.
        * In favor of the overall goal -- reducing the special configuration in the salt configuration
        * Everything except the kubelet should run inside a container (eventually the kubelet should as well)
            * Running in a container doesn’t cut down on the complexity that we currently have
            * But it does more clearly define the interface about what the code expects
        * These tools (Chef, Puppet, Ansible) conflate binary distribution with configuration
            * Containers more clearly separate these problems
        * The mesos deployment is not completely automated yet, but the mesos deployment is completely different: kubelets get put on top on an existing mesos cluster
            * The bash scripts allow the mesos devs to see what each cloud provider is doing and re-use the relevant bits
            * There was a large reverse engineering curve, but the bash is at least readable as opposed to the salt
        * Openstack uses a different deployment as well
        * We need a well documented list of steps (e.g. create certs) that are necessary to stand up a cluster
            * This would allow us to compare across cloud providers
            * We should reduce the number of steps as much as possible
            * Ansible has 241 steps to launch a cluster
* 1.0 Code freeze
    * How are we getting out of code freeze?
    * This is a topic for next week, but the preview is that we will move slowly rather than totally opening the firehose
        * We want to clear the backlog as fast as possible while maintaining stability both on HEAD and on the 1.0 branch
        * The backlog of almost 300 PRs but there are also various parallel feature branches that have been developed during the freeze
    * Cutting a cherry pick release today (1.0.1) that fixes a few issues
    * Next week we will discuss the cadence for patch releases
Title: Continued Discussion on Ansible, 1.0 Code Freeze
Summary
The discussion continued on using Ansible for cluster setup, covering topics like provider-specific configurations, init vs. systemd support, and the possibility of using containers to reduce complexity. There was also a discussion on the steps required to stand up a cluster and the need for a well-documented list. The second topic covered was the 1.0 code freeze and the plan to slowly release new code while maintaining stability, with a cherry-pick release (1.0.1) planned for today.