Cloud Native Computing Foundation KubeDay Japan 2022, 9 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Bare-Metal Chronicles: Intertwinement of Tinkerbell, Cluster API and GitOps - Katie Gamanji, Apple

Description

Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Bare-Metal Chronicles: Intertwinement of Tinkerbell, Cluster API and GitOps - Katie Gamanji, Apple

Within its 8 years of existence, Kubernetes has been the gravitational center of the Cloud Native, elevating a pluggable system that diversified the entire ecosystem. Multiple areas emerged in the industry, galvanizing solutions for components such as network, runtime, storage, and cluster provisioning. The maturity of the cloud native landscape is led by the wider adoption of enterprise and large organizations. However, for these companies deployment and handling of bare-metal infrastructure has always been essential. A pivotal tool to manage cross-provider infrastructure has been Cluster API, leading a unique and radical stance for Kubernetes distribution. In association with a model such as GitOps, Cluster API assembles a mechanism that leverages the concept of a "cluster as a resource". This talk will outline how cloud native tools, such as Tinkerbell and Cluster API unlock a robust deployment of bare-metal infrastructure. Attendees will acquire an understanding of why the usage of ClusterAPI and provisioning automation with GitOps tools, such as ArgoCD, is a powerful concept that leads an organization towards the discovery of a modernized provisioning model.

A

Hello: everyone, my name, is Katie gamanji and currently I am a senior field engineer at Apple I joined Apple last year and in this role, I am trying to bring kubernetes and Cloud native expertise to different products and services within apple as well. I am one of the TOC or technical oversight, Committee Member for cncf or Cloud native Computing foundation. In this role, I am joining 10 other Champions within the industry, and we try to provide a technical vision for the cncf landscape.

A

I have many other roles in the community, one of them being on The Advisory board for Captain, which currently is an incubating cncf project and I am the creator of the cloud native fundamentals course. So this is actually a free course that you can find on Udacity. But if you have anyone interested in pursuing a cloud native job, I, definitely recommend looking at this course as well.

A

Today, however, I would like to talk about bare metal, Chronicles and, more specifically, the intertwinement between cluster API, Tinkerbell and gitups, and to do so, firstly, I would like to introduce cluster API, and this is pretty much we're going to look into a tool that provides a set of interfaces and standards to provision our infrastructure to different Cloud providers.

A

Next I'm going to focus on bare metal provisioning and here I'm, going to introduce a tool which is called Tinkerbell now, more importantly, I'm going to focus on the combination between cluster API and Tinkerbell, and this is going to be the kpt or a cluster API provider for Tinkerbell and, lastly, to introduce some Automation in all of this architecture. I would like to look into tools such as githubs, such as argosidium flux and where we can further introduce Automation and parametrization in our infrastructure.

A

Now before I move forward. How many of you here are familiar with cluster API? Have you heard about it using it in production? Maybe okay, some hints how many of you have heard about Tinkerbell and not the character?

A

Okay, one ahead and how many of you have heard about github's Argo, City flux, using it in production? Okay, that's really good awesome and how many of you are actually using bare metal or have on-prem data centers that you have to manage. Okay, some of you I hope by the end of this talk, you're going to be more inspired to actually look into bird metal provisioning, because it's not that scary as it might seem now.

A

There is a reason why I'm getting this stock at this moment now, actually just kind of a tail Dr I'm, not ldr um um kind of a note. I do realize that the screens might not be very visible, so I will just try to go for everything very slowly to ensure that everyone has an understanding of what's going on. So if, if you don't understand something, please let me know and I will go for it one more time now going back to the thread of the story.

A

There is a reason why I'm giving this stock at this moment, because within the cloud native landscape, we had multiple tools that cross the chasm now crossing. The chasm means that we're going to have late adopters and these late adopters are described by the fact that they're very restricted, and they should have a full ownership of their infrastructure. As such, they look into you solutionizing how they can deploy and manage kubernetes on bare metal.

A

