Hey folks, thanks a lot for the replies! Sorry for the absence, but I was busy getting married, you know, this kind of stuff is time consuming!
> Are you planning to run the Kubernetes control plane components (API, Scheduler, etc.) on the cluster itself, through Kubernetes? We're not doing that yet, but I'd like to. We're trying to figure out a way to launch a production-ready-like kubernetes cluster to get everyone familiar with the technology without trying to use 'gimmicks' like vagrant. Objective is to deploy labs easily but the same way we do production work. Most people feel like there shouldn't be a lot of work dedicated to bootstrapping production clusters since you usually only do it a couple times but I feel like it's worthy the effort. Gonna check out the links you folks posted! Wasn't aware of those projects! Em quarta-feira, 16 de agosto de 2017 06:09:38 UTC-3, sergiusz...@gmail.com escreveu: > > On Wednesday, August 16, 2017 at 11:04:41 AM UTC+2, sergiusz...@gmail.com > wrote: > > Hey, > > > > In addition to what Alex said (both of us are in the Tectonic Installer > team): > > > > For an automated bootstrap process of k8s components you need to address > two problems besides the infrastructure provisioning part: > > > > 1. executing the deployment on exactly one bootstrap node. We call this > internally "bootstrap master election". This can be solved on: > > > > a) the machine initiating the automated installation by choosing one > machine and simply executing a remote command a la `ssh > user@bootstrap-master bootstrap.sh` where `bootstrap.sh` includes your > `kubectl apply's`. We use terraform to do this for us, see [1]. > > > > b) if the machine initiating the automated installation provisions the > infrastructure, but does not have access to the actual nodes, the election > process is more complex. On AWS for instance we have a small script being > executed on each master which detects whether it is meant to be a bootstrap > node, see [2]. Obviously the detection mechanism depends on the platform. > > > > 2. at-most-once execution on the bootstrap node itself. We solved this > using a simple systemd trick, see [3] and [4] ;-) > > > > I hope that helps a bit. > > > > - > > Sergiusz > > > > [1] > https://github.com/coreos/tectonic-installer/blob/5c4fd74/platforms/metal/remote.tf#L73-L100 > > [2] > https://github.com/coreos/tectonic-installer/blob/5c4fd74/modules/aws/ignition/resources/detect-master.sh > > [3] > https://github.com/coreos/tectonic-installer/blob/5c4fd74/modules/bootkube/resources/bootkube.service#L3 > > [4] > https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionArchitecture= > > > > On Wednesday, August 16, 2017 at 3:52:59 AM UTC+2, Marcelo Andrade wrote: > > > Hey folks! > > > > > > I'm trying to put together some automation on the process of creating > our Kubernetes clusters and I got all the infrastructure/OS/master/nodes > basic installation covered. > > > > > > > > > Then I figured I have no convenient way to automatize the launch of > our several services that already run under Kubernetes > > > > > > > > > Is there a smart to "bootstrap" kubernetes elements on the startup of > the cluster, let's say tthe DNS addon (creating the SA, configmap, > deployment...), the ingress-controller components (deployment for > default-backend, configmaps and so) or whatever client-controlled > deployment? > > > > > > > > > I could work around scripting some kubectls or posts on the API but > then ocurred 'there must be an easier way"... Or there is not? :D > > Whops, my link list is screwed up, sorry about that: > > > [1] > https://github.com/coreos/tectonic-installer/blob/ba2aee9/platforms/metal/remote.tf#L73-L100 > [2] > https://github.com/coreos/tectonic-installer/blob/a9cf682/modules/aws/ignition/resources/detect-master.sh > [3] > https://github.com/coreos/tectonic-installer/blob/5c4fd74/modules/bootkube/resources/bootkube.service#L3 > [4] > https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionArchitecture= > > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
