Timely! We were just looking over some clusters today and noticed the Fleet logo. The team has opted to use Flux for now, since the clusters may not be operated by us, but we want to deploy a standard set of tools to all clusters anyway, which flux seems to be a good fit for. Thanks for all that you do Viktor!
Thanks for this great introduction! To me this is a product that I need to look deeper into since it looks like a great fit for my next project! I like the way you are talking about the products you test and that you just don't want to sell but also show the cons (like empty events during problems and working with typical kustomize structures, no drift or reconciliation!).
As always your videos are absolutely on new knowledge thanks for keeping me updated with new and latest technology with respect to DevOps Can you please make a video on GitOps on GKE autopilot private cluster please that will be pretty helpful
I don't think that GitOps in a private cluster based on GKE Autopilot would be any different from other types. Since GitOps tools are polling information from Git, clusters can be locked so being private is not an issue, and using Autopilot does not change how we define manifests and store them in Git (beyond a few minor things). So, I'm not sure whether "GitOps on GKE autopilot private cluster" would be any different from GitOps on any other type of k8s cluster. That being said, if you're facing any specific problem with Autopilot and GitOps, I'd be more than happy to help. Feel free to ping me on Slack/Twitter/LinkedIn or, even better, join the AMA or monthly chats and we can discuss it.
I'm facing some technical difficulty to set-up or install Argo CD or any GitOps tools on GKE autopilot private cluster if you please demonstrate how it can be setup it would be very helpful and I'll appreciate that ❤️
Thanks, awesome review!! I agree with all comments above. In my case I don't really like the idea to put all the configuration for different environemts into the same file, maybe I am very use to have different folders or branches per environment... it could grow a lot if you have a lot of clusters that not share the same settings.
@@DevOpsToolkit I really like the idea of using tags instead folders and hierarchy for matching the configuration, it is more flexible. The folder structure has been used for so long, like hiera, terragrunt and other tools...
Nice video once more. I'm planning for scale (at some point) and was wondering about the following scenario. The plan is to have tenants running in different "pods". Pods not in the k8s sense, but more in the sense of an area of compute power, but only with one provider. Pods can be found on different providers though. Pods would be containing or connected to a lot of services needed for the tenant applications to run (databases, storage, ingress controlling, etc). The tenant applications, and there can be any number of applications per tenant, would be "spread out" across these named "pods". The tenants themselves would have both dev (which may include staging) and production instances of their apps. There could be any number of tenants in each of these pods (to save on compute resource). So, I'm thinking these named pods fit into the target names/ labels used in Fleet. But, they could be broken down even more, so instead of just "production" and "dev", there could be "pod-1", "pod-2" etc. and they could be broken down further as "pod-1-prod", "pod-2-prod" and "pod-1-dev", "pod-2-dev", etc. etc. Does that make sense? If yes, how scalable is that? Imagine 1000s of git repos being the source of truth for 1000s of Fleet managed cluster targets.
To begin with, if you're not using different clusters for tenants, I strongly recommend exploring vCluster (th-cam.com/video/JqBjpvp268Y/w-d-xo.html). Now, I'm not sure I fully understood what you're trying to do. Is each tenant having completelly different set of apps? If that's the case, Rancher Fleet will not be any better than, let's say Argo CD or Flux. On the other hand, if you're having the same apps deployed across multiple tenants residing in different clusters, virtual clusters, or Namespaces, than Fleet might indeed be a good option. However, if that's the case, I'm not sure why would you have 1000s of repos.
Hi, thank you for the video. Id like to ask you why the Fleet and not Argo cd is the choice, when handling multiple clusters. What is the main cons for Argo cd in this scenario. New in the field, trying to learn as much as I can from you :)
Argo CD is based on the idea that one application (`Application`) is associated with one cluster. That's somehow mitigated with ApplicationSets, but that's still a workaround that helps to create an App for each environment. Fleet, on the other hand, was designed from the start to manage the same app on multiple clusters and we can manage them all from a single file. That being Argo CD (and Flux) is battle-tested while Fleet is in its infancy so I still recommend Argo CD (or Flux) in the majority of cases. The exception would be if you run on a truly large scale. For now, Fleet is in the "lot of potential, but we should wait and see" type of the category. It's quite possible that Argo CD and Flux will get the "missing" features sooner than it will take for Fleet to mature.
There is a CNCF sandbox project called Karmada, which promises multi-cluster management like Fleet, but without the GitOps part, using it's own CRDs and deploying it's own cluster agents. Do you think it will be a potent antagonist of Rancher Fleet, or maybe they can coexist, one bringing the GitOps aspect and the other a more extended control plane-style management of the underlying clusters? Personally I think it is more like Rancher's multi cluster management, which incorporates Fleet for deployment, not management, than an antagonist of Fleet itself. Also in a scale of 4-5 clusters it's safe to use ArgoCD for managing the different pipelines. What do you think? Thanks for the always great content!
Many thanks for the video ! I would like to know if it is possible to automatically deploy changes on a cluster after each commit on a branch in a Git repository ? Thank you in advance
@@DevOpsToolkit they have an integration with Flux. Although I am not a big fan of Azure Arc and a lot of those high level wrappers around existing tools Azure are coming out with
With new tools coming up every week. I am kind of fatigued with learning a new tools that supersede something I learnt few months ago. How do you judge if a tool is worth learning? If we should introduce it in our company (which means one can't switch to a new tool in a few months)?
I believe that we should learn much more tools than we need. Learning is important so that we can make the right choice specifically since we cannot change the tools we use all the time. For every tool we use in prod, we tend to experiment in labs with 10x more, and play with for a short time with 10x more than that.
I prefer fleet allowing me to troubleshoot clusters and then updating manifest in git, I don't want to be fighting with git when doing customization, I think this is also necessary because of how helm handles releases.
@@oscarordu oh yeah. Those happen but I do not think such situations should influence the choice of tools since all have the option to disable auto-sync.
No. Flux and Fleet are synchronizing manifests in git with k8s clusters. They do not care what those are. For canary deployments you need Flagger or Argo Rollouts. You'll find videos with those on this channel.
You do see that the state is wrong, but you do not see any events and that's the first thing I tend to look at when the status is not "ready". So, I was complaining about missing events, not the status.
Please can someone help me. I want to deploy my Github Repo to Rancher2. What steps I should follow. How I can do it ? Hi I have Rancher version v2.5.11 but I am not able to see and user Fleet and Github Repo. How I can add and fleet to clone github repo in Rancher. I am using Rancher on Hetzner Cloud. Secondly when I am installing the Fleet through Shell it give me an error ""Error from server (Forbidden): pods is forbidden: User “u-4x2hv” cannot list resource “pods” in API group “” in the namespace “default”.
You are right. Videos increased in length and I should get back to shorter versions. There are a couple videos already in production but, after those, I'll do my best to make them much shorter..
Timely! We were just looking over some clusters today and noticed the Fleet logo. The team has opted to use Flux for now, since the clusters may not be operated by us, but we want to deploy a standard set of tools to all clusters anyway, which flux seems to be a good fit for. Thanks for all that you do Viktor!
yes a comparison videos always welcome from you Viktor
Moving it closer to the top of my TODO list.. :)
Thanks for this great introduction! To me this is a product that I need to look deeper into since it looks like a great fit for my next project! I like the way you are talking about the products you test and that you just don't want to sell but also show the cons (like empty events during problems and working with typical kustomize structures, no drift or reconciliation!).
Your videos are awesome ❤️
As always your videos are absolutely on new knowledge thanks for keeping me updated with new and latest technology with respect to DevOps
Can you please make a video on GitOps on GKE autopilot private cluster please that will be pretty helpful
I don't think that GitOps in a private cluster based on GKE Autopilot would be any different from other types. Since GitOps tools are polling information from Git, clusters can be locked so being private is not an issue, and using Autopilot does not change how we define manifests and store them in Git (beyond a few minor things). So, I'm not sure whether "GitOps on GKE autopilot private cluster" would be any different from GitOps on any other type of k8s cluster.
That being said, if you're facing any specific problem with Autopilot and GitOps, I'd be more than happy to help. Feel free to ping me on Slack/Twitter/LinkedIn or, even better, join the AMA or monthly chats and we can discuss it.
I'm facing some technical difficulty to set-up or install Argo CD or any GitOps tools on GKE autopilot private cluster if you please demonstrate how it can be setup it would be very helpful and I'll appreciate that ❤️
Thanks, awesome review!! I agree with all comments above. In my case I don't really like the idea to put all the configuration for different environemts into the same file, maybe I am very use to have different folders or branches per environment... it could grow a lot if you have a lot of clusters that not share the same settings.
That approach can cause issues when running at scale (e.g.., ten clusters or more). In those cases you do need a single place to configure envs.
@@DevOpsToolkit I really like the idea of using tags instead folders and hierarchy for matching the configuration, it is more flexible. The folder structure has been used for so long, like hiera, terragrunt and other tools...
Nice video once more. I'm planning for scale (at some point) and was wondering about the following scenario. The plan is to have tenants running in different "pods". Pods not in the k8s sense, but more in the sense of an area of compute power, but only with one provider. Pods can be found on different providers though. Pods would be containing or connected to a lot of services needed for the tenant applications to run (databases, storage, ingress controlling, etc). The tenant applications, and there can be any number of applications per tenant, would be "spread out" across these named "pods". The tenants themselves would have both dev (which may include staging) and production instances of their apps. There could be any number of tenants in each of these pods (to save on compute resource). So, I'm thinking these named pods fit into the target names/ labels used in Fleet. But, they could be broken down even more, so instead of just "production" and "dev", there could be "pod-1", "pod-2" etc. and they could be broken down further as "pod-1-prod", "pod-2-prod" and "pod-1-dev", "pod-2-dev", etc. etc. Does that make sense? If yes, how scalable is that? Imagine 1000s of git repos being the source of truth for 1000s of Fleet managed cluster targets.
To begin with, if you're not using different clusters for tenants, I strongly recommend exploring vCluster (th-cam.com/video/JqBjpvp268Y/w-d-xo.html).
Now, I'm not sure I fully understood what you're trying to do. Is each tenant having completelly different set of apps? If that's the case, Rancher Fleet will not be any better than, let's say Argo CD or Flux. On the other hand, if you're having the same apps deployed across multiple tenants residing in different clusters, virtual clusters, or Namespaces, than Fleet might indeed be a good option. However, if that's the case, I'm not sure why would you have 1000s of repos.
@@DevOpsToolkit Thanks. Definitely will take a look at vCluster. And yes, each tenant's apps will be different. That is the (huge) challenge. :)
If each tenant has different apps, you are not benefiting from the main reason for using Fleet (scale) so I would probably go with Argo CD or Flux.
@@DevOpsToolkit Ok. Awesome for the "direction" and help. I'll look into those solutions (and your videos of them) ASAP. 🙂
@@DevOpsToolkit Hey, doing some more research and it looks like Flux is the tool I need. Thanks again for the recommendation.
Hi, thank you for the video. Id like to ask you why the Fleet and not Argo cd is the choice, when handling multiple clusters. What is the main cons for Argo cd in this scenario. New in the field, trying to learn as much as I can from you :)
Argo CD is based on the idea that one application (`Application`) is associated with one cluster. That's somehow mitigated with ApplicationSets, but that's still a workaround that helps to create an App for each environment. Fleet, on the other hand, was designed from the start to manage the same app on multiple clusters and we can manage them all from a single file.
That being Argo CD (and Flux) is battle-tested while Fleet is in its infancy so I still recommend Argo CD (or Flux) in the majority of cases. The exception would be if you run on a truly large scale. For now, Fleet is in the "lot of potential, but we should wait and see" type of the category. It's quite possible that Argo CD and Flux will get the "missing" features sooner than it will take for Fleet to mature.
@@DevOpsToolkit Thank you for the quick answer!
There is a CNCF sandbox project called Karmada, which promises multi-cluster management like Fleet, but without the GitOps part, using it's own CRDs and deploying it's own cluster agents.
Do you think it will be a potent antagonist of Rancher Fleet, or maybe they can coexist, one bringing the GitOps aspect and the other a more extended control plane-style management of the underlying clusters?
Personally I think it is more like Rancher's multi cluster management, which incorporates Fleet for deployment, not management, than an antagonist of Fleet itself.
Also in a scale of 4-5 clusters it's safe to use ArgoCD for managing the different pipelines. What do you think?
Thanks for the always great content!
Adding it to my TODO list for one of the upcoming videos... :)
Many thanks for the video !
I would like to know if it is possible to automatically deploy changes on a cluster after each commit on a branch in a Git repository ?
Thank you in advance
Yes, it is. You just need to tell it which branch to monitor.
I think Azure arc is good to manage multi clusters through gitops.
I don't think Azure Arc implements GitOps. You'd need to combine it with other tools like Argo CD, Flux, or Rancher Fleet. I might be wrong though.
@@DevOpsToolkit they have an integration with Flux. Although I am not a big fan of Azure Arc and a lot of those high level wrappers around existing tools Azure are coming out with
That's quite possible. I have only superficial experience with azure. I should change that...
With new tools coming up every week. I am kind of fatigued with learning a new tools that supersede something I learnt few months ago. How do you judge if a tool is worth learning? If we should introduce it in our company (which means one can't switch to a new tool in a few months)?
I believe that we should learn much more tools than we need. Learning is important so that we can make the right choice specifically since we cannot change the tools we use all the time. For every tool we use in prod, we tend to experiment in labs with 10x more, and play with for a short time with 10x more than that.
I prefer fleet allowing me to troubleshoot clusters and then updating manifest in git, I don't want to be fighting with git when doing customization, I think this is also necessary because of how helm handles releases.
Do you mean to say that you edit resources first directly in cluster and then apply the same changes to git?
@@DevOpsToolkit I meant mostly for emergencies or troubleshooting, not as a regular edit, more like one off edits to check or confirm a fix.
@@oscarordu oh yeah. Those happen but I do not think such situations should influence the choice of tools since all have the option to disable auto-sync.
Can flux and fleet do canary with istio?
No. Flux and Fleet are synchronizing manifests in git with k8s clusters. They do not care what those are. For canary deployments you need Flagger or Argo Rollouts. You'll find videos with those on this channel.
I just realized I wrote "kids" instead "k8s" :)
#tks
With the rancher UI you see that the gitrepo is in wrong state i think describe should show it in some way.
You do see that the state is wrong, but you do not see any events and that's the first thing I tend to look at when the status is not "ready". So, I was complaining about missing events, not the status.
Please can someone help me. I want to deploy my Github Repo to Rancher2. What steps I should follow. How I can do it ?
Hi I have Rancher version v2.5.11 but I am not able to see and user Fleet and Github Repo. How I can add and fleet to clone github repo in Rancher. I am using Rancher on Hetzner Cloud.
Secondly when I am installing the Fleet through Shell it give me an error ""Error from server (Forbidden): pods is forbidden: User “u-4x2hv” cannot list resource “pods” in API group “” in the namespace “default”.
Judging by that error, the user (KUBECONFIG) you're using to install Fleet does not have sufficient permissions. Is that an admin user?
You know I like you & respect you but 40mins video(s) really not working , I wish we can go back to 15 mins or less concept, just saying.
You are right. Videos increased in length and I should get back to shorter versions. There are a couple videos already in production but, after those, I'll do my best to make them much shorter..