Hachyderm.io

1 post1 participant0 posts today

beyondwatts<a href="https://beyondwatts.social/tags/Talos" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Talos</a> <a href="https://beyondwatts.social/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> single node cluster up and running with <a href="https://beyondwatts.social/tags/Calico" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Calico</a>, <a href="https://beyondwatts.social/tags/MetalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a>, <a href="https://beyondwatts.social/tags/Traefik" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Traefik</a> and a test <a href="https://beyondwatts.social/tags/whoami" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#whoami</a> deploymentIn no way scientific but it feels much more responsive that <a href="https://beyondwatts.social/tags/microk8s" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#microk8s</a> Next step to rebuild a clean node and then migrate some services

Travis KJ5DCLwawaweewa <a href="https://nangang.travnewmatic.com/tags/cilium" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cilium</a> <a href="https://nangang.travnewmatic.com/tags/ingress" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ingress</a> adventure time!<a href="https://docs.cilium.io/en/stable/network/servicemesh/ingress/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://docs.cilium.io/en/stable/network/servicemesh/ingress/</a> <a href="https://docs.cilium.io/en/stable/network/lb-ipam/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://docs.cilium.io/en/stable/network/lb-ipam/</a>look ma! no <a href="https://nangang.travnewmatic.com/tags/MetalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a> !

makuharigaijinI also ended up replacing my Ubiquiti routers with <a href="https://fosstodon.org/tags/mikrotik" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#mikrotik</a>. I want working load balancing in this cluster, so I have tried out <a href="https://fosstodon.org/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a>. However, I could not get it to work in L2 operating mode with either <a href="https://fosstodon.org/tags/calico" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#calico</a> or <a href="https://fosstodon.org/tags/cilium" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cilium</a>. So, I've overhauled my home network to support BGP in order to have more options. This project keeps getting bigger.

thecodelabMetalLB in Kubernetes claims IP addresses on your existing physical NICs using either ARP or BGP.  The speaker pod responds to ARP requests for service IPs, leveraging the node's existing network interface and MAC address. <a href="https://mastodon.social/tags/Kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Kubernetes</a> <a href="https://mastodon.social/tags/Networking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Networking</a> <a href="https://mastodon.social/tags/BareMetal" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#BareMetal</a> <a href="https://mastodon.social/tags/MetalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a>

thecodelabMetalLB in Kubernetes claims IP addresses on your existing physical NICs using either ARP or BGP. 💡 The MetalLB speaker pod responds to ARP requests for service IPs, leveraging the node's existing network interface and MAC address. <a href="https://mastodon.social/tags/Kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Kubernetes</a> <a href="https://mastodon.social/tags/Networking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Networking</a> <a href="https://mastodon.social/tags/BareMetal" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#BareMetal</a> <a href="https://mastodon.social/tags/MetalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a> <a href="https://mastodon.social/tags/ServiceIP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ServiceIP</a>

Johannes KastlNote to self: When converting a Kubernetes cluster with Cilium as CNI to replace MetalLB with Cilium's new L2 announcements, you need to tweak some settings in your Cilium installation. Especially enabling Cilium to act as a kube-proxy replacement (if you are not already doing so) and enabling the l2 announcements. Which means kube-proxy needs to be disabled in k3s.In other words: k3s on my Raspi4 is now providing a loadbalancer to blocky using Cilium's L2 announcements...<a href="https://digitalcourage.social/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> <a href="https://digitalcourage.social/tags/k3s" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#k3s</a> <a href="https://digitalcourage.social/tags/cilium" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cilium</a> <a href="https://digitalcourage.social/tags/homelab" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#homelab</a> <a href="https://digitalcourage.social/tags/metalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metalLB</a> <a href="https://digitalcourage.social/tags/loadbalancer" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#loadbalancer</a> <a href="https://digitalcourage.social/tags/dns" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#dns</a> <a href="https://digitalcourage.social/tags/blocky" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#blocky</a> <a href="https://digitalcourage.social/tags/hellyeah" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#hellyeah</a>

