Mae yna Simon yn ddweud â'r AEP, sy'n ddweud o proses o ddweud o'r ddweud o architechur, sy'n ddweud â'r Embercosm. Dwi'n ddweud â'r ddweud o'r ddweud o architechur, o'r ddweud o'r ddweud. A dyna ddiwedd ar gyfer, dyna'n ddweud â Simon. Simon wedi ddweud â'r simulator. Y ddweud â'r Embercosm yn ddweud o ddweud o'r ddweud o architechur, sy'n ddweud â'r ddweud o'r ddweud o'r ddweud o'r ddweud o architechtechur, mewn gwiriaf ac blincau, ddweud â'r ddweud, aent rydym yn ddweud. Dwi'n ddweud â'r ddweud â yw y cerdd. First of all, I'm going to what AAP is, so this is what it looks like, a sort of high-level block diagram. It's Harvard architecture, so the code and the data are completely separate. We've got a variable number of registers, I'll talk about it a bit more later, which varies between four and 64 registers. They're 16 bits wide each. All of the operations work on 16 bits. We've got 16 bits worth of data memory, so 264 kilobytes of data memory, and 24 bits of code, which is word-addressed, so we've got 16 megawords of code maxim-addressable. At the moment, the architecture looks very sane, so it's a risk architecture, and it's load-store, so if you want to do anything you have to load from your memory into your registers, do the operation there and push it back. At the moment, the instruction sets relatively straightforward, there's nothing that surprising in there, but the purpose of this architecture is mainly to form a good basis. It's simple at the moment, and it's going to become more complicated as we add new things and try new things out. That's basically what I said just now. I want to go into a bit about the motivation of why we're doing this. As I said, our main business is working on compilers and things. Why come up with an ISA, why come up with an architecture? The reason for doing that is basically, there's a number of reasons, one that is very, very good for training. If we've got new employees, new people, or if we want to help out with the community, then it's very good if you're trying to learn how to write compilers to have something to do, basically, that doesn't involve digging deep into the x86 compilers or the ARM compilers, which are very massive and complicated. Having a good basis, which is well documented and open, it's very useful from that perspective. For us, it's very useful for experimenting with new features, and this ties into the main points, which is basically that. We have customers come to us and want new architectures or want a new compiler for their new architecture, and we can't necessarily talk about that architecture. That architecture, the compiler for it, the tools for it, can't necessarily be upstream in the code bases, so we can't necessarily have ourself entry in the main source code for LVM, GCC, and similar. But we would like to have something entry which represents that architecture because otherwise we're working out of a tree, so we're working on our own, and we have to maintain everything, we have to make sure that nothing in the main tree compiler breaks anything we're doing, we have to maintain that compatibility, and we don't have some architecture entry which we can push our changes back and give back to the community. That's the main reason that we want to do this, and from that perspective, the experimentation side is very true as well. By having an architecture which we can play around with and modify, we can, if a customer has some strange or interesting feature in their architecture, we can add it to our architecture, implement it there, demonstrate it, it can be done, and then we can push that into the main tree if it's allowable or otherwise. It's good practice, it's good. To demonstrate we can do something. I just wanted to quickly go into a couple of the problems, so this is to try and address some problems that we've seen in compilers, and we want to fix things that we see in those compilers when it stumbles on an architectural feature that isn't represented in a tree, so we want to address that, and so I'm going to talk about a couple of the things that we've had to address even in this relatively simple architecture thus far. The main premise is that compilers often assume that your architectures are boring and straightforward. They are not used to having very weird architectures, things like DSPs, throw a spanner in the works a bit and get more difficult to implement. So an example we've got in AAP, we've got this data memory, it's only 16 bits. Our registers are 16 bits, so a register can reference to all of our data memory, and that's all well and good. Our code memory, however, is too big. We can't reference all of it, so things like function pointers, we can't reference all of our code memory through a single register, so our function pointers can't live in a single register. So we then have to pair up our registers and that itself isn't a problem. Compilers handle that fine. The difficulty comes when you want to do both of these, so we've got some things we want to reference with one register, some things we want to reference with two, so when we're using functions we want two registers to talk about it. When we're referencing dates we want one. However, the compiler tends to assume that one point size fits all, so you have one pointer and that is assumed to be big enough for both. So that gives us a couple of choices. You can use the smaller amounts because it's more efficient and try and reference everything with it, but now you can't use that for all of your code, which is not helpful. Sometimes you can get around that with some workaround or some hack, but that's not very ideal. The alternative is that you use two registers and a pair everywhere, so all of your data you reference with two registers, and that's just mind-blowingly inefficient and you don't want to do that either. Overall, the actual problem can be brought down to we just need to fix this assumption in the compiler. It's an assumption that doesn't hold for us and it's an assumption that doesn't hold for our customers, so it needs to be fixed. Another issue that we come across, so we're a load store architecture. We can only do calculations when something's in the register file. So we have to first load things in and store them out once we've run out. So once we've run out of registers, we have to shuffle values between registers and memory. We can't operate directly on the memory. And that code to do that, to do the shuffling, spilling and reloading of registers, that's all produced by the compiler. So we've got our obvious example, which is C plus D. We've got some stuff in some registers already and we've got the values here. We first have to store what's already there. So store one register, two registers, out to these. Then we load in our values that we actually want to do the calculations on, which is C and D. And then finally we actually do the add. Now, in all of that, we've got five instructions here to do the add. Four of them are completely useless. They're not doing anything interesting. So we do this operation, C plus D. This is the actual guts where that operation is happening, but we've got to do all of this shuffling of stuff to actually do that operation. And you want to minimise that, basically. And these compilers do a reasonably good job of this, but it's quite a hard problem. It's quite difficult to compute how to spill and restore registers, when to push stuff to mirror and when to pull them back. The problem we have is that in compilers, there's often an assumption that you have quite a lot of registers. So you've got at least eight registers, or 16. And when you've got eight or 16 registers, it doesn't matter quite as much if you don't use them all quite as effectively. If you waste one register out of eight, that's not so bad, but if you've only got four registers, as we're aiming to support with AAP, you've lost a quarter of your register space just because you're using it inefficiently. So we're addressing this, which is basically handling this case where everything is much more constrained than targets are typically used to. So those are basically a couple of the problems we've seen. There are a whole bundle of other smaller things that we've encountered, but basically these are the kind of things we see, and we want to fix these in compilers, and we want to fix them in a way that we can put those fixes into the main source tree and have them be supported and maintain support for them. So back to the high-level view. So this is where AAP has come from. It started out at FOSSTEM last year, and that was Simon's. Simon did the initial ISA design and did the initial compiler. He brought that up incredibly quickly. We did a big bundle of development in this gap here, and then a year ago, almost exactly a year ago, we had a high school student come in to do an FPGA implementation, and that runs on a D0nano, and that was Dank Orenge, and that's also available. We talked about it at Orconf, and we also talked about it at FOSSTEM this year. Just before the end of last year, Simon started working on the simulator, which is what he's going to talk about now. So the current stage of things, we've got our ISAs in version 2.1. We've made a few changes. They're mainly relatively small changes. We've got a compiler, which is Clang LVM based. We've got a basic debugger. We've obviously got this FPGA implementation. Sadly, we don't have a portrait of Dan, but he left this on the whiteboard for us. And we've got the simulator, which Simon's going to talk about now.