However, the story was a bit different at the beginning to actually reach the point where we need to solve this. This problem. We need to look a bit uh into the past more exactly nine years ago. Now, if you look nine years ago, the container orchestrator framework space was very heavily Diversified. We had tools such as docusworm Apache, mesos, corowa's, Fleet, kubernetes and all of them provided a viable solution to run containers of scale.

A

However communities it took the lead in defining the principles of how to run containerized workloads. Nowadays, kubernetes is known for its portability and adaptability, but, more importantly, for its approach towards declarative configuration and automation, and we can see this in numbers as well.

A

Based on the VMware tons report, state of kubernetes 99 of the organizations see a clear benefit of using kubernetes, the first one being a better resource utilization, so CPU and memory, and the second one being an East application management, especially when you want to upgrade your application in the cluster now in metric, which is going to be very important for this stock, is that 52 of the organization still have a need to deploy the infrastructure on-prem very important. This number is actually declining from last year.

A

Last year it was 55 this year's 52, so we see a slow decline in the need for bare metal, but that does not dismisses the fact that half of this organization still need to deploy on-premes. So they need a solution for that and another metric I would like to draw your attention towards. Is that 88 of the organizations manage more than six clusters now?

A

The story here is that it's very complicated and difficult to actually provision one cluster, but once you do it one time you can easily replicate that across different environments, so you can have, for example, QA staging production and many more, and this actually grows exponentially if you need to deploy to different availability zones. So you replicate your Stacks across the world.

A

However, the community and the adoption rate for kubernetes increased, and this was very beneficial for it, because over time, multiple tools were built around it to extend its functionalities, and we actually saw some of these interfaces that we talked in the morning, such as support for different networking, runtime storage and many more and this created.

A

What today, we know as the cloud native landscape, which resides under the cncf umbrella- and this is the landscape that we, the TOC, provide a technical vision for so we will try to pretty much accept projects within the sandbox level and we will pretty much help them to go through incubation and graduation status. So the aim is for all of these projects to reach a maturity and the graduation stage.

A

Now, at this stage we know that kubernetes is pluggable, it is extensible. However, at the moment, when we had interoperability of the basis, we had multiple tools that were built to bootstrap a cluster as well, so you might be familiar with tools such as cube, ADM cup spray, tectonic installer, if you go back to the corevis house and many more actually. However, if you look at all of these tools, it's difficult to find a common denominator.

A

What it means is that if I use one tool to deploy my infrastructure to Azure, it's going to be very difficult for me to use the same tool to deploy. My infrastructure to gcp, usually I have to introduce a new tool, and this is not sustainable, especially if you have a multi-flate strategy for your clusters. As such, it was clear that we need standardization and interfaces, and this is where cluster API was introduced.

A

So cluster API is a set of declarative apis for cluster creation, management and deletion, but, more importantly, it does so in a unified manner across multiple Cloud providers.

A

Now, when we refer to Cluster API, we refer to c-cluster lifecycle, which had its first initial release in April 2019..

A

Since then, it had multiple releases, and this year it reached the view on beta1 endpoint, a very big milestone for the cluster API team and, as I mentioned, it actually integrates actively with multiple Cloud providers. So we're going to have support for major Cloud providers such as AWS, gcp and Azure. We're going to have support for Chinese providers as well, such as Alibaba, Cloud, Baidu and tencent, and if you deploy the infrastructure to China, you would know it's quite challenging, because usually you cannot lift and shift. You actually have to use tooling inside that region.

A

Well with cluster API at least the way you deploy your infrastructure is going to be similar and standardized, and lately we have new initiatives to bootstrap our clusters on bare metal, and these initiatives is led by packet, metal, free and Tinkerbell.

A

Now, I've seen a lot of people being new to Cluster API. So what I'm going to do? I'll just try to introduce it to make sure that we have the base, understanding and fundamental knowledge to know how it works. So, let's suppose we would like to deploy multiple clusters in different different Cloud providers in different regions.

A

The first thing we're going to need is a kubernetes cluster, so we need a key printers cluster to deploy multiple kubernetes clusters. This is something that I call cubeception now for testing purposes. You can use kind, which is pretty much a dockerized version for your for kubernetes to create this management cluster.

A

If you want to use cluster repair in production, I do recommend using a fully fledged cluster, and this is because it comes with a more sophisticated failing over strategy. Now, once we have our management, cluster up and running will require the dependencies or the controller managers on installed. On top of it, and currently there are three types of control managers: we need to look into the cluster API crds or customer service definition, controller, the bootstrap provider controller and the infrastructure provider controller.

A

Let's go back to the first one. Cluster API introduces five new custom resource definition and we need a controller to make sure that we can create, delete or reconcile any changes. We have to these resources.

A

The second one is going to be the bootstrap provider, and this is the component that translates the yaml in it yaml script into cloudiness script, and it will make sure to attach an instance from a cloud provider to the cluster as a node, and this capability currently is provisioned by cubadium, Talus and eks, and the last component we're going to need is the infrastructure provider, and this is going to be the component that talks with the provider apis and produces the actual resources think about instances, ppcs subnets security groups and so forth.

A

So the actual actual resources now here with the infrastructure provider, is that the relationship is one to many. You need at least one provider. So if you deploy your infrastructure to gcp, you will need the infrastructure provider for gcp. If you want to deploy the Tinkerbell you'll need a Tinkerbell provider and so forth. So it depends on what kind of providers you want to deploy your infrastructure.

A

So once we have our controllers installed, we will be able to provision the target clusters and the target clusters are the one we will be delivering to our application teams, so they can put their up their services on top of, and these are going to be the Clusters that your customers will interact with while consuming your services.

A

Now a very important concept that cluster API introduces is cluster as a resource, pretty much we'll be able to use yaml manifest to Define our infrastructure's code, and this can be done for the five craft, custom, resource definitions or crds that I mentioned and I'm going to introduce them shortly, because they're going to be quite relevant throughout the demo. Hopefully them is going to work as well.

A

Now the First Resource we're going to look into is a cluster resource, and this takes care of the main networking components for a cluster, so think about the subnets for your pilots and services or DNS suffix and so forth. Now by default in cluster API you're, going to have a control plane associated with every single cluster, so control blend resource. Pretty much allows you to programmatically manage multiple machines with the control plane label label which is going to have all of the control plane components installed on top of it machine.

A

Here you can think this is a resource, that's very similar to instance, so here you can actually check or actually specify the version of kubernetes the instance type, any security groups, networking and so forth. So this is going to be the vanilla provisioning for cluster API you're just going to have a couple of control planes. That's it control plane machines. Now, if you'd like to deploy any workloads, you need a data plane and in cluster API.

A

This is managed through a machine deployment, so I'm hoping that you're familiar with kubernetes, so machine deployment is very similar to deployment it will roll out strategies between different machine set resources, machine set very similar to replica set. It will ensure that we have an amount of machine resources up and running at all time and machine again. This is just an instance. We can specify the version of kubernetes instance type and so forth. However, the label on this particular instances are going to be working out now. These five customer service definitions.

A

We can use to specify our infrastructure's code, so we don't need to use ansible or terraform. We can use our yaml, we like yaml within Cloud native, so here's where we can say that I want a cluster with 10 nodes, three of them being the control plane, seven of them being in the data plane. I would like this cluster to be deployed in gcp, for example, in this particular region, with this particular security groups attached to it.

A

So here's where we Define what we want for our infrastructure and to kind of provide more of a visual aid of how exactly cluster resourcing looks like here. I have a cluster resource for AWS and I'm, going to Showcase it for gcp and Tinkerbell as well. Now what I have here is a cluster resource with the name demo cluster in the V1 beta1 endpoint in the specs section, I'm, choosing a slash 16 for all pods and towards the end.

A

You can see that we have a control plane reference attached to it, so this is going to be by default with every single cluster resource.

