[opensuse-kubic] deployment questions
Have a few questions around possible deployment options ... a) Can one effectively do a multi-arch cluster deployment, say some x86_64 and some aarch64 nodes? - this might be relevant mostly to have designated (labeled) worker nodes of the respective variety for targeted workloads b) Parallel to above, would it be possible, given the kubeadm-based approach to include a worker node based on another Linux (with Kubernetes installed) distribution? - as above, this might enable usage of other enabled devices like Jetson/RPi4 which don't yet have openSUSE images available c) From the https://en.opensuse.org/Kubic:kubeadm wiki page, it cites being able to have a single master node (and untaint to allow workload scheduling there). For edge computing (aka gateways), this might be a quite valid usage scenario. Other than potential resource conflicts of such a single node "cluster", any other considerations/caveats? And a couple of issues ... 1) on the same wiki page cited above, for Cilium it cites using /usr/share/k8s-yaml/cilium/cilium.yaml but the file currently residing there is /usr/share/k8s-yaml/cilium/quick-install.yaml. Is this the correct one to now use? 2) for some reason, all of the nodes in a recent deployed cluster show Status = NotReady (which may be related to previously listed issue and my assumption to use the file in that directory), since kubectl describe node <name> shows an error ... "Missing CNI default network" Thanks for any help / guidance -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
Any feedback/answers on these questions ?
On Mon, Nov 18, 2019 at 10:02 AM Bryan Gartner
Have a few questions around possible deployment options ...
a) Can one effectively do a multi-arch cluster deployment, say some x86_64 and some aarch64 nodes?
- this might be relevant mostly to have designated (labeled) worker nodes of the respective variety for targeted workloads
b) Parallel to above, would it be possible, given the kubeadm-based approach to include a worker node based on another Linux (with Kubernetes installed) distribution?
- as above, this might enable usage of other enabled devices like Jetson/RPi4 which don't yet have openSUSE images available
c) From the https://en.opensuse.org/Kubic:kubeadm wiki page, it cites being able to have a single master node (and untaint to allow workload scheduling there). For edge computing (aka gateways), this might be a quite valid usage scenario. Other than potential resource conflicts of such a single node "cluster", any other considerations/caveats?
And a couple of issues ...
1) on the same wiki page cited above, for Cilium it cites using /usr/share/k8s-yaml/cilium/cilium.yaml but the file currently residing there is /usr/share/k8s-yaml/cilium/quick-install.yaml. Is this the correct one to now use?
2) for some reason, all of the nodes in a recent deployed cluster show Status = NotReady (which may be related to previously listed issue and my assumption to use the file in that directory), since kubectl describe node <name> shows an error ... "Missing CNI default network"
Thanks for any help / guidance
-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
On Mon, Nov 18, Bryan Gartner wrote:
Have a few questions around possible deployment options ...
a) Can one effectively do a multi-arch cluster deployment, say some x86_64 and some aarch64 nodes?
No idea. Just try it.
- this might be relevant mostly to have designated (labeled) worker nodes of the respective variety for targeted workloads
b) Parallel to above, would it be possible, given the kubeadm-based approach to include a worker node based on another Linux (with Kubernetes installed) distribution?
As long as kubeadm/kubelet have the same version as the rest of the cluster: nobody cares about the underlying OS, so yes, this should work.
- as above, this might enable usage of other enabled devices like Jetson/RPi4 which don't yet have openSUSE images available
c) From the https://en.opensuse.org/Kubic:kubeadm wiki page, it cites being able to have a single master node (and untaint to allow workload scheduling there). For edge computing (aka gateways), this might be a quite valid usage scenario. Other than potential resource conflicts of such a single node "cluster", any other considerations/caveats?
And a couple of issues ...
1) on the same wiki page cited above, for Cilium it cites using /usr/share/k8s-yaml/cilium/cilium.yaml but the file currently residing there is /usr/share/k8s-yaml/cilium/quick-install.yaml. Is this the correct one to now use?
As already written on this list: cilium is currently broken and it's a lot of work to get it building correct again. No idea how far we are with this.
2) for some reason, all of the nodes in a recent deployed cluster show Status = NotReady (which may be related to previously listed issue and my assumption to use the file in that directory), since kubectl describe node <name> shows an error ... "Missing CNI default network"
"Missing CNI default network" means you haven't installed one. Seems you missed a step in the setup or made a mistake somewhere. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
On Tue, Dec 10, 2019 at 10:43:56AM -0700, Bryan Gartner wrote:
Any feedback/answers on these questions ?
The wiki page https://en.opensuse.org/Kubic:kubeadm has an information that Cilium is currently broken. We are sorry of that and I'm working on fixing it. There is a separate topic on the list about that: https://lists.opensuse.org/opensuse-kubic/2019-11/msg00006.html Michal -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
participants (3)
-
Bryan Gartner -
Michal Rostecki -
Thorsten Kukuk