GilgwathThose who've been reading my toots, might have picked up on the fact that I'm building a <a href="https://social.tchncs.de/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> cluster from scratch (yes, I like pain). After figuring out <a href="https://social.tchncs.de/tags/cri_o" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cri_o</a> <a href="https://social.tchncs.de/tags/calico" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#calico</a> <a href="https://social.tchncs.de/tags/certmanager" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#certmanager</a> <a href="https://social.tchncs.de/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a> <a href="https://social.tchncs.de/tags/traefik" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#traefik</a> and <a href="https://social.tchncs.de/tags/cloudnativepg" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cloudnativepg</a> I finally deployed my first actual application: <a href="https://social.tchncs.de/tags/nextcloud" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#nextcloud</a> ! Wueeh! Extremely stocked! Now I need to figure out how I rope in my ZFS box for persistence, and then I'm ready for a deployment in testing! <a href="https://social.tchncs.de/tags/k8s" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#k8s</a> <a href="https://social.tchncs.de/tags/selfhosting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#selfhosting</a>

xyhhx 🔻 (plz hire me)this week i learned that cilium can do layer 2 advertisement and can act as a load balancer. i'm considering dropping metallb, and instead letting cilium handle that responsibility.does anybody have experience with this kind of setup? this is for a homelab running on proxmox, and it's exposed to the internet using chisel tunnel<a href="https://nso.group/tags/cilium" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cilium</a> <a href="https://nso.group/tags/metalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metalLB</a> <a href="https://nso.group/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> <a href="https://nso.group/tags/networking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#networking</a> <a href="https://nso.group/tags/loadBalancers" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#loadBalancers</a> <a href="https://nso.group/tags/k8s" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#k8s</a> <a href="https://nso.group/tags/homelab" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#homelab</a> <a href="https://nso.group/tags/selfHosting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#selfHosting</a> <a href="https://nso.group/tags/CNI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CNI</a> <a href="https://nso.group/tags/networking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#networking</a> <a href="https://nso.group/tags/BGP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#BGP</a>

h2owasser🌊<a href="https://social.tchncs.de/tags/Kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Kubernetes</a> at home in old and used <a href="https://social.tchncs.de/tags/minipc" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#minipc</a> driven by <a href="https://social.tchncs.de/tags/Talos" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Talos</a> <a href="https://social.tchncs.de/tags/Linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Linux</a> and <a href="https://social.tchncs.de/tags/proxmox" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#proxmox</a>. <a href="https://social.tchncs.de/tags/selfhosted" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#selfhosted</a> <a href="https://social.tchncs.de/tags/quorum" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#quorum</a> <a href="https://social.tchncs.de/tags/Loadbalancer" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Loadbalancer</a> <a href="https://social.tchncs.de/tags/Metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Metallb</a> <a href="https://social.tchncs.de/tags/Devops" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Devops</a> 🖥️12 CPU - 48 GB RAM. Low <a href="https://social.tchncs.de/tags/Power" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Power</a> comsumption.

chihuamaranianI spent today trying to set up <a href="https://tech.lgbt/tags/istio" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#istio</a> and/or <a href="https://tech.lgbt/tags/cilium" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cilium</a> in my <a href="https://tech.lgbt/tags/microk8s" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#microk8s</a> single node cluster. The basic setup works, but falls apart when I try to use either as an ingress. They both want a proper load balancer, and I really dont understand <a href="https://tech.lgbt/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a> enough to troubleshoot that alongside the network mesh alongside the ingress config. Metallb docs assume I have a large range of ips. I just have one computer statically assigned on a home router. I'm out of my depths. <a href="https://tech.lgbt/tags/homelab" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#homelab</a> <a href="https://tech.lgbt/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> <a href="https://tech.lgbt/tags/selfHosted" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#selfHosted</a>

Markus Werle<a href="https://mastodon.online/@vwbusguy" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@vwbusguy</a> I am curious about what you use as <a href="https://nrw.social/tags/Kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Kubernetes</a> Stack, especially which load balancer you prefer for Pods that need their unique IP address. We played around with <a href="https://nrw.social/tags/k3s" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#k3s</a> and <a href="https://nrw.social/tags/MetalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a>, but I would like to know if you prefer other options.

Sean HoodI have this ~weird intermittent issue accessing services on my <a href="https://hachyderm.io/tags/k3s" class="mention hashtag" rel="tag">#k3s</a> box over <a href="https://hachyderm.io/tags/tailscale" class="mention hashtag" rel="tag">#tailscale</a> w/ Subnet routing. I'm running <a href="https://hachyderm.io/tags/metallb" class="mention hashtag" rel="tag">#metallb</a> as the Service type: LoadBalancer. But like sometimes things are fine, others not. If I SSH into the server and use SOCKS all works fine. I can access other services via the subnet router fine too. Mostly rambling for when I figure out wtf is going on and either fix or replace it.Tbh, metallb might be replaced soon with Cilium's L2 Annoucements

GeneBeanI’ve got these bits running in a vm now so next is to add <a href="https://fosstodon.org/tags/Multus" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Multus</a> CNI, kube-vip, & something to provide for load balancer services. I’m going to check out the option in Cilium and see if it’s a good alternative to <a href="https://fosstodon.org/tags/MetalLB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a>. Once that’s sorted, it’s going to be time for <a href="https://fosstodon.org/tags/ArgoCD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ArgoCD</a> & the <a href="https://fosstodon.org/tags/Nginx" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Nginx</a> ingress (ingress-nginx). After that I have a several pieces of the puzzle to finish researching and assembling as a PoC.

Johannes KastlHas anyone used <a href="https://digitalcourage.social/tags/talos" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#talos</a> <a href="https://digitalcourage.social/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> with <a href="https://digitalcourage.social/tags/cilium" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cilium</a> as <a href="https://digitalcourage.social/tags/CNI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CNI</a> and successfully gotten the IPAM part of cilium working? This basically should do what <a href="https://digitalcourage.social/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a> does, announce "additional" IPs via L2 or BGP and provide them as loadbalancer IPs inside the cluster.I have the machine running, cilium is running, I defined the Cilium IPPool and my <a href="https://digitalcourage.social/tags/traefik" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#traefik</a> service got an external IP address from the ippool's range. I have ingressroutes ready and DNS set up for the ingressroute hostnames to point to that IP address.But I cannot reach anything on that IP, curl tells me that it could not connect to the server...Looks like nothing is listening on that IP.

Aaron LongchampsThe good news is that my core problem seems to be fixed: powering down the k8s nodes and powering them back up will not break MetalLB. All the pods (eventually) become healthy in their own sequence and pass traffic.<a href="https://infosec.exchange/tags/homelab" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#homelab</a> <a href="https://infosec.exchange/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> <a href="https://infosec.exchange/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a> <a href="https://infosec.exchange/tags/networking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#networking</a>

Aaron LongchampsFound the easy way to fix this sequencing issue since Kubernetes is an orchestration engine after all. By using a priority class for each piece, I can ask Kubernetes to run the controller first followed by the speaker pods.That being said, I think the scope for these priorities is on a per-node basis. If other nodes are ready to run the DaemonSet pods, they'll run. I might have accidentally got it working by having the controller start before a speaker node for whichever node is running both of them.Scheduling info: <a href="https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/</a><a href="https://infosec.exchange/tags/homelab" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#homelab</a> <a href="https://infosec.exchange/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> <a href="https://infosec.exchange/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a> <a href="https://infosec.exchange/tags/networking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#networking</a>

Aaron LongchampsWell, I'm part of the way there. It seems there's a leftover 'speaker' process as part of the MetalLB service and there's one of these pods that runs on each node. 5 nodes, 5 pods, 1:1 relationship. This is normal.When I boot up my k8s home lab cluster, all 5 of the k8s nodes have unhealthy MetalLB pods with the same error. I don't leave the ESXi host running all the time because it's a whole HPE DL380 Gen9 server, loud fans and all :)Using netstat, I found the offending leftover process using my port, killed that process, deleted the pod (forcing k8s to redeploy it) and then everything was healthy again. This process was also called 'speaker' which tells me it is a part of MetalLB itself.Now what I can't tell is why there seems to be some 'abandoned' process using :7946 when the pod going away means the port usage should also go away. Two processes can't bind to the same port of course, so it has to be something leftover from the last time MetalLB services were running.I might be able to figure out what's going on via k8s or via Linux's own internal mechanisms. I'm not sure which one is the better approach yet.The next question I have is this: if I reboot one of the k8s nodes, does it come up unhealthy again? If so, I'm just going to automate this repair with Ansible, at least in the short term.To really debug this, I would need to track processes as they are launched, ports as they are consumed, line that up with Kubernetes events, and logs from MetalLB containers. This would be a really good use case for a dedicated syslog endpoint that everything sends to.<a href="https://infosec.exchange/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a> <a href="https://infosec.exchange/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> <a href="https://infosec.exchange/tags/opensource" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#opensource</a> <a href="https://infosec.exchange/tags/golang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#golang</a> <a href="https://infosec.exchange/tags/ansible" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ansible</a> <a href="https://infosec.exchange/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#linux</a> <a href="https://infosec.exchange/tags/troubleshooting" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#troubleshooting</a> <a href="https://infosec.exchange/tags/syslog" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#syslog</a>