A

However, I would like to draw your attention towards the infrastructure reference here is where we say that we want this cluster to be deployed in AWS and, what's going to happen, underneath it's going to pull configuration, that's very specific to AWS and we defined actually so here we say that we want the cluster to be deployed in your central one as a region, and you want to attach an SSH key name with the name default to our instances. This is not a declarative list of variables.

A

You have a full flexibility of what you can configure, but these are just for demo purposes here now very important pay attention. If we want to deploy the same cluster to gcp, these are going to be the changes required. So on the cluster side, we just change our infrastructure reference. That's the only thing we need to do and underneath is going to pull all of the configuration that we defined for gcp as such the region. Naming convention is very different: we deploy it to Europe West free.

A

We have the concept of a project within gcp, so we attach our cluster to a project called C API and we can specify the network in this case with the name defaults API. But, more importantly, what you can see here. We have standardization, we can use and reuse our manifest. We have the building blocks. What's going to be different, is the configuration for the cloud provider and, if you'd like to deploy our clustering wheel using Tinkerbell again infrastructure reference is going to point to a think of a cluster.

A

However, the configuration is going to be very specific for Tinkerbell and here I'm, just specifying the base registry, where we'd like to pull our infrastructure or images to be installed on our bare metal.

A

Now so far with cluster API. We know that we can deploy our infrastructure anywhere and we can do so in a standardized manner, so we have building blocks and interfaces open, spec. Now what happens if a second organization you do not want to use a cloud provider? What happens if you want to fully manage your infrastructure on bare metal? Well, in this case, we have Tinkerbell that saves the day. Tinkerbell is an engine for bare metal provisioning anywhere. Kubernetes is just a subset of it. It pretty much Provisions bare metal anywhere.

A

It was built by the equinix metal team in 2019 and it was donated to cncf as a Sandbox project in November 2020., now being a Sandbox project means it's a still Greenfield project.

A

It still requires a lot of enhancements when it comes to functionalities, so it's null not at the production level or at the scale that every single organization needs, but this is where I would like to invite you to contribute and actually look into the tool, especially if you have a need for bare metal and, of course, Tinkerbell aims to minimize the time for provisioning bare metal anywhere. So it can be pretty much data, centers public cloud or even Edge devices.

A

So now, let's look at how Tinkerbell works so to manage any bare metal using Tinkerbell. You need free sense of configurations. Let me try to show that free sets of configuration, Hardware template and workflow. The hardware is going to be your inventory, so, for example, I have 10 Raspberry, Pi machines or I. Have this amount of servers available? You need to declaratively actually specify that and you can uniquely identify every single Hardware machine using the MAC address and the AP address.

A

After the inventory specification. We need a template and the template is pretty much a set of actions that we want to perform on top of the bare metal so think about this. You want to install an operating system. You want to install dependencies any middleware, any application.

A

So by the end of it, you have a server in the state that you want it in production and workflow is pretty much attaching a hardware to a template, and this is very useful, especially if you have a multi-flat strategy, so you can say: I want five machines to be installed with Linux and their respective dependencies and the other five machines to have Windows and their respective dependencies. So you can have the strategy of how you want to provision your bare metal.

A

Now, once we have all of this configuration available, we can use the tingcli and send all of this configuration to The Ting server. The think server pretty much can be running anywhere within your environment or local machine if you're doing a demo and what is it actually going to do? If you have a hardware and a template, it's going to take a machine run all the actions in the template. So by the end, you should have a server in the desired state that you wanted now, as I mentioned, Tinkerbell focuses on bare metal provisioning anywhere.

A

What happens if I want to provision kubernetes on bare metal? What happens if I want a machine or a bare metal machine to be attached to the cluster as a node? In this case we have the combination between cluster API and Tinkerbell coming together, and this is going to be crowned by kpt or cluster API provider for Tinkerbell, and this is actually how it's going to look like quite overwhelming, but I'm going to take it step by step.

A

