Skip to content

Proposal to rework Kubernetes deployment CLI #5472

@zmerlynn

Description

@zmerlynn

The following is a proposal for reworking the existing kube-up.sh, kube-down.sh, and kube-push.sh to eventually be in Go for advanced cloud deployments, while allowing the existing shell investment to continue for a period of time.

  • Define a deploy/deploycmd/api versioned Cluster object. This object holds all general configuration variables of the cluster and the add-on pods, plus IAAS relevant variables specific to each IAAS provider. (Issue to be filed soon to haggle over what's in these structures.)
  • Create a kubedeploy command with up, down, and push verbs, each of which take a cluster YAML. The up and push verbs take a path (possibly optional in the case of push) to the Kubernetes binaries to deploy.
  • The initial implementation of kubedeploy only has to act as a YAML -> env variable translator. Re-write the existing shell scripts to use common env variables (they're actually all close, e.g. config-default.sh, etc.). Then kubedeploy can take the given API object, spew a chunk of environment variables, and carefully execute the existing bash scripts (vigorous handwaving, but this part is not that technically challenging, just a hairy yak).
  • We can then define the interfaces in Go for what an "enlightened" deployment looks like, and in the process try to transition the GCE cloud provider over (keeping an eye on, say, Vagrant as the N=2 case.)

As an added benefit, the last bullet gives us a place to start upstreaming GKE cluster deployment code, which has been a desire for the GKE team for a while. Oh, and @satnam6502 will probably love it for scalability, because I think he gouges his eyes out every time he deals with the bash in util.sh.

This will also give us a place for kubedeploy upgrade in the fullness of time, which is a distinct use case from push.

Thoughts?

cc @jlowdermilk, @brendandburns, @alex-mohr, and anyone else that cares.

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.sig/cluster-lifecycleCategorizes an issue or PR as relevant to SIG Cluster Lifecycle.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions