kubeadm feature flags
mikedanese opened this issue · 15 comments
From @bogdando on October 19, 2016 16:32
FEATURE REQUEST:
Add runtime/config feature flags for granular control of kubeadm init tasks. Like:
- etcd clustering,
- certs management,
- container images pulling,
- configs generation,
- static pods definitions for system components,
- essential addons installation.
Use case:
One may want to use hyperkube and do not pull images for apiserver and other components.
Or one may want to only run certs management tasks, or only re-generate configs or static manifests pods or only install addons. Having feature flags eases idempotent runs, co-existing with external CM systems like ansible or puppet and integration testing efforts a lot.
The feature flags, either CLI or config file based, should ease integration efforts and make the tool more flexible as well.
Related feature #11
Kubernetes version (use kubectl version): next
Environment:
- Cloud provider or hardware configuration: any
- OS (e.g. from /etc/os-release): any
- Kernel (e.g.
uname -a): any - Install tools: n/a
- Others: n/a
Copied from original issue: kubernetes/kubernetes#35133
From @lukemarsden on October 20, 2016 10:13
Thank you for this @bogdando! We definitely want to make kubeadm support your use-case in kargo. We have just merged support for kubeadm init to read config from a file which will make it easier to add this level of granular control without making the user-facing CLI totally insane. I'll add discussion of this topic to the next SIG-cluster-lifecycle meeting next Tuesday at 9am, could you join that?
From @bogdando on October 20, 2016 10:31
@lukemarsden thank you, I will
From @bogdando on October 24, 2016 14:1
Also note that while being configurable is very nice to have, runtime flags must allow to specify which steps a user wants the kubeadm init do for him and which do not
From @bogdando on October 27, 2016 11:13
This is now tracked as kubernetes/enhancements#138
From @pires on October 27, 2016 16:16
Just to add to what Luke said, there's file configuration support for kubeadm join as well.
From @bogdando on October 28, 2016 14:4
Reopened as there is yet another optional place to track it
@mikedanese
I traced your comments regard the porthost issue which I faced recently (AWS env), is there any workaround for this? How to expose service external IP to public if it can't communicate locally. I defined nodeport but that wasn't helpful.
@aisarmog That issue isn't handled here, please open a new one if you still have issues.
@mikedanese thanks for working on this spec.
Heads up! I still believe that feature flags should be runtime flags. And that's why:
Taco Bell programming is known for using tones of flags for decades, and it just works.
Config options suxx in containers world: you have to mount them as files/configmaps, take care of multiple RW access (data integrity), notifications of the main process on changes etc.
While runtime flags .. just work.
(and I think that's why there is so much runtime flags in kubelet and so none as config options. So why not kubedam to follow kubelet design decisions?)
Please update the "Related feature kubernetes/enhancements#11" the original description contains wrong link
We are trying to be consistent by standardizing on file based config. We are migrating all components to file based config. kubernetes/kubernetes#12245
why there is so much runtime flags in kubelet and so none as config options
Kubelet and other components already do support file based config
@wilkers-steve and @larryrensing; can you guys reach out to @mikedanese to find out how we can start getting involved and help with things like this? if there are any gaps, i'd like to work with the kubeadm team to close them.
@v1k0d3n you got it
This is implemented with kubeadm phases, closing in favor for the other issues we have for that command...