You got the default bill payment terms, so this is kind of like we saw on the invoice. If I enter a bill into the system, that means that I'm going to pay it at a future time. Now the term bill for QuickBooks is a very specific term, so we can use it in a lot of different ways outside of QuickBooks, even in accounting, but for QuickBooks, it means we got a bill from the customer and we're entering it into our system before we pay it. We're not just going to pay it with a check. We could get an invoice or a bill from a customer and pay it with a check, which means we wouldn't use the bill form. If I enter it with a bill form, that means that we're going to pay it in the future. Now it doesn't have a default here because you're probably going to have to enter the manual bill date of when it is due, rather than just give a default here because we're the one receiving the bill. But I'm going to put a default on it in our practice problems so we can just see, so it'll generate that automatically for us. So that's going to be when it's going to be due by default. Let's save it.


This is stock number 10477. We are here at Summit Automotive in Fond du Lac, Wisconsin. You're new and used. Heavy-duty truck, headquarters. Today we are checking out this super clean 2017 GMC Sierra 2500 crew cab short box. This truck has the 6 liter V8 motor, gas motor, and it has been fully safety and inspected by our service shop. It has a fresh oil and filter change. All the fluids have been checked and topped off and this truck is 100% ready to go. You can see it has the HID headlamps, the LED running lights, and the factory fog lights. Summit white is the color we shoot all of our videos in 1080p, 60 frames per second, so if you have HD capabilities on your computer tablet or smartphone device turn them on right now because it is like you were right here looking at the truck with me and definitely your best way to check out the vehicle. Quality and condition-wise before seeing it in person. Very very clean down this side, factory chrome step-ars, and if you want to check out all the photos on this truck in the upper right-hand part of your screen is a link right to our website. Click that and check us out there. It has the chromed 18-inch rims, BF Goodrich all-terrain LT26570R18 tires with right around half the tread left on the front. You can see the frame and underbody is in nice shape. Didn't see any denser dings on that fender. It has the nice HID headlamps, the chrome-trimmed grille, front bumper and lower valance are in excellent condition. I didn't see any dense or dings on that. Front bumper is in really nice shape. Passenger side fender is in excellent condition as well, and the passenger side rim, no scuffs or scrapes on that. As you go down this side of the truck you can see just how clean the body is, how reflective and mirror- like that paint is. We take these HD videos so if you are far away or even if you're close by and just cannot make the trip down but you're still interested in purchasing the vehicle, you can see the vehicle, hear the vehicle and have confidence in what you're looking at before you even get here. So that when you do get here there's no surprises and you'll be 100% ready to go. And that's why we offer the Summit Auto Fastpass option in the upper right- hand part of your screen a link right to our website where you can apply for financing, get pre-approved, see a payment quote, even appraise the trade all from the comfort of your own home. And when you get here all you got to do is drive the truck, check it out, love it, and you'll be all set to go. Factory exhaust, back tire has just as much tread as the front tires, maybe even just a little bit more, and the frame and underbody is in really nice condition. I didn't see very much corrosion at all. Back rim, no scuffs or scrapes on that. Just a couple little water drops. And as we come around to the back of the vehicle you can see the rear bumper is in absolutely perfect condition, no denser dings on that, and it does have the rear bumper steps. Tailgate is in nice shape, it has a GMC factory soft tonneau cover that looks like it's in really nice shape. Has a spray-in bed liner, fifth wheel bed rails, and it does have LED bed lighting up there. Very clean back here, no denser dings on that box, and it does have a locking tailgate with a backup camera as well. Down this side of the truck just as clean as that passenger side has the mudflaps on it which keeps your lower rockers looking good, free of rock chips, and no denser dings on the box here. And for full disclosure this back rim is in excellent shape as well, no scuffs or scrapes on that. Down the rest of the side of the truck very very clean, has those nice chrome step bars, all the pads are in good condition, has the telescopic tow mirrors with the built-in directional signals, the LED side lights. These mirrors do fold in, they also fold out, and they also telescope out like so.  Both of these seats are heated. Power driver's seat, no rips, no tears on that. Factory all-weather floor mats throughout, auto headlamps, turned-out four-wheel drive, factory brake control, you get your telescopic and tilt on the steering wheel. Power windows, power locks, power mirrors, you get the nice carbon fiber door trim, and as we hop inside the truck here you can see that this one only has 30,838 miles. Instrument cluster is very nice and clean, and it does come with cruise controls on the left, Bluetooth and information center controls on the right. That steering wheel is leather-wrapped and in excellent condition, has the six-speed automatic transmission with the optional tap shift, the GMC IntelliLink radio, you get AM-FM and Sirius XM radio capabilities. This is also where your backup camera shows up, and this is also where you can do your projection. So you can do Android Auto and Apple CarPlay and project your cell phone right to the screen. So if you got Waze or Google Maps you can put them right on the screen, and it's like you have the navigation on the screen. You can control everything through the screen then once it's up there.  These are your cargo lamps, that's how you turn those lights in the bed on, as well as the side lights on the mirrors, and your downhill assist to control. I'm going to leave those on so we can check out those mirrors because they're pretty cool, pretty bright. Two USBs, two power points, and then 110 volt, 150 watt plug-in. You get the dual glove boxes factory format on that side, passenger seat, no rips, no tears on there, smells very clean inside this truck. The headliner is in excellent condition, and up here you get your map lights and home link buttons for your garage doors, security systems, and lighting systems. You do get on-star capabilities in that review mirror, as well as an SOS button, and we'll take a quick look at the back seats and then check out under the hood.  Seats are in great shape, they do fold up like so, and you do have a storage bin underneath there. All weather floor mats back here as well, very nice condition, and those seats fold down like so. Carbon fiber on the doors back here, and we'll take a quick look under the hood. Those are those LED side lights, they are super bright, and I would personally like to thank you for checking out the video today, and hopefully from this HD video, you will have been able to tell just how clean this truck is all the way around inside and out. Under the hood we have the 6-liter VORTECH V8 motor, and Jamaica is very clean, runs very smooth. This truck has been fully safe and inspected by our service shop. Has a fresh oil and filter change, all the fluids have been checked and tapped off. The truck has been gone through mechanically 100%, and is 100% ready to go. See more pictures of this truck, or one of our other 450 new and used cars, trucks, SUVs, minivans, Wranglers, halftones, three-quarter tons, one tons. You name it, we got it on our website, www.summitauto.com. Full pictures and descriptions of every single vehicle from two locations, all at summitauto.com. If you like to check out more HD videos, you can go to www.youtube.com. Remember to like, subscribe, and share on this video and all the videos that you see there. In fact, in a second you will see a link to subscribe to our YouTube channel on your left. A link to more GMC Sierra 2500 videos, like this one on your right, if you have not been to our website on the bottom link to this vehicle on our website, click those, check us out, and we really look forward to helping you with this extremely clean 2017 GMC Sierra 2500 crew cab, short box, SLE Z71 in Summit White. Thanks again.


