[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Raw Kube binaries exposed through OpenShift binary

As of https://github.com/openshift/origin/pull/2294, the raw, untouched core Kube components are exposed via the OpenShift all-in-one binary under the `openshift start kubernetes *` path prefix.  Since Origin is a Kubernetes distribution + the awesome extras for security, builds, deployments, auth, etc, we wanted to make it possible to use it like a Kube component in the event there was a specific need.

Under the `openshift start kubernetes` path you can find the five core Kube components, exposed exactly as they are upstream:

    kube-proxy              -> openshift start kubernetes proxy
    kube-apiserver          -> openshift start kubernetes apiserver
    kubelet                 -> openshift start kubernetes kubelet
    kube-controller-manager -> openshift start kubernetes controller-manager
    kube-scheduler          -> openshift start kubernetes scheduler

If you create a symlink with the name of the upstream component pointing to the binary, OpenShift will automatically start that component.  So a symlink `kube-proxy` that points to the OpenShift binary will start kube-proxy.  kubectl -- already available as `openshift kube` -- is now symlinkable too, so if you symlink `kubectl` -> `openshift`, when you run `kubectl` it will behave as upstream kubectl but with the OpenShift resources exposed.

The components are exposed in their raw form, will all of the upstream defaults and flags.  At this time, your node configuration will *not* apply when you start these components.  In the future we are likely to expose a mode that unifies the OpenShift config files with the components, so that you'll be able to use the node config to apply the selective parts of the node and master config.

An important note - because OpenShift runs secured by default, running individual components may require a bit of elbow grease (part of the value of what openshift node does is apply these defaults sanely, and why we want to make it easier in the future).  You'll at minimum need to apply the correct security certificates that the master expects, but all of the individual pieces *should* be available via flags on the kube* commands to start them.  If you hit problems when trying this out, please let us know.

The development build now creates these symlinks automatically (see _output/local/go/bin/* for a list) so if you add that to your path you can test running those components.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]