Search
36 results for “jpetazzo”
-
My module to deploy Kubrnetes clusters on Proxmox using Talos is now documented, and published on github:
https://github.com/jpetazzo/taloprox/
Last step, perhaps write a blog post about all this? 🤔
-
My module to deploy Kubrnetes clusters on Proxmox using Talos is now documented, and published on github:
https://github.com/jpetazzo/taloprox/
Last step, perhaps write a blog post about all this? 🤔
-
My module to deploy Kubrnetes clusters on Proxmox using Talos is now documented, and published on github:
https://github.com/jpetazzo/taloprox/
Last step, perhaps write a blog post about all this? 🤔
-
My module to deploy Kubrnetes clusters on Proxmox using Talos is now documented, and published on github:
https://github.com/jpetazzo/taloprox/
Last step, perhaps write a blog post about all this? 🤔
-
My module to deploy Kubrnetes clusters on Proxmox using Talos is now documented, and published on github:
https://github.com/jpetazzo/taloprox/
Last step, perhaps write a blog post about all this? 🤔
-
@jpetazzo Thanks for your reply.
For now I went a manual uprade path as well. Using hetzner-k3s I install two shell scripts on the node.
One to run the upgrade and check if a reboot is needed for cordon.
2nd to run autoremove and mention uncordon if needed.
Next step would be to use Kured to automate.
Also, indeed, it would be nice if #hetzner would support something like #microos -
La semaine dernière, 1er run d’un nouveau lab « k8s prod-ready clusters from scratch » dans le module M5 de la formation #HighFive d’ Enix.
Formation en 5 semaines pour tout savoir de #Docker et #Kubernetes, construite et animée par 📦️ @jpetazzo.https://www.linkedin.com/posts/lpiot_highfive-docker-kubernetes-activity-7340997777100836864-Kl16
-
Le GitOps, c'est pour les apps, les secrets et l'infrastructure sans exception !
Venez découvrir cela à @devoxxfr :
https://link.davinkevin.fr/AstroGitOps-devoxxfr25-program
N'oubliez pas de mettre en fav ⭐️
-
Good news, everyone (especially me): the issue turned out to be both logical and... not so logical.
Formerly, we were booting the Talos nodes on a disk image coming from the Talos factory. That disk image had all the configuration we wanted; in particular, it had the "nocloud" flavor, meaning: "hey, I'm going to give you a bunch of information - including your IP address - through a particular way - in this case, a tiny filesystem on a virtual block device. But now, we're booting from an ISO image. We can't *run* from an ISO image (although, technically, since Talos is immutable... I guess we should be able to? I wonder if that's possible?), so in the Talos MachineConfig, we pass an "install" block to say, "hey, install Talos on this particular disk". And here, there is an "image" parameter, to tell which image you want to use.
Naively, I thought that omitting this parameter meant "infer the image from the ISO" (i.e., use a nocloud image). I was wrong! It picks a different image. In this case, the "metal" image. And the metal image doesn't give a damn about the nocloud metadata, and just does DHCP in that case. So it makes sense!
...But also... Since I booted from a *nocloud* image, why can't it default to a *nocloud* installer? No idea.
Anyways, I changed my MachineConfig template to include the correct image and now we're back in business. Clusters are up and running.
So now I can go back to writing docs and perhaps publishing this module, ... but also I need to pack for my trip to Tennessee. So we'll see :)
-
Good news, everyone (especially me): the issue turned out to be both logical and... not so logical.
Formerly, we were booting the Talos nodes on a disk image coming from the Talos factory. That disk image had all the configuration we wanted; in particular, it had the "nocloud" flavor, meaning: "hey, I'm going to give you a bunch of information - including your IP address - through a particular way - in this case, a tiny filesystem on a virtual block device. But now, we're booting from an ISO image. We can't *run* from an ISO image (although, technically, since Talos is immutable... I guess we should be able to? I wonder if that's possible?), so in the Talos MachineConfig, we pass an "install" block to say, "hey, install Talos on this particular disk". And here, there is an "image" parameter, to tell which image you want to use.
Naively, I thought that omitting this parameter meant "infer the image from the ISO" (i.e., use a nocloud image). I was wrong! It picks a different image. In this case, the "metal" image. And the metal image doesn't give a damn about the nocloud metadata, and just does DHCP in that case. So it makes sense!
...But also... Since I booted from a *nocloud* image, why can't it default to a *nocloud* installer? No idea.
Anyways, I changed my MachineConfig template to include the correct image and now we're back in business. Clusters are up and running.
So now I can go back to writing docs and perhaps publishing this module, ... but also I need to pack for my trip to Tennessee. So we'll see :)
-
Good news, everyone (especially me): the issue turned out to be both logical and... not so logical.
Formerly, we were booting the Talos nodes on a disk image coming from the Talos factory. That disk image had all the configuration we wanted; in particular, it had the "nocloud" flavor, meaning: "hey, I'm going to give you a bunch of information - including your IP address - through a particular way - in this case, a tiny filesystem on a virtual block device. But now, we're booting from an ISO image. We can't *run* from an ISO image (although, technically, since Talos is immutable... I guess we should be able to? I wonder if that's possible?), so in the Talos MachineConfig, we pass an "install" block to say, "hey, install Talos on this particular disk". And here, there is an "image" parameter, to tell which image you want to use.
Naively, I thought that omitting this parameter meant "infer the image from the ISO" (i.e., use a nocloud image). I was wrong! It picks a different image. In this case, the "metal" image. And the metal image doesn't give a damn about the nocloud metadata, and just does DHCP in that case. So it makes sense!
...But also... Since I booted from a *nocloud* image, why can't it default to a *nocloud* installer? No idea.
Anyways, I changed my MachineConfig template to include the correct image and now we're back in business. Clusters are up and running.
So now I can go back to writing docs and perhaps publishing this module, ... but also I need to pack for my trip to Tennessee. So we'll see :)
-
Good news, everyone (especially me): the issue turned out to be both logical and... not so logical.
Formerly, we were booting the Talos nodes on a disk image coming from the Talos factory. That disk image had all the configuration we wanted; in particular, it had the "nocloud" flavor, meaning: "hey, I'm going to give you a bunch of information - including your IP address - through a particular way - in this case, a tiny filesystem on a virtual block device. But now, we're booting from an ISO image. We can't *run* from an ISO image (although, technically, since Talos is immutable... I guess we should be able to? I wonder if that's possible?), so in the Talos MachineConfig, we pass an "install" block to say, "hey, install Talos on this particular disk". And here, there is an "image" parameter, to tell which image you want to use.
Naively, I thought that omitting this parameter meant "infer the image from the ISO" (i.e., use a nocloud image). I was wrong! It picks a different image. In this case, the "metal" image. And the metal image doesn't give a damn about the nocloud metadata, and just does DHCP in that case. So it makes sense!
...But also... Since I booted from a *nocloud* image, why can't it default to a *nocloud* installer? No idea.
Anyways, I changed my MachineConfig template to include the correct image and now we're back in business. Clusters are up and running.
So now I can go back to writing docs and perhaps publishing this module, ... but also I need to pack for my trip to Tennessee. So we'll see :)
-
Good news, everyone (especially me): the issue turned out to be both logical and... not so logical.
Formerly, we were booting the Talos nodes on a disk image coming from the Talos factory. That disk image had all the configuration we wanted; in particular, it had the "nocloud" flavor, meaning: "hey, I'm going to give you a bunch of information - including your IP address - through a particular way - in this case, a tiny filesystem on a virtual block device. But now, we're booting from an ISO image. We can't *run* from an ISO image (although, technically, since Talos is immutable... I guess we should be able to? I wonder if that's possible?), so in the Talos MachineConfig, we pass an "install" block to say, "hey, install Talos on this particular disk". And here, there is an "image" parameter, to tell which image you want to use.
Naively, I thought that omitting this parameter meant "infer the image from the ISO" (i.e., use a nocloud image). I was wrong! It picks a different image. In this case, the "metal" image. And the metal image doesn't give a damn about the nocloud metadata, and just does DHCP in that case. So it makes sense!
...But also... Since I booted from a *nocloud* image, why can't it default to a *nocloud* installer? No idea.
Anyways, I changed my MachineConfig template to include the correct image and now we're back in business. Clusters are up and running.
So now I can go back to writing docs and perhaps publishing this module, ... but also I need to pack for my trip to Tennessee. So we'll see :)
-
Of course, I can't be trusted to take notes properly, so I haven't properly documented progress on this thread 😅
But here is what happened since last time...
I moved all that to a module that I intend to publish. This led me into investigating how to set default computed values for the module inputs. For instance, I want to be able to specify IPV4 and IPV6 subnets, but if no subnet is specified, I want to pick a random one.
I also added a bunch of documentation.
And then I tested everything using a Proxmox token instead of SSH access, and ... of course it broke, because I was importing a disk image (downloading a raw disk image from the Talos image factory) and that requires SSH access. Because the Proxmox API is annoying like that.
(I didn't think that'd be an issue because that particular feature wasn't listed in the bpg provider under "stuff that requires SSH access".)
So I'm now refactoring everything to install from an ISO image instead (since that doesn't require SSH access), but of course, yak shaving happened: when installing from a Talos image, when the VM reboots, instead of using the static IP address passed by Proxmox in the "nocloud" payload, it's now obtaining an address from DHCP. Which means that cluster bootstrap doesn't work anymore.
I'm now pondering options:
- switching back to raw disk provisioning (and requiring SSH access for my module to work)
- passing IP addresses in the Talos MachineConfig (that should definitely work, right?)
- finding out if there is a way to tell Talos to use the nocloud payload even when rebooting (actually kexec-ing) the disk install
-
Of course, I can't be trusted to take notes properly, so I haven't properly documented progress on this thread 😅
But here is what happened since last time...
I moved all that to a module that I intend to publish. This led me into investigating how to set default computed values for the module inputs. For instance, I want to be able to specify IPV4 and IPV6 subnets, but if no subnet is specified, I want to pick a random one.
I also added a bunch of documentation.
And then I tested everything using a Proxmox token instead of SSH access, and ... of course it broke, because I was importing a disk image (downloading a raw disk image from the Talos image factory) and that requires SSH access. Because the Proxmox API is annoying like that.
(I didn't think that'd be an issue because that particular feature wasn't listed in the bpg provider under "stuff that requires SSH access".)
So I'm now refactoring everything to install from an ISO image instead (since that doesn't require SSH access), but of course, yak shaving happened: when installing from a Talos image, when the VM reboots, instead of using the static IP address passed by Proxmox in the "nocloud" payload, it's now obtaining an address from DHCP. Which means that cluster bootstrap doesn't work anymore.
I'm now pondering options:
- switching back to raw disk provisioning (and requiring SSH access for my module to work)
- passing IP addresses in the Talos MachineConfig (that should definitely work, right?)
- finding out if there is a way to tell Talos to use the nocloud payload even when rebooting (actually kexec-ing) the disk install
-
Of course, I can't be trusted to take notes properly, so I haven't properly documented progress on this thread 😅
But here is what happened since last time...
I moved all that to a module that I intend to publish. This led me into investigating how to set default computed values for the module inputs. For instance, I want to be able to specify IPV4 and IPV6 subnets, but if no subnet is specified, I want to pick a random one.
I also added a bunch of documentation.
And then I tested everything using a Proxmox token instead of SSH access, and ... of course it broke, because I was importing a disk image (downloading a raw disk image from the Talos image factory) and that requires SSH access. Because the Proxmox API is annoying like that.
(I didn't think that'd be an issue because that particular feature wasn't listed in the bpg provider under "stuff that requires SSH access".)
So I'm now refactoring everything to install from an ISO image instead (since that doesn't require SSH access), but of course, yak shaving happened: when installing from a Talos image, when the VM reboots, instead of using the static IP address passed by Proxmox in the "nocloud" payload, it's now obtaining an address from DHCP. Which means that cluster bootstrap doesn't work anymore.
I'm now pondering options:
- switching back to raw disk provisioning (and requiring SSH access for my module to work)
- passing IP addresses in the Talos MachineConfig (that should definitely work, right?)
- finding out if there is a way to tell Talos to use the nocloud payload even when rebooting (actually kexec-ing) the disk install
-
Of course, I can't be trusted to take notes properly, so I haven't properly documented progress on this thread 😅
But here is what happened since last time...
I moved all that to a module that I intend to publish. This led me into investigating how to set default computed values for the module inputs. For instance, I want to be able to specify IPV4 and IPV6 subnets, but if no subnet is specified, I want to pick a random one.
I also added a bunch of documentation.
And then I tested everything using a Proxmox token instead of SSH access, and ... of course it broke, because I was importing a disk image (downloading a raw disk image from the Talos image factory) and that requires SSH access. Because the Proxmox API is annoying like that.
(I didn't think that'd be an issue because that particular feature wasn't listed in the bpg provider under "stuff that requires SSH access".)
So I'm now refactoring everything to install from an ISO image instead (since that doesn't require SSH access), but of course, yak shaving happened: when installing from a Talos image, when the VM reboots, instead of using the static IP address passed by Proxmox in the "nocloud" payload, it's now obtaining an address from DHCP. Which means that cluster bootstrap doesn't work anymore.
I'm now pondering options:
- switching back to raw disk provisioning (and requiring SSH access for my module to work)
- passing IP addresses in the Talos MachineConfig (that should definitely work, right?)
- finding out if there is a way to tell Talos to use the nocloud payload even when rebooting (actually kexec-ing) the disk install
-
Of course, I can't be trusted to take notes properly, so I haven't properly documented progress on this thread 😅
But here is what happened since last time...
I moved all that to a module that I intend to publish. This led me into investigating how to set default computed values for the module inputs. For instance, I want to be able to specify IPV4 and IPV6 subnets, but if no subnet is specified, I want to pick a random one.
I also added a bunch of documentation.
And then I tested everything using a Proxmox token instead of SSH access, and ... of course it broke, because I was importing a disk image (downloading a raw disk image from the Talos image factory) and that requires SSH access. Because the Proxmox API is annoying like that.
(I didn't think that'd be an issue because that particular feature wasn't listed in the bpg provider under "stuff that requires SSH access".)
So I'm now refactoring everything to install from an ISO image instead (since that doesn't require SSH access), but of course, yak shaving happened: when installing from a Talos image, when the VM reboots, instead of using the static IP address passed by Proxmox in the "nocloud" payload, it's now obtaining an address from DHCP. Which means that cluster bootstrap doesn't work anymore.
I'm now pondering options:
- switching back to raw disk provisioning (and requiring SSH access for my module to work)
- passing IP addresses in the Talos MachineConfig (that should definitely work, right?)
- finding out if there is a way to tell Talos to use the nocloud payload even when rebooting (actually kexec-ing) the disk install
-
I received an obvious phishing/scam email, so out of curiosity, I clicked (for the first time ever) on "AI overview" in GMail to see what it'd say about it.
The result will surprise you
(well it really shouldn't)But hey I hope it helped some assclown with their promo packet and maybe landed them a bonus!
-
Let's continue the Proxmox + Tofu + Talos + Cilium adventure, with two little footnotes. "Devil is in the details!"
First: Talos "inlineManifests" behavior.
When you add some inlineManifests to your Talos MachineConfig and push that MachineConfig, the manifests get applied immediately. Yay!
However, when you update or remove some inlineManifests and push the MachineConfig ... Nothing happens. Talos does a full (potentially destructive!) reconcile only when executing a cluster upgrade. (This is pretty well explained in the Talos docs[1])
This means that our initial installation of CIlium will work immediately, but subsequent configuration changes won't work (the YAML won't be applied) until we run a "talosctl upgrade-k8s". (Pro-tip: make sure to specify "--to" with the current k8s version, otherwise it'll execute a "real" upgrade which implies downloading new images and restarting the whole control plane one component at a time - which takes a while.)
So, are we there yet?
Not quite!
The second issue: each time I'd do a "tofu plan", it would tell me that something had changed. Which is kind of annoying. If you don't change your Tofu configuration, variables, etc, normally, you'd expect "tofu plan" to tell you a reassuring:
No changes. Your infrastructure matches the configuration.
So, what is going on? 🤔
-
Also, I want the K8S cluster to support IPV6, which meant replacing Talos' default CNI (Flannel) with Cilium.
(OK, it might be possible to support IPv6 with Flannel on Talos, but the Talos docs say very little about how to customize Flannel, and I wanted Cilium for other reasons too - e.g. LoadBalancer support with L2 announcements, replacing kube-proxy...)
This means declaring "cni: none" in the Talos machine config, and then either:
1) manually installing Cilium after provisioning the cluster
2) finding a way to automatically install Cilium when the cluster is provisioned.
Of course I went for option 2, right :-)
Which leads us to a rabbit hole of multiple options:
1) wait for the cluster to be up (=K8S API is functional) and then use the Helm provider to create a helm_release resource on the cluster
Problem: there is no easy and clean way to wait for the cluster to be up.
Talos has a talos_cluster_health resource, but this one waits for all nodes to be "Ready", which isn't going to happen since the CNI hasn't been deployed yet. (There is a skip_kubernetes_checks option but it doesn't seem to help.)
Declaring something like a kubernetes_nodes resource in Tofu sort of works, ... until you reprovision the cluster. Then you realize that you can't even do a "tofu plan" because Tofu tries to refresh that resources' status, which requires the cluster to be up. So, this is a non-starter.
2) use Talos "inlineManifests" feature, which instructs talos to apply a bunch of YAML to the cluster when it's provisioned
Problem: this requires Cilium YAML manifests; and the way I install it is typically with the Helm chart.
Solution: use a helm_template data source to do the equivalent of the "helm template" command, and render the Cilium chart into ready-to-apply YAML manifests.
Next problem: the Cilium Helm chart is very sophisticated, and depends on Capabilities.KubeVersion - in other words, when we invoke the helm_template resource, we need to pass it the correct kube_version.
Next solution: that version is available in talos_machine_configuration resources.
And with that (and a good amount of Cilium configuration!) our cluster comes up fully functional!
-
Found the common point between century-old blues standards and my homelab AMA
-
Okay, first problem with Flox: there doesn't seem to be an easy / generic way to install it 😅
The install docs (https://flox.dev/docs/install-flox/install/) have links to DEB and RPM packages, as well as instructions for Nix; but I'm on another distro... I suppose step 1 would be to install Nix? 🤔
(Instructions unclear; got my nix stuck in GPU fans)
-
Next talk at #scale23x, we're moving to #planetnix, with "You Know Nix. Your Team Doesn't. Now What?" by Rok Garbas.
IOW, how to usr #Flox to evangelize #Nix / help your coworkers to get on board with Nix but with a gentler learning curve.
-
We'll see how to run popular #LLM on Kubernetes, and how to leverage #Bento, #RabbitMQ, and #PostgreSQL to run requests asynchronously; then we'll use #Prometheus and #Grafana for observability, sprinkle #KEDA for ausoscaling, and some #Helmfile to manage the deployment of all these components.
Interested? Register here:
-
They often fall in this uncanny valley where requests take a bit too long to work well with a #LoadBalancer, but not long enough to justify spinning up #BatchJobs. Fortunately, there is a solution: #MessageQueues!
.../...
-
Dernière après-midi à #Devoxx ; je vais découvrir le #MobProgramming (ou encore #EnsembleProgramming ou #SoftwareTeaming) dans la présentation de Marjorie Aubert et Alexandre Victoor.
L'aspect qui m'intéresse c'est le côté "on-boarding" notamment l'intégration de juniors. Ça va aussi parler de mélange télétravail / sur site, sujet important pour moi aussi 😁
-
...but less great for us, users, since we are facing choices that we don't understand when we're just trying to get started 🫤
Just in case: don't hesitate to ask for help in the Kubernetes slack (#kubeadm channel) or even here. Many folks have suffered similar pains and will be glad to help!
-
It's pretty cool to see that there are still new features coming to #Docker Compose:
https://www.youtube.com/watch?v=KDh8aIwfIac
My favorites for now are "pull_policy: build" (to make --build the default for some services) and "dockerfile_inline" (because yes I often have 2- or 3-line Dockerfiles that I might as well inline in Compose!) but the video has 15 tips, so I'm just scratching the (brace for it) tip of the iceberg here (ho ho)
I'm also keeping an eye on the experimental git stuff!