We need to look at three sets of configuration, what we need from the Tinkerbell side, what we need from the management cluster on the cluster API and, what's going to result, the result is going to be the target cluster, so going back to Tinkerbell's side here is where we need all of our configuration like as I mentioned, we need free set of configuration, workflow templates, actual Hardware templates and workflow. You can actually see them already in this diagram. So on Tinkerbell side we need our inventory.

A

We need to say that we have 10 Raspberry Pi machines and we need to make think server aware of them from the management cluster side. This is going to be cluster API, a mini recap. What we need is all of our controllers, soil dependencies. We need the infrastructure provider for Tinkerbell, so kpt is going to be installed by default.

A

Another thing we're going to need here is the yaml configuration for our infrastructure. So, as I mentioned, we use yaml or crds to Define our infrastructure's code. We need that. We need to Define that we want the cluster with five nodes and so forth, and another thing we're going to have is a hardware yaml. Now this is the important distinction, because if we have 10 Raspberry Pi machines, you might want only five of them to be part of the cluster.

A

So you need to make cluster API aware of what it actually can use throughout the bootstrapping process. So the hardware yaml is going to contain, for example, five or six machines that you want to dedicate for your infrastructure.

A

Now the very important thing about cluster or Tinkerbell and the Tinkerbell provider for cluster API. It actually comes with a set of templates and workflows available, so you don't have to rewrite them. They're already available out there. So what's actually going to do is if you want to provision a new machine, a bare metal machine using kpt.

A

The template is going to have the actions to install all the kubernetes kubernetes binaries, so you're going to have the cubelet you're going to have the source installed you're going to have q proxy networking attached. So, by the end of it, you should have an instance with all the kubernetes binaries that will be able to be attached to the control plane and actually be part of the cluster in the Target cluster.

A

Cool it's a bit packed, but let's take a breather now I would like to take you back to the beginning of the presentation where we've seen that 88 of the organization manage more than six clusters, it is impossible to manage these clusters individually at least sustainably. So what you need to do is you need to introduce Automation and parametrization if possible, and here's where we can actually use the power of get Ops now most of you are familiar with githubs, just kind of a very quick recap.

A

The Guido's principle has the gate repositories as the source of Truth for defining the state of your application and, in our case, our infrastructure.

A

Now, what is actually going to mean is, by default we're going to have a PR based rollout. That means that the Delta between our local environment and production is just one PR away.

A

Githubs actually bring automatic reconciliation as a very important capability, and what it actually means is that we're going to have a GitHub store, that's going to watch a repository, and if new changes are identified, these are going to be extrapolated and applied to the cluster straight away. But more importantly, with ketops we're going to have a version state of our cluster. This means we have different historical data points of our infrastructure.

A

So if you are in a red state, for example, you can very easily revert to a known and green State using just a couple of Kit commands. Now this is actually a very nice announcement. I think everyone is aware, but the gitos principle is very well represented by argosidium flux and both of which graduated within the last week.

A

So this is a very important milestone for the cloud native Community Argo City actually announced the graduation yesterday and flags announced their graduation I think a couple of days ago, but meaning actually being a graduate project means that you have a big, um a very mature project that has a lot of adoptions and contributions from different organizations.

A

But, more importantly, it has a sustainable roadmap with functionalities that actually can solve the problems that the tools will need to solve in the future and with that, let's actually see where we can use or where you can introduce automation within our infrastructure provisioning.

A

Now, what I've done for now is I've completely removed Tinkerbell from the scenario, because cluster API pretty much standardizes the way we deploy our infrastructure anywhere, even using Tinkerbell or even on bare metal. So what I'm actually going to focus here is how can we automate our infrastructure, provisioning using cluster API and Argo CD? So going back to the fundamentals, we're going to look at everything Google can have or should have on the management cluster and the result is going to be applied to the Target cluster.

A

Now on the management cluster, we're going to have again mini recap: we're going to have all the file controllers up and running as well we're going to have our infrastructures code so what kind of infrastructure cluster we would like to deploy now all of this yaml manifest by default, they can be stored in git and by default we can use a tool such as argocd to watch this manifests.