Aaron LongchampsContemplating digging in to the metallb source code tonight so I can figure out why:1) it always works the first time I install it 2) never works after a shutdown/startup of my homelab k8s environment no matter whatThere's a pretty obvious error about port 7946 being in use so at least it makes sense why it's not starting up. The weird part I still need to figure out is why.Sample part of the error: listen tcp 10.0.1.103:7946: bind: address already in use<a href="https://infosec.exchange/tags/homelab" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#homelab</a> <a href="https://infosec.exchange/tags/kubernetes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetes</a> <a href="https://infosec.exchange/tags/kubernetesnetworking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#kubernetesnetworking</a> <a href="https://infosec.exchange/tags/metallb" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#metallb</a>

MikaI've just merged a huge PR to my <a href="https://sakurajima.social/tags/Orked" rel="nofollow noopener noreferrer" target="_blank">#Orked</a> (O-tomated RKE Distribution - GREAT NAME I KNOW) that makes it easier than ever for anyone to set up a production-ready <a href="https://sakurajima.social/tags/RKE2" rel="nofollow noopener noreferrer" target="_blank">#RKE2</a> <a href="https://sakurajima.social/tags/Kubernetes" rel="nofollow noopener noreferrer" target="_blank">#Kubernetes</a> cluster in their <a href="https://sakurajima.social/tags/homelab" rel="nofollow noopener noreferrer" target="_blank">#homelab</a>. With this collection of scripts, all you need to do is just provision the nodes required, including a login/management node, and run the scripts right from the login node to configure all of the other nodes to make up the cluster. This setup includes: - Configuring the Login node with any required or essential dependencies (such as <a href="https://sakurajima.social/tags/Helm" rel="nofollow noopener noreferrer" target="_blank">#Helm</a>, <a href="https://sakurajima.social/tags/Docker" rel="nofollow noopener noreferrer" target="_blank">#Docker</a>, <a href="https://sakurajima.social/tags/k9s" rel="nofollow noopener noreferrer" target="_blank">#k9s</a>, <a href="https://sakurajima.social/tags/kubens" rel="nofollow noopener noreferrer" target="_blank">#kubens</a>, <a href="https://sakurajima.social/tags/kubectx" rel="nofollow noopener noreferrer" target="_blank">#kubectx</a>, etc.) - Setup passwordless <a href="https://sakurajima.social/tags/SSH" rel="nofollow noopener noreferrer" target="_blank">#SSH</a> access from the Login node to the rest of the Kubernetes nodes - Update the <code>hosts</code> file for strictly necessary name resolution on the Login node and between the Kubernetes nodes - Necessary, best practice configurations for all of the Kubernetes nodes including networking configuration, disabling unnecessary services, disabling swap, loading required modules, etc. - Installation and configuration of RKE2 on all the Kubernetes nodes and joining them together as a cluster - Installation and configuration of <a href="https://sakurajima.social/tags/Longhorn" rel="nofollow noopener noreferrer" target="_blank">#Longhorn</a> storage, including formatting/configuring their virtual disks on the Worker nodes - Deployment and configuration of <a href="https://sakurajima.social/tags/MetalLB" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a> as the cluster's load-balancer - Deployment and configuration of <a href="https://sakurajima.social/tags/Ingress" rel="nofollow noopener noreferrer" target="_blank">#Ingress</a> <a href="https://sakurajima.social/tags/NGINX" rel="nofollow noopener noreferrer" target="_blank">#NGINX</a> as the ingress controller and reverse proxy for the cluster - this helps manage external access to the services in the cluster - Setup and configuration of <a href="https://sakurajima.social/tags/cert-manager" rel="nofollow noopener noreferrer" target="_blank">#cert-manager</a> to obtain and renew <a href="https://sakurajima.social/tags/LetsEncrypt" rel="nofollow noopener noreferrer" target="_blank">#LetsEncrypt</a> certs automatically - supports both <a href="https://sakurajima.social/tags/DNS" rel="nofollow noopener noreferrer" target="_blank">#DNS</a> and HTTP validation with <a href="https://sakurajima.social/tags/Cloudflare" rel="nofollow noopener noreferrer" target="_blank">#Cloudflare</a> - Installation and configuration of <a href="https://sakurajima.social/tags/csi-driver-smb" rel="nofollow noopener noreferrer" target="_blank">#csi-driver-smb</a> which adds support for integrating your external SMB storage to the Kubernetes cluster Besides these, there are also some other helper scripts to make certain related tasks easy such as a script to set a unique static IP address and hostname, and another to toggle <a href="https://sakurajima.social/tags/SELinux" rel="nofollow noopener noreferrer" target="_blank">#SELinux</a> enforcement to on or off - should you need to turn it off (temporarily). If you already have an existing RKE2 cluster, there's a step-by-step guide on how you could use it to easily configure and join additional nodes to your cluster if you're planning on expanding. Orked currently expects and supports <a href="https://sakurajima.social/tags/RockyLinux" rel="nofollow noopener noreferrer" target="_blank">#RockyLinux</a> 8+ (should also support any other <a href="https://sakurajima.social/tags/RHEL" rel="nofollow noopener noreferrer" target="_blank">#RHEL</a> distros such as <a href="https://sakurajima.social/tags/AlmaLinux" rel="nofollow noopener noreferrer" target="_blank">#AlmaLinux</a>), but I am planning to improve the project over time by adding more <a href="https://sakurajima.social/tags/Linux" rel="nofollow noopener noreferrer" target="_blank">#Linux</a> distros, <a href="https://sakurajima.social/tags/IPv6" rel="nofollow noopener noreferrer" target="_blank">#IPv6</a> support, and possibly even <a href="https://sakurajima.social/tags/K3s" rel="nofollow noopener noreferrer" target="_blank">#K3s</a> for a more lightweight <a href="https://sakurajima.social/tags/RaspberryPi" rel="nofollow noopener noreferrer" target="_blank">#RaspberryPi</a> cluster for example. I've used this exact setup to deploy and manage vital services to hundreds of unique clients/organisations that I've become obsessed with sharing it to everyone and making it easier to get started. If this is something that interests you, feel free to check it out! If you're wondering what to deploy on a Kubernetes cluster - feel free to also check out my <a href="https://sakurajima.social/tags/mika" rel="nofollow noopener noreferrer" target="_blank">#mika</a> helm chart repo 🥳 🔗 <a href="https://github.com/irfanhakim-as/orked" rel="nofollow noopener noreferrer" target="_blank">https://github.com/irfanhakim-as/orked</a> 🔗 <a href="https://github.com/irfanhakim-as/charts" rel="nofollow noopener noreferrer" target="_blank">https://github.com/irfanhakim-as/charts</a>

