Man the content just keeps getting better and better. No joke the amount of outdated videos out there is insane and its great getting updated information and a fresh perspective. Thank you again and keep up the good work.
This is a great step by step for those who already have some experience. I'm one of these guys who can benefit from this. Thank you so much for sharing!
Appreciate the support! Is there anything specifically you’d like to see with ansible? I was planning on doing istio for the kubernetes cluster after my reverse proxy video but I’d love to get your feedback
Heey thanks for the answer! In Ansible I really enjoy and i thnks there are quite few goood videos of deploying a AWX in an alredy cluster using helm. You can make like a second part with this one about deploying AWX in kubernetes clluster deployed with kubespray@@JamesRhoat
Maybe it was a Docker in Windows thing, but using their kubespray image had its problem with timeouts with the SSH key until i remove my passphrase from it. Another nuance was hostnames needed to be all lowercase and not camel case. Im assuming the goal is to just spin up an instance and get kube running on it with everything on the OS drive, so other cases of using a second bigger drive will need some adapting
Very good and clear outline of the steps required to get a kubernetes cluster up and running on bare metal. But….. And here comes the critique: you did not make your backplane HA, yes you have multiple control-plane nodes but no way to control your cluster when the server where you point to in your .kube/config file goes offline. To achieve true HA, you need to install a loadbalancer and a failover mechanism like VRRP in the form of keepalived on your control-plane nodes to be able to access your kube-api. I always like to use HAProxy and keepaliveD for that. Don’t forget to configure a different name for the kube-api in your kubespray configuration
This is true, I didn’t opt to cover an external load balancer as it is just the configuration file would just need to be updated to point to a node that is still online. But the cluster is still deployed in a stacked ha configuration. When you talk about using HAproxy to load balancing the api server configuration are you hosting that inside the cluster?
@@JamesRhoat fair enough, there's only so much you can cover in a single video. I always like to install HAProxy and keepaliveD directly on the OS, if you deploy it like a regular cluster application you could run into a chicken egg problem, in which you can't access your cluster because there's a problem with the container runtime or in cluster dns, you then would have no way to fixit remotely. Or you can deploy HAProxy and keepaliveD on a separate pair of servers so you can utilize it for other clusters and applications as well.
Hey sorry for the delay I had Covid the last few weeks! They seemed to have finished working on a PR to support this 1.28 release a few months back though the default is still 1.27.7 I haven’t tested this but based on the PR you might just be able to bump the version and attempt to deploy 1.28.3 per the testing here github.com/kubernetes-sigs/kubespray/pull/10390
My cluster is just like your video, Jamas. However, I'm trying a problem with ingress-nginx. It is returning error 404. Could you please clarify why this 404 error occurs, and how to solve it? Thank you.
When you look at your ingress, are you pointing to the appropriate service name? also does your service have endpoints? Also, are you able to get to the default service with an external ip or if you run a kubectl port-forward command?
Hey I’m glad the video helped there is another playbook in their repo called scale, it allows you to add or remove a node from your cluster. I plan on making a video soon to discuss this.
thx for all! i've a problem. my virtual machine have ip in this subnet 192.168.6.0/24. i can't reach 172.16.43.1 ip. i follow you in each steps. please help me
If i understand correctly your home network is 192.168.6.0/24, unless you have a route configured in your network to route to 172.16.43.0/24 you will likely not be able to reach it. Your DHCP server which configures your home network usually only has a range of 192.168.6.1-192.168.6.200 try setting your metallb range to give you a 192.168.6.201-192.168.6.210 range. This will allow you to advertise on the same subnet as your home network and you should be able to access it. However, you should confirm in your router that the dhcp ip range is restricted to a subset of ips, I assume you wouldn't be able to ping something at 192.168.6.201 prior to making this change. The reason this setup works in my homelab is due to me using the 172.16.0.0/12 IP address space: 172.16.0.0 - 172.31.255.255