A

So if you introduce any new changes to your GitHub to actual manifest in Git You Can merge your PR Argo City is going to pick up the changes from the pr and apply them to the Target cluster straight away very optional. However, I I want to see a kind of outline this. You can use a template manager because we have multiple clusters. We want to parameterize or we want to reuse as much of our infrastructure as possible.

A

So here, for example, I'm introducing help you can use customize as well to parameterize the version of kubernetes to 1.24 to parametrize the amount of replica for the control plane in this case to free and the replicas for the worker nodes in this case is going to be one. So here we have pretty much a cluster with four nodes in version 1.4 at 124.0.

A

Now any changes now I need to introduce are going to be to the helm chart because Argos today is going to watch the helm chart if I'm putting any changes to this chart, for example, putting a different version for kubernetes from 2.25, for example.

A

These changes are going to be picked up by Argo City and applied to the Target cluster straight away, and this is something that I would like to demo as well, if I'm not mistaken, so going here, what I'm going to showcase the setup I'm having at the moment I have the management cluster deployed on my local machine using kind on this cluster I have all of the controllers installed. Actually I'm going to use AWS.

A

A very important remark here: I would love to do the demo on bare metal, however, to travel with a bit of Raspberry Pi's across the world. It's more challenging so I'm going to use AWS, because it's more convenient for me to Showcase how it can automate our infrastructure provisioning, but it doesn't matter because with cluster API, the functionality is going to be similar. So, ideally, you should have a digestible understanding of how we can automate and provision our infrastructure.

A

So in this case the controllers that I'm going to have is going to be for AWS as well. Argo City is going to be installed and I'm going to have a Helm chair. That's going to manage my infrastructure and the idea is that I'm going to increase the amount of replica notes for actually the work nodes, and ideally they should be applied to the Target cluster without me doing anything so without any further video.

A

Let's just make sure that everything works.

A

Now this is a bit overwhelming. I know these screens are a bit small. So not it's not very readable. All the way through, however, I'm going to take you all the way, step by step to Showcase what I actually have happening on the screens. So.

A

That's not it either cool. What I'm actually going to do. This is my management cluster I'm, going to get all of my pots, so I would like to Showcase all of the controllers that I have installed.

A

So this is a bit overwhelming I, don't like the viewing it's a bit trained, but if I make it smaller, no one can see it either. So I'm going to point your attention towards the cluster API, this is going to be the bootstrap provider, so in this case I'm using cubeadm to bootstrap my cluster, the yeah, and this is going to be for the control plane.

A

We needed a a control controller for our crds and this is going to be installed in the Kappa system. So this is going to take care of our crd reconciliation and, as I mentioned, uh we're going to have an infrastructure provider, and in this case it's going to be called Kappa. We know about kpt, which is provider for Tinkerbell. Kappa is provider for AWS, so cluster API provider for AWS, because I'm using AWS I have that controller installed and as well.

A

You can see that I have argosity already installed over here, so pretty much we'll be able to connect cargo city as well. Now here is where I would like to Showcase how we have the management cluster versus Target cluster, so on the top I have the management cluster on the bottom. I have the target cluster.

A

So this is a cluster you're actually going to provision now, because in AWS the VPC provisioning takes around five minutes, I've already provisioned the target cluster, it's just kind of be more resourceful with the time, but what I have here, I'm actually getting all the machines, so the machines are our crds. These are all our instances and we can see. We have currently I'm just going to try to highlight them. You see here, control, plane, control, plane, control, plane.

A

We have three control, plane machines and you can actually see in our Target clustering that we have free control, plane machines as well, and here on the mind management cluster side. We can see that we have one worker node. This is well. This is like Insider knowledge, but MD here stands for machine deployment, which is pretty much our data plane, and we can see that here we have one worker node as well, so pretty much. What we have in our machines matches the target cluster as well.