MikaUpdate: I've figured out that I've worse networking knowledge than I thought. For people like me that plans to spin up a secondary <a href="https://sakurajima.social/tags/Kubernetes" rel="nofollow noopener noreferrer" target="_blank">#Kubernetes</a> cluster - also with <a href="https://sakurajima.social/tags/Ingress" rel="nofollow noopener noreferrer" target="_blank">#Ingress</a> support to publish your service online, do the following: 1. Ensure <a href="https://sakurajima.social/tags/MetalLB" rel="nofollow noopener noreferrer" target="_blank">#MetalLB</a> and Ingress <a href="https://sakurajima.social/tags/NGINX" rel="nofollow noopener noreferrer" target="_blank">#NGINX</a> controller have been set up on the cluster, no (port) customisation required - leave them as is 2. Register a domain name on your DNS server i.e. <a href="https://sakurajima.social/tags/Cloudflare" rel="nofollow noopener noreferrer" target="_blank">#Cloudflare</a> pointing towards your public IP (router) - I've a <a href="https://sakurajima.social/tags/Helm" rel="nofollow noopener noreferrer" target="_blank">#Helm</a> <a href="https://github.com/irfanhakim-as/charts/tree/master/mika/cloudflareddns" rel="nofollow noopener noreferrer" target="_blank">chart</a> that automates this which works with non-enterprise networks with dynamic public IP 3. Set up port forwarding on your router for the second cluster - HTTP (wan port: 8080, virtual host port: 80, lan host IP: Cluster 2 loadbalancer IP) and HTTPS (wan port: 8443, virtual host port: 443, lan host IP: Cluster 2 loadbalancer IP) 4. Deploy an ingress for said service as per usual All of these steps are the same for your "primary" Cluster except the different WAN ports since <code>80</code> and <code>443</code> will have been taken by your primary cluster on your router/network. NOW, the thing I've missed thruout this goose chase, is... when you visit that domain you've specified in your service's ingress (in your Cluster 2), please add the custom port you've used (i.e. <code>:8443</code>) at the back... 🙃 Otherwise, ofc you'll get 404 NGINX errors since when you don't append the custom port at the back of the address, it will reach the default/standard ports <code>80</code> (http) or <code>443</code> (https) instead. Jesus, this could've all been avoided if I hadn't went autopilot mode too much in my networking classes years ago. Happy kubernetes-ing everyone.

Recent searches

Search options

Administered by:

Server stats:

#MetalLB