Hi, everyone. Thank you so much for joining this session today. Like, it really means a lot to me. And I mainly came here today to tell you a story. Tell you a story about policy-based governance and a multi-cluster Kubernetes environment. During this story, we will go through how an organization is able to transform itself from a messy, unstandardized environment into a strictly regulated system in which nobody can do anything without the big brother watching him. So as we go through the story, we will see how we manage to take advantage of open source CNCF projects and leverage them in order to take a huge Kubernetes environment that consists of hundreds of clusters and onboard it into the governance stack. My name is Mikhail Kotelnikov, or Mikhail Kotelnikov in Hebrew. And I am a cloud architect in Reddit, Israel. I'm working as a professional services group. And yeah, it mainly means that I come to Reddit customers and organizations that work with Reddit and provide solutions that may help them on board Kubernetes and manage it properly. And today's story, the story I'm going to share with you today, is based on an engagement that I went through and I'm still going through in the past two to three years. And I think that the main goal that I'm trying to share in this session is how we were able to achieve this goal, first of all. And secondly, what are the challenges? What are the decisions? And what are the risks of going through this process together with the organization or in your environment? Because it's not a simple process to go through. It's not a simple process to govern and provide policy-based aspects to your environment. And this is exactly the process that we're going to cover in this session. OK. So is the mic OK? OK. And is it working? Yeah? OK. So in order to make this process easier for us to understand, we'll need to go two years to the past and see how the environment was when we began working with it. The organization that we worked with had multiple clusters. The first one was based in Tel Aviv. And the main business was around deploying applications and Kubernetes instances closer to the edge. So each cluster had an application or a set of applications that were deployed on top of it. And it provided access as close as possible to the users that were consuming them. As time went by and years went by, the organization made more money and it started scaling to other sites in Israel. It went towards other cities, other remote sites. And you may see that the organization started evolving across the complete country. And now we have clusters really spread out across many different sites. And we provide services to the site, to the users that consume services from the site. As time went by, it really made sense at the time. Clusters began changing from the blue dots you see here to red dots and unaligned misconfigured clusters, in which you could basically see that in each environment, you could see a certain misconfiguration. Like each cluster had a different aspect that was configured on top of it. One cluster did not have a resource quota for its namespace. Another cluster had unsecured ingress instances. Another cluster had unencrypted traffic going between pods. And it was a complete disaster, even though we tried to maintain the policies throughout the complete environment, we could see that each cluster, it was either misconfigured or somebody changed something manually. And we could see that things were not as expected. So at this point of time, we decided that we needed to take action and be able to provide some kind of a solution. So in order to understand the basics of what we try to solve, we need to first of all understand what is Kubernetes policy-based governance is about. So let's go through how policies and how policies should be managed in a Kubernetes instance. This model that we're going to go through is a model which is designed by the compliant CIG in Kubernetes. And it was provided as a kind of portfolio that you could implement in your environment and manage it as part of your organization. So the model states that, first of all, you will deploy an administration point for policies to be managed yet. So you would kind of create a single point of management for the policies to be maintained. Mainly, you will have the compliance officer and the platform team to apply the policies and configure them together. The compliance officer will say that the security control that we must address and the platform team will usually provide the technical aspects that can be implemented in order to achieve this control. Afterwards, from the administration point, the policy is propagated into the Kubernetes cluster itself. On the Kubernetes cluster, we will have an enforcement point, which will apply the policy, and in terms, it will allow the policy to actually persist on the cluster itself. And as you can see, the policy is deployed here by using a certain policy engine, but it also reports to a policy information point, meaning that each violation that is initiated on the Kubernetes instance itself is being forwarded to an information point, which is usually being looked at by some sort of a SecOps team that looks at the violations. And many times, the platform team is in charge of the platform, so it remediates the violations that were initiated by the Kubernetes cluster itself. So if we take a look at the policy lifecycle itself and how it's being managed in such organizations, we will be able to take a look and see that the control is being defined. For example, in here, we say that all access to the cluster has to be secured via TLS. Has to be secured. Afterwards, we say that as a technical control, we define that all ingresses must be secured via TLS, and we state that all of the Kubernetes clusters should have this configuration. And then we need to create some sort of a mechanism which is able to take this technical control and enforce it and be able to take it to a level in which we can see each misconfiguration or violation that is initiated in each namespace in our environment. So we are able to define the control itself. We are taking the technical implementation of the control. And afterwards, we are maintaining this control as time goes by. So this may sound simple at first, because we have nowadays in the CIN-CF portfolio a lot of tools that are able to do and perform such things. We have Keyverno. We have Gatekeeper that you can deploy on top of your environment. And you can see each policy and how it works. And you can basically track each violation in a single cluster. But when you move towards multi-cluster, some things may change and some things may need to be adapted to when you perform this kind of evolution. So in this, if we take a look at a core concept that we need to address when we go to multi-cluster, we need to address the concept of base learning. Because you need to be able to control all of your clusters and make them look like soldiers. Each cluster should be in a certain uniform that the cluster that stands right next to him is wearing. Nobody can be, nobody can change and nobody can actually be different from each other. So if we are changing this and we are moving towards a position in which we have clusters that drift from each other, we are not being able to provide an environment in which we can actually allow anomalies in which we cannot allow, we cannot control the anomalies that are being initiated in the environment. So if there's something that happens and is being investigated by the team, we can actually see that some clusters might be drifting from each other. And it really makes investigating the issue harder. So if we take the model we saw before, the policy-based governance model we saw before, and we take a look at how it might need to be adapted when we change towards multi-cluster, we will see that the administration point will mainly remain the same. We will still need the point in which we can manage the policies and see and address them. We will see that the information point will probably remain the same. We can see that the SecOps team and the platform team will still need a single point of view for their policies to be managed, to be seen as their status has to be seen from a single point. But the main thing that changes here is the way we enforce the policies and how we validate them. Because as scale grows, we need to be able to see how these policies are being maintained and being distributed to the cluster itself. So when we started designing this multi-cluster government stack, we had multiple requirements from this enforcement point. The enforcement point had to be consistent, first of all. Meaning that if I have multiple clusters, if I'm deploying multiple Kubernetes clusters and I have a certain policies that I need to spread across them, I need my policy to be consistent across my cluster. So if I change a certain policy, a certain aspect in the policy itself, the policy has to be propagated to the cluster and to the enforcement point on each cluster. So if I have a certain policy engine on the cluster, it has to be modified as time goes by. And be equal for each cluster. Another requirement we had from this enforcement point was flavors. So as our organization grew, we saw that clusters became different from each other because of different business needs. So we had multiple clusters for different business units. And different business units require different policies. So if we take certain clusters and we adapt them towards different policies, we have to be able to control the policies themselves and how they're being deployed on the clusters. In terms of certain policies are going to be initiated and deployed on production clusters. Another policy is going to be deployed for dev clusters. If we have different business units, we are going to be needing different policies for each business unit based on their requirements from the organization. And if we take a look at the next requirement, it's basically saying that we need our environment to be ever-growing. So if we are taking our environment to scale and we're scaling to dozens and hundreds of clusters, we need the policy to be able to spread and scale across the clusters as my environment grows. So if you saw that I had two clusters and I had three and I had four, then I had 100, I need my policy to be automatically enrolled on each and one of these clusters. And I cannot be able to leave any cluster behind because it will hurt my business. And the last one is reports. I need my enforcement point to be able to spread the reports and be able to provide each policy enforcement point to actually forward the initiated violations from the policy itself to a centralized information point. So if we can see the policy information point that has the three clusters inside of it, you will see that if I have initiated a violation on one of the clusters, it has to be reflected in the governance stack that my SecOps team sees. So based on these requirements, me and my team, together, we came up and decided to design a solution. And the fundamental base for the solution and its requirements was quite unique. And I must take a note at this point and say that there are many options here and you can take a lot of actions and you can use enterprise products. But we decided to go and take our policies and treat them the same way we treat our applications. So if you think about it, the things that I described before are things that we have already solved when we are dealing with applications. We are able to scale our application automatically for clusters that are being deployed in our environment. We are able to take and monitor the applications as the environment goes and grows. We are able to provide different flavors to our applications as my flavors extend. I can perform multiple baselines for applications for different environments. So we decided to take this approach and deal with policies the same way we deal with our applications in the environment. So the first thing that you might think about when you deal with applications is where do you store them? And at this point, we decided that we are going to store our policies in Git. So we are able to take the policy itself, the definition, the governance rule that we want to initiate, and place it inside of Git. So the administration point is actually needs to be propagated with policies from a Git instance. Afterwards, we decided that we need to have a certain Kubernetes native platform for deploying these policies. Because we have multiple solution nowadays that allow policies to be propagated on top of clusters. And taking it and managing it as an extension to the Kubernetes API makes it much easier and much more declarative for users and platform engineers to actually manage the policies and evolve the policies as the environment grows. So if I have another requirement for a certain policy, it will be much easier for me in the platform team to create the policy as part of my daily routine if it's being generated by a YAML that is deployed by Kubernetes. So in this case, we have multiple products that do it. I chose Gatekeeper in this case, but you could go with Keverner or any other deployment that you are wishing to do. If we take the next component that we need to take care of is the GitOps-based deployment, it is much easier to deploy our policies the same way we are deploying the applications. Meaning that if a change is initiated in Git, I want the change to be propagated into my clusters in the environment. So if I have a policy that is being managed and it went through an approval process of the SecOps team for the compliance officer and the DevOps team and the platform team, the policy is being deployed into Git, all of the clusters that are affected by this Git repo, by the policy that's deployed into the Git repo, need to be applied and distributed across the environment. Basically, taking the GitOps approach allows me to scale my policies across the cluster in much an easier fashion. So in this case, we went forward with Argos CD that fetches the policies from the Git repository and spreads them across the cluster as my environment grows. New clusters that are enrolled into Argos CD can be applied with the policies that are inside of the Git repo. And the next aspect that we need to take care of is policy customization. And since we are working with YAMLs and basically we are working with Kubernetes CRDs as an extension to Kubernetes API, we are able to take tools that modify YAMLs, that provide customization to YAMLs based on templating on overlays, it depends on what the organization shows. You could take a specific policy template and create different value files for each policy. So for example, in this case, I have provided a different value file for the policy that's going to be deployed on Flavor A. And I have provided a different value file that's going to be deployed on Flavor B. The flavors can provide more restrictive or less restrictive policies based on what I chose as the organization's compliance officer, for example. And the next challenge that we need to take care of is the policy observability itself. And the way we actually take the policy and provide its status either to the SecOps team or to the platform team itself. So in this case, you can take the agent that's deploying and managing the policy and scrape metrics and export the policies as specific metrics to your environment. You could use an alert manager to forward your policy result to different kind of ingestors. Or you could fold the metrics into a centralized stack like TANOS or Victoria Metrics and basically allow the user to see this metrics and to act upon the violations as they are initiated. So as we can see from this stack, from the technical implementation that we went for, we are able to take the policy itself and manage it by using certain CNCF open source tools. And let's try to take this kind of methodology and provide a very big picture by using all of the things that we went through in this presentation. One of the things that we try to tackle when we just onboarded the policy multi-cluster governance stack was a pretty bad culture of namespace creation across the environment. We saw that multiple clusters have different namespaces that should not be present on these clusters. So some of the namespaces were created by malicious sections. Some of the namespaces were created to troubleshoot issues and people just left them there and forgot about them. And some namespaces were just not required to be on these clusters. We wanted, at the first stage of our policy enrollment, to be able to take these namespaces and create a policy that shows whether we have namespaces that are not managed by my team or by the platform team and initiate a violation if the namespace should not be in the cluster. So basically, you could see that our whole idea here was to maintain all of the namespaces that are spread across the complete environment from a single point and initiate a violation if the namespace is not declared with Git. How we did it is here in this repository, and you guys can take a look at it later. But the final result was something like this. First of all, we have our operator or platform engineer that takes the value files in Git, that declares the namespaces that should be initiated and should be implemented in this environment, and declares the namespace and the additional configurations that should be present in it. In this example, we can see that we have a loud namespace one and a resource quota that is applied to this namespace. Alongside default namespaces that I approve of being in this cluster. Afterwards, this value file, this template, is being taken care of by ArgoCD. And ArgoCD takes it and deploys it on the managed clusters. So if we take a look at what's being deployed on the managed cluster is the namespace that is declared inside the values file. And we can see that alongside this namespace we have another default one that is being actually managed by ArgoCD. The policy itself, since it has a declarative way of showing the namespaces that are being managed in the cluster, is able to see which namespace should exist on this cluster and which namespaces should not exist in the cluster. And based on the result of the policy, the policy can actually initiate a violation to my monitoring stack and allow my platform team to see this policy result and understand it whether it's critical and whether I actually have an issue in the environment. So if we take a look at this and we actually prepared a small demo for this, we can see that my dashboard here shows me all of the clusters that are being managed in this environment. We have three clusters that are managed by the governance stack. And I can see that I have one violation. Alongside this, I can see that I have the name of my violating cluster. And I actually have the namespace name of the violating cluster itself. All of this stack is being deployed automatically via ArgoCD. So all of the applications that actually deploy the policy and deploy the governance stack itself are being managed via Argo. And we have a specific values file that propagates to this applications and creates the policies and the artifacts themselves that are being deployed on the edge cluster itself. So if, for example, I run a command to add another cluster to my governance stack, to my ArgoCD instance, I can see that it creates the cluster. I can see that the cluster is being added automatically to the clusters. You can see that I have cluster 4 over here as well. And an application is being created to enroll the cluster into the governance stack. So I have created a monitoring agent. I have created the policy itself. And I have distributed and propagated the policy based on this certain action. And if we create a namespace on this cluster, we can see that I've created a manual namespace on this cluster itself. And we can see that this namespace is being monitored by the policy stack itself. And it will initiate another violation in my dashboard as it should take a few seconds. And it will initiate another violation for the created namespace. And let us just see it will take like two more seconds. Yep, and you can see that cluster 4 has created another violation. If I now add this namespace to Git, I will be able to actually remediate this violation by taking it from this unmanaged namespace to being a managed namespace in Git. So yep, we are finished for today, guys. And thank you so much for joining this session. And. Thank you.


Do you remember TikTok ads three years ago? Everybody was making tons of money because it was a new thing. This new thing is the Facebook marketplace. So with the growing popularity of this platform is essential for us to know how to list products on this platform. An excellent way to find these winning products is to do product research. After all, if we don't know what products are trending right now, what products are on the wave right now, we're not going to win at this game. So join me in this video where I have prepared a list of 25 best selling products for Facebook Marketplace. Let's dive into this. Now, before getting started, I want you to know three things. First of all, the Facebook Marketplace is such a great place to start dropshipping because it has such low fees. Second of all, because it's a relatively new platform, you can only sell on the Facebook Marketplace if you are a US citizen. And third of all, I want you to know that when you're dropshipping on the Facebook Marketplace, you don't have much competition. With that in mind, these are the 25 best selling products for Facebook Marketplace. So guys, all of the products that I'm going to talk about in this video can be found by clicking the link in the description. Make sure to check it out because each and every product has their own link and you can find them there. But also at the same time, make sure to watch the whole video because it will add a lot of value to your business. So first category that I'm going to talk about is of course furniture. We cannot have a house without furniture, right? In this category, we can sell basically anything ranging from TV wall mounts to rocking chairs, office chairs, office equipment, sofas. At number two, we have home decoration. This is one of the most popular because everybody wants to make their house look beautiful. In this category, we can sell basically anything that's aesthetic to our house. We can start with this black circle mirror, ceramic circular vase, woven basket, Rubik's Cube candle and artificial hanging plant. I have a beginner tip for you here. In this niche, you can take full advantage of platforms such as Instagram and Pinterest to get really nice images and videos of these products. This will definitely increase the traffic on your store and you can have really nice ads with the pictures and videos that you can find them. At number three, we have print on demand products, aka POD. The print on demand business model allows us to customize and print products with unique designs. And since these products are pretty unique because we are basically creating them, we are creating a perceived value because you can not find those anywhere else. For print on demand products, you can sell mugs, magnets, buttons, posters, phone cases, notebooks, keychains, socks, underwear and so on. In my opinion, print on demand is a niche that will always work. It's ever green. I know this niche is like 12 years ago and it has always been performing well because you can always find new designs to put on products. At number four, we have children's toys. Undoubtedly, now that I'm a new parent, I know what it means. I know that you would do anything to satisfy your children's needs so you will buy them anything that they wish. And of course, that is why drop shipping children's products is such a good idea. I have an interesting fact for you here. Children's niche has the biggest AOV out of all of the niches. AOV stands for average order value and that is because people are spending a lot of money on their children. In this niche, really cool products that we can sell on the Facebook market place are the following. This phone bowl shooting gun, tricycle, electric car toys. This princess tent right here. I have a daughter and I can imagine that in like two years she's gonna put me one of these. Toy rocket launcher, this tea party set, this large dartboard, or this toy doctor kit. And my approach for this category would be for you to classify the products based on age gaps, such as one to three years old, three to five years old, five to seven years old. Next up, we have garden and tools. This is another great niche that you can start dropshipping on a Facebook marketplace. Do you remember during COVID everybody was locked inside their houses. So doing gardening felt like a pretty cool thing to do. You didn't have anything else to do. And I think that this stuck with a lot of people and now they are actually enjoying it. So here are some best selling items in the gardening niche that you can sell on the Facebook marketplace. This expandable garden hose, this garden dump cart, this harvest basket right here, this shovel, this gardening tool kit, and this glass weeder. Next up, we have sports and outdoor equipment. A lot of people are doing sports and a lot of people are going outdoors. So you're gonna have a market to sell products in these niches. So here we have this LED camping lantern, resistance loop bands, this flashlight, this huge camping tent, this hunting trail camera, scuba diving fins, this full body swimsuits, and these swimming water shoes. Since a lot of people enjoy going outside, you can make a lot of sales just by selling these products to them. Next up, we have seasonal products we're in Q4 actually. So this is such a good niche to start selling. Now I want you to know the fact that I'm not only talking about Christmas, I know Christmas is around the corner, but I'm not talking about Christmas. I'm talking about St. Patrick's Day, I'm talking about Valentine's Day, Mother's Day, Father's Day, but the examples that I'm going to give you here are related to Christmas and winter basically. This artificial Christmas wrap, this snow globe lantern, inflatable Santa Claus because why not? Of course, ugly Christmas sweaters, they should not miss from any Christmas party. Trick or treat tote bags and this animated Halloween candy bowl. And by the way, when you're selling such products, for example, these ones that are related to Christmas, make sure to go the extra mile and create some discount codes that are related to Christmas, such as Christmas 2023. Apply this discount code to get 10% off your order, something like that. Next up, we have baby supplies they cannot miss from this list. Just to give you some numbers to crunch on, the baby niche was worth $77 billion. Yes, with a B in 2020. And it's projected to be worth close to $90 billion until 2026.  In this niche, we can do very good in a Facebook marketplace with the following products, colorful baby bibs, reusable cloth diapers, ergonomic baby carrier. All the mothers need this waterproof diaper bag feeding chair. Without this, all of the parents would be lost pacifier set foldable baby stroller milk warming machine. This is really useful. And this stroller seat pad. Next up, we have car accessories. Basically, with this niche, you're targeting all of the car lovers. Now, if it's pretty hard to target a car lover on TikTok or on meta ads, it's really easy to do that on a Facebook marketplace. So these are some best selling items that you can sell on your Facebook marketplace. Car floor mats, blind spot mirror, tinted license plate cover. Just be careful. This could get you in trouble. This trunk organizer, the steering wheel cover, and this rear door protective pad cover. Next up, we have pet supplies. Now the pet niche is huge. It only did like $5 billion in sales in 2022. It's a lot less than the kids niche, but it still has a lot of potential.  And finally, of course, I was not going to forget about this electronics. Electronics are performing exceptionally well. It doesn't matter what time of the year it is, you're going to do some nice sales if you know how to sell electronics. So in this niche, let's name a few products. This Bluetooth smartwatch, waterproof Bluetooth speaker, LED ring light with stand, wireless keyboard and mouse set, this Cardo light projector, ring camera doorbell and this USB cable management organizer. Now, as I told you what products to sell on the Facebook Marketplace, there are some products that you should never sell. So listen to this. First of all, we have adult products. Now this industry is prohibited to market on the Facebook Marketplace. This is pretty self explanatory. Next up, we have weapons and ammunition. You're not allowed to sell something like that. Next up, products that are violating trademarks and copyrights. You wouldn't want to invent a product to own the rights to that product and somebody else making money out of it. So don't do the same thing. Alcohol and tobacco products. We're here to do drop shipping. We're not going to sell alcohol and tobacco medical and health care products. Now, if you would have caught the COVID wave, then it would have been a good idea to sell masks. For example, they are pretty much medically related. But now that COVID is over, you don't really need to dig in this field. And finally, hazardous materials. And now I have some tips for you that will help you scale your Facebook Marketplace online business. First of all, use high quality product images and product videos.  And now I hope that you fully understand why it's so important to have nice quality videos and pictures when you're selling a product. Second of all, we don't only need pictures because pictures are not selling the products alone. We only need text. This means that we need a good product description. We live in the era of chat GPT where you can write an amazing product description in a matter of seconds. So go ahead and do that. Number three, set competitive prices. Now, given the fact that the Facebook Marketplace is not that competitive, you should still look at your prices. There will still be people that are going to compete with you. Number four, remain responsive. It's really important for you just as it is on a normal store and a Shopify Geography store to do your customer service correctly and to respond to all of the emails, all of the tickets, all of the phone calls, you should do the same on a Facebook Marketplace and treat it like a normal store. Number five, market your products. It's really important for you to show your products to your potential customers, not let them come to you. We could do this in a lot of ways with three of the most popular are Facebook ads, Facebook promotions and Facebook buy and sell groups. And of course, finally, we have scaling and automation. You can save tons of time by using an automation tool such as AutoDS. With the help of AutoDS, you can streamline and automate everything that's related to your online store. Number one, we have automatic product imports. If you like a product from our supplier list, you just go to it, you click on one button and you will automatically import it into your store. Number two, we have product research. That's a pretty hard thing to do by yourself. This is why we are here. We have an amazing team that's doing 24-7 research just to give all of these winning products to you guys. Number three, we have price and stock monitoring. Now, this is pretty tricky because if you do this by yourself, this is going to take a lot of your time. You always need to keep an eye on the prices and on the stocks of the products of your suppliers. And this is why we also have automatic price optimizations. We're going to do all of the work for you if something changes. And number five, we have advanced image editor. You can definitely make good use of this when you're creating your product pages. With these fantastic features, you can definitely fast track your road to dropshipping success. Thank you for watching, guys. If you want to dig deep into the Facebook marketplace subject, we have a lot of videos to cover that. You can start with this beginner's tutorial or this full case study that takes you from zero to 35 sales. Also, you're going to get a lot more help by subscribing to our channel because this way you're going to get notified every time we're posting something new. Thanks for watching, guys. Have an amazing day. Bye.