A

The change I would like to introduce is pretty much increased amount of replicants that we have for our cluster now before I do that some people might be new to the helm, chart or actually how we parametrize some of our variables. So here is the helm chart or the input file for the helm chart that I've actually showcased on the slides. So pretty much is similar. Again, we parametrize the version of. Let me make this bigger a bit.

A

We parameterize the version of kubernetes to 124 free replica nodes for our control plane and one replica node for our worker worker plane or data plane. So everything matches that we have in our terminal now to Showcase actually to Showcase how Helm chart works. I would like to showcase.

A

Let's see the template I'm going to go to the cluster template and here again everything we've seen on the slides. Pretty much is the same, so we have a cluster resource. We choose. This live 16 for all pods and our infrastructure reference is AWS.

A

So here is where we pretty much say that we want this cluster to be deployed in AWS to see where the template like, where the helm, chargeable input variables, let's go to machine deployment, and here is actually where you're going to pick up the amount of replicas for our work nodes and here's how we're going to pick up the version of kubernetes.

A

So this is just a way for Helm to pretty much pull up the values that we have in in the input file and recreate the Manifest with the desired state that we want actually one more minute. Hopefully, if you give me maybe two more minutes: I'm gonna showcase the demo. If everyone is patient enough, um but I'll try to go through this as quickly as possible.

A

So what I'm actually going to do? The only thing I'm going to do is change our values that demo file that we send on the slides and I'm going to increase the amount of replicas from one to let's put five, because it's get UPS all I need to do is to use git commands to submit my changes so I'm going to use a git commit with a very meaningful demo message: I'm going to speed all my files and I'm going to do a git push straight away.

A

I know over time, but I really want to showcase this and how it's actually going to work cool. Now what we actually can do, we can look in the Argo City. This is going to be very overwhelming, but this is how we can see a visualization of all of our parameters and customer service definitions. So what I'm going to do? It's actually we're going to look for the repository every single couple of minutes, but I can reinforce to look for new changes.

A

So if I hit a refresh- and hopefully my internet is not going to fail me- oh goodness, mine. This is peer pressure. Let's see, am I actually.

A

Okay, let me just do the word forward again: local demos, cool, okay, refresh refreshing.

A

Awesome and we can see that we are out of sync. Ideally, we should see our change here. We increase the amount of replicas from one to five. Now, with Argo CD, you can do automatic reconciliation. I chose to do manual, reconciliation just because I would like to kick off the demo.

A

So what I'm going to do I'm going to synchronize manually, but this can be fully automated with Argo City, and ideally we can see that we have some resources showing up here, but, more importantly, we should be able to see them here on the management cluster. We can already provision some of our machines and ideally, by the end of it. Hopefully we're not going to have time to see this, but within a minute or so we'll be able to see new machines added to the cluster.

A

So I can come back to this after I'm introducing one of the last slides, oh dear pressure, cool I'll come back to that. I really want to showcase. How that's going to happen. It's usually around the minute, so shall I actually stop now. Is that it I don't have time cool now, unfortunately, we don't have time to actually showcase the demo or another slide I wanted to Showcase is how we can combine all of these tools together, so how we can use Tinkerbell cluster API and Argo CD to deploy our infrastructure in an automatic way.

A

Now I don't have any more slides. This is the overlap between the tools, but, more importantly, I would like to thank you very much. If you have any questions and if you like to see the demo there, it's actually a recording of it so you'll be able to see it I'm more than happy to show it after the talk as well so like if you want to real estate, I'm happy to showcase the Showcase it after.

A

If you have any questions reach out to me on social media such as Twitter and Linkedin, and this is a QR code towards the cloud native fundamentals course. So if everyone would like to start their Korean, Cloud native I recommend taking this course now. This is Katie gomanji and I. Look forward to seeing how you can shape the cloud native ecosystem. Thank you and enjoy the rest of the conference.

A

And we have, we have new machines here 49 seconds ago here it is the demo worked actually, but not in time.