 OK, let's get started. First of all, thanks for everyone who joined this session. My name is Yang Tang. I'm a maintainer of recording this project. Yang Tang is my GitHub handle. By the way, if you have any questions after the session and you want to ask how it's reached out to me in GitHub, my GitHub profile also consists of my email. So you can send me email as well if you like. In today's session, I'm going to discuss about several things. First of all, I'm going to give a brief introduction of Quoting Ads. After that, I will also discuss about the Quoting Ads project community as well as the latest update. And then I will discuss about the survey discovery and the DNS, especially about how to use Quoting Ads for survey discovery. Finally, I will walk through a go-long plug-in for Quoting Ads and show you how easy it is to write a go-long plug-in for Quoting Ads in less than 100 lines of code. As many of you know, Quoting Ads is a flexible DNS server written in go-long. It has a focus on service discovery. The biggest difference between Quoting Ads and other DNS server is that Quoting Ads has a plug-in-based architecture. It can be easily extended. What does that mean? If you have any new feature or anything that you want and you are not able to find it in existing plug-ins, you can actually write a plug-in yourself as long as you know how to write in go-long. Actually, at the end of the session, I will walk you through one demo plug-in to show it. Quoting Ads has been the default DNS server since several years ago. And because of that, if you ever use Kubernetes, you certainly have already used Quoting Ads. Quoting Ads is a DNS server, first and foremost. So it supports DNS. It also supports some of the DNS-related protocol like DNS over TOS and DNS over GRPC. The latest development in DNS is that there are some additional protocols like DNS over ATP3 being discussed and being standardized. We are working on adding additional protocol support for Quoting Ads as well. The biggest feature for Quoting Ads, in comparison with other DNS server, is that Quoting Ads has a very rich cloud integration. As you can see, Quoting Ads support a different cloud data sync up with different windows like AWS ROPV3, like Azure DNS, like Google Cloud DNS. The project of Quoting Ads was started by Mick Gibbon several years ago. Actually, I think Mick started the project around 2016. It has been almost seven years. So I'm going to say it's a successful project. It has been used widely across the cloud native ecosystem. It also has other usage outside of Kubernetes as well. And I will discuss a little bit in this session. Quoting Ads has a very rich community. We have more than 300 contributors. So here, I'm going to say big thanks to everyone who ever contributed to Quoting Ads project or whoever created a pull request. We have 28 maintainers. The reason we have so many maintainers is because the standard to be accepted as a maintainer is fairly low for Quoting Ads. If you ever create a significant pull request, one significant pull request, and if you can find a maintainer as your sponsor, we will add you as a maintainer. That's why you'll see there are 28 maintainers here. We also have 33 public adopters. The public adopter means if your institution or your company using Quoting Ads and your building, your company or institution are willing to share the name in public, you can add your company's name in Quoting Ads project's website. And that is called the public adopter. As we all know, there are more than 33 institutions using Quoting Ads, I'm pretty sure about that. However, many companies didn't share the name in public. That's why we only have 33. But if your company are using that and are not concerned about sharing the name in public, you can create a pull request in Quoting Ads project to add a public adopter. That also means you are going to be part of the Quoting Ads community as well. As of right now, Quoting Ads already reached the 10,000 start, which is a major milestone. If you have not done so, I encourage anyone who has not started Quoting Ads to click a star now that let's see when we can reach the next milestone. The Quoting Ads project used to be a project lead-based. So essentially, Mick Gibbon was the origin also of Quoting Ads. And he started Quoting Ads project in 2016. He has been the project lead since then. Last year, Mick decided to stepping down. We certainly respect his personal choice. And as a result, we converted the project structure from project lead model to a committee model. The steering committee of the project will be always going to be elected by maintenance. So if you want to be part of this committee, you want to create a significant pull request to be a maintenance force. Then we can see what you can do to do more contribution to Quoting Ads project. I'm going to discuss a little bit about the project update, especially since last Qubicang. Several versions of Quoting Ads have been released. The latest release was 1.10.1, which was released in February 2023. That's a couple months ago. In this latest release, it consists of several new things. We introduced a new plugin. That's a timeout. We also introduced several new features. Like ACL now allows you to drop carry as action. The template plugin allows you to create a request with extended DNS errors. The load balancer plugin added a new weighted policy. And finally, the cache plugin gives you the option to serve original record TTOs from cache. One more thing I want to emphasize about the update is the security. We all know security has been a focus for the whole industry for the past several years for different reasons. The Quoting Ads has been built with Golan 1.19 since Quoting Ads 1.10. Why is this important? Because the older version of Golan, especially before 1.17.6, has several security issues. If you're using all the Quoting Ads versions, you may notice that the Quoting Ads has several upstream-related vulnerabilities you want to fix. So that's why we encourage everyone who is using Quoting Ads to upgrade to the latest version, ideally with 1.10.1. So the next topic I'm going to discuss is about server discovery. For DNS, we serve discovery. Many people ask a question, actually, in the past. Many people ask a question about the DNS, the usefulness of DNS in server discovery. Someone even asked me directly, say, in this day and age, you have an SDN. SDN can pretty much do anything. And you can use SDN to wire up any endpoint in any way you like, like in your networking, right? Software-defined networking. Why would you still use DNS? That's an interesting question, right? There are several reasons why DNS is important. First of all, DNS is pretty much in direction. But this is a nice in direction you actually want to have in order to have maximum flexibility. The DNS itself, if you configure it properly, it can be probably a phasing, which allows you to expose to the whole internet. Or you can configure the DNS to be within a certain network, so it's going to be internal. DNS is also easy and simple to change. In fact, any no-vins ID admin can probably change the DNS record for you. That's much easier than making any other adjustment. If you're changing, let's say, cloud vendor, if you're changing, let's say, Kubernetes even configuration, it's the learning curve. But DNS is too easy to change. Another thing people probably didn't realize is that the DNS itself is a distributed system. When we talk about distributed system, people always refer to like a wrap protocol, which seemed to be quite complicated, quite fancy. But DNS itself is also a distributed system. And this is a massively scalable distributed system, because the whole internet is backed by DNS. And also, DNS has one thing that's actually many people probably in Kubicaon may not notice. The DNS actually, in Kubicaon, many people here building or operating a service that's actually customer-facing. You build a service, you want the customer to use that. But DNS has a usage here. But DNS also is part of the IT infrastructure. So your company's ID admin, they are serving the cooperation data. And in this case, they are still using DNS. That's the thing. So in Kubicaon, you're talking about customer-facing, customer-facing services. But in IT world, you're talking about corporate services, I feel. Because of that, when we talk about DNS, it still has a massive value in this day and age, because the flexibility, that's one. Another one is ease of use. And the indirection of DNS itself will give you a lot more benefit in the long run. OK, next thing I'm going to discuss is the multi-cloud. Many people already heard of multi-cloud. And many people here probably using multi-cloud. DNS is actually a nice tool to interact with multi-cloud. So first of all, why many companies decide to go with a multi-cloud or hybrid cloud? There are several reasons. The first reason is that in this world, people are facing the data solvency and data residency restrictions. If your customer from certain countries or from certain parts of the world, there are legal restrictions. And you will have to place the data in certain regions. You cannot just have one region to serve all your customers, especially in enterprise world. And because of that, you may not have a choice but to decide to go with a multiple-cloud window or even with a hybrid model of a cloud plus on-prem to serve different customers. Another reason multi-cloud has been interesting nowadays is the merger and acquisition. That's something I noticed recently. In different economic environment and conditions, a company may have consolidations. Some companies are quite another company. And the merger and acquisition should happen all the time. If a model company are combined, you'll probably realize that they're using different cloud windows. And because of that, because of the migration cost that's been so high, so a lot of times, you are forced to operate in an environment with different cloud windows. And that's why the multi-cloud itself is important. Research to DNS, again, as I pointed out just moments ago, DNS actually serves diversified source information to KubeCon, to DevOps and engineers at KubeCon. You're probably focusing on customer-facing services. But for IT admins, they're probably more focusing on corporate-facing services as well. So that's information bridging the world of IT admin as well as DevOps and engineers. In multi-cloud, if you're dealing with the cloud, you probably want to use DNS service from Cloud Window. I do want to point out that the DNS service from Cloud Window may not be as reliable as you'll believe. As of right now, as far as I know, all three major Cloud Windows from AWS, from Google Cloud and Azure DNS, give you 100% SLA. That's 100% service license agreement. However, this one is very much misleading. Why is this misleading? It's because what does that mean for 100%? If the service is disruption, what will be the consequence? The consequence, as far as I know, is that they will give you a refund for the loss of service. But they will not give you a refund for the disruption of your service. So think about how much money you're spending every year on DNS. Now you can figure out if, let's say, AWS or Google Cloud or Azure DNS has a service interruption for, let's say, a day. You probably can figure out the money is not that high. And it's probably meaningless to you if you're building a very critical service. In fact, the company I worked for several years ago, actually a couple of years ago, encountered a service interruption due to DNS outage from one Cloud Window. I'm not going to say who. The conversation with the Cloud Window was not that pleasant. Because after the calculation, we realized we are only going to get a service credit refund of about $100 or so. So the conversation, the meeting with the Cloud Window was like, oh, do you guys really want that $100 back? Or maybe we can give you some gift card. Anyway, so I'm just trying to point out, say, even though we rely on Cloud Windows, a lot of times, the consequence may not be exactly what you expect unless you go into the details of the agreement. So that's why the company we started rethinking about our strategy. And we realized DNS itself is very sensitive and a critical service. We are thinking about the potential of just building our service just as a backup. Because we cannot afford to have our critical service loss like millions of dollars, but only get a credit refund of like $100. We talk about quoting as a project. And the one interesting about quoting is that quoting is always have a cloud integration with all three windows. People may ask why you use Cloud Windows API to do integration? Why not just directly communicating with DNS server from Cloud Windows directly? I mean, certainly, UDP, you can just send the UDP packet to, let's say, roughly three DNS server and then they can exchange the data as well. The reason we use the Cloud Windows API is that most of the API are ACPI space. So it's secure in comparison with UDP. And the Cloud Windows API normally have authentication and authorization, which is much better than UDP, which is almost available. And also TCP-based protocol is certainly a lot more reliable and also give you a better error handling. And finally, the integration with Cloud Windows through the API allows us to separate the data sync up and DNS query. So you can have two channels, one channel to serving your customer, serving your, let's say, corporate IT world. And another channel is to query the Cloud Windows, like, no, like, roughly three, or like Google Cloud DNS, to do the data sync up. So again, like I said, the good thing about coding as is that you can consider coding as the central of service discovery to fetch all the information from different sources, from your IT admin, from Kubernetes, from different Cloud Windows. And you can serve the DNS in one channel to everyone. So that's the advantage of coding as in these Cloud integrations. This is an example of actual potential usage of using coding as to wire up different Cloud Windows data. This example is going to give you a, it's going to wire up for AWS, roughly three, and Google Cloud DNS, as well as your local DNS record. As you can see, you can have three plugins. The first plugin is to use the roughly three, which will talk to AWS to get the DNS information from AWS. And you can configure your coding as to fall through if the DNS record is not available in roughly three. And you can fall through to Google Cloud DNS. If the data is still not available in Google Cloud DNS, you can serve the DNS record yourself locally. This is a simple core file that will get the job done. And you can see the whole core file, it's like 10 lines of configuration. And that will achieve the result of mixing DNS data from multiple Windows as well as your local DNS. So that's one example of coding as usage in server discovery. I'm going to walk through another one that's going to be a demo plugin. As I promised at the beginning of the session, I'm going to walk through a coding as a plugin that's written in Golang. But don't worry, this Golang plugin is very simple. What this plugin achieve is that it's a source IP-based server discovery. Let's say you have a DNS server, and you want your DNS server to serve a different result based on the source IP. Let's say you're in a corporate network. You want to say, if the query is from within your corporate network, you want to return one value. Let's say 1.1.1.1.1. And let's say if the query is from outside or from the internet, you want to serve a different value. So you will have the same DNS query name, like example.org. But the result will be totally different. So how to achieve that? You can write your own plugin in Golang, and that's not going to be very difficult. I'm going to show a demo plugin. This plugin only consists of three major functions. The first function, that's a init function, will only do a one-time initialization. It will register the set of function with Cadi. By the way, for anyone not familiar with Cadi or wondering why Cadi is in the picture, CodiS was started as a fork of Cadi. It's initially CodiS was called Cadi DNS. So CodiS itself is like a plugin of Cadi itself. But then eventually it's evolved and converted to a DNS focused, I know, like a project. But initially it was a fork of Cadi. That's why you see some of reference of Cadi here. That's a init plugin. The set of plugin will do several things. Basically, the set of plugin will pass the configuration. It will be called once for each of the plugins in the core file so that your plugin can be configured properly. And finally, the server DNS is the main body of your plugin. And you want to put the functionality within server DNS to achieve what you achieve your goal. I'm going to walk through the Golang code. And you can see it's fairly straightforward. In the plugin, it's just several lines of code to register the demo itself. The set of plugin is to pass the configuration. But since the demo plugin is very simple, because we talk about what we want to achieve, we just want hard code. So the setup is very simple as well. If you have additional configuration, you probably need to go deeper. But here, we just make it simple. And finally, the server DNS function is where the true logic happens. In this server DNS, you will receive the request and the response. The state will get a state of request. And this request, from the request, you can get the query name as well as the source IP of the request. That's only two information you can get in most of the cases. As I explained, we try to return different results based on the source IP. So if the source IP is from an internal address, let's say 127 or 172, then we're going to return a unique IP of 1.1.1.1. And if the source IP is from outside the world, then by default, it will return 8.8.8.8. I pick up those two numbers randomly, because those two numbers actually are not going to be very useful. The 1.1.1.1, that's Cloudflare's DS server, and the 8.8.8, that's Google DS server. But that's just an example. You can certainly decide to go anywhere you want if you're serious about writing a Golan plug-in. But that's pretty much all you need to do to construct a demo plug-in. And you can build the plug-in easily. Before we talk about building the plug-in, you also want to have a core file associated with it. But as I explained, we try to hard code our configuration. So the core file, all you need to do is just specify a demo so that the demo plug-in will be invoked. And that's steps to build the plug-in. The building the plug-in is a little convoluted. But here, I give you one command line. If you can copy this command line, if you can run with Docker, then it will build the plug-in for you. So this one command line will give you everything. And after you build the binary, you can just run locally with dot slash coding as anti-fuel just serve your need. The demo plug-in is available in coding as website. So you can certainly take a look. I did account. The total line of code is 80 lines. So that's not a lot. And interestingly, serving different record based on source IP is one of the most requested features by community. We didn't do that, but we encourage people to take a look at Golang. And it's very simple. So you probably would rather write a Golang code yourself. Why we didn't support this is because the configuration can be very convoluted if we go with this route. People will say, hey, you have a different configuration. You have, let's say, what will be a source IP? It will be long list. What kind of format you have to present? We realize it's probably too convoluted to serve everyone's need. But if you have a specific request, say, you just want to return different result based on the source IP. And you know exactly source IP. You can just copy the demo plugin and make some small modifications. And it will serve your need. OK, so we are almost approaching to the end of the session. So I wanted to just find anyone who interested in coding as want to make contributions. There are several ways to make contribution. First of all, you can start coding as in GitHub. So let's see if we can reach to the next milestone. We are reaching 10,000 stars. So maybe we can increase the number even further, because that's the only thing matters in this day and age. You can also add the name of your institution or company to adopt this.md. That also means you can create a pull request and you'll become a contributor yourself. And finally, if you want to be a maintainer, as I explained, you only need to contribute one significant pull request. I mean, a typo or some small bug fix may not matter, unfortunately. And then you can find the one maintainer to sponsor you and you will be added as coding as maintainer. And I do want to say the coding as a community has been fairly friendly. If you contribute a significant pull request, I can guarantee you can find some sponsor to introduce you as a maintainer. OK, I think that's pretty much it. So maybe we can talk about any questions. Any questions? Hi. At the beginning of your talk, you mentioned some requests inside of a cluster might not be DNS. It was like a section, do you need DNS anymore within a cluster? And you talked about how talking to external services, you still need it. But is that ringing any bells for you? Sorry, I'm not sure about your question. Maybe you can elaborate a little with some examples. It was around service discovery. And I thought what you were saying is when one service is talking to another, it might not need to make a DNS request for that because it's handled by a bunch of other stuff. OK, so I think you're talking about if DNS is necessary. So in this day and age, we have SDN, software defined networking. With software defined networking, your IP can be wired up in any way you want. The traditional way of you have a cluster, it has to be in a certain side of block. It has a restriction, say, slash 16 or slash 24. It's not a truly relevant anymore in SDN age. Because in SDN, you can have one virtual machine side by side in another virtual machine. They can be in totally different IP. And you can even hard code a machine with an IP, right? So that's my reference to the DNS versus the so-called SDN was of static IPs. You can just say, OK, I have one virtual machine. I'm going to assign static IP. I know this static IP is 1.1.1.1.1. It will never change. So that's a question some people ask. OK, why do you still need DNS in this case? But my answer was that even in this case, you wanted to have DNS because DNS give you an indirection. And the indirection is something you wanted to maintain. And changing DNS is always going to be easy in comparison to change the SDN configuration. Even though SDN is a lot easier in comparison to many years ago. In many years ago, with your switch or router, you're limited by your switch router. But nowadays, it's the limitation of SDN is much less compared with many years ago, right? So that's my comment about the SDN or the DNS still relevant. OK, so the static IP would be like a cluster IP for a service? Is that? In your cluster, I mean, normally in your, let's say, when you try to operate in reality, your cluster may still be within the same side of block, right? Because that's easy. Because that's a traditional way of how people maintain the network. But underlying, if you look deeper, if you want to go with a SDN router, you can go anywhere you want. Your cluster can be totally shuffled with different IP addresses. And they can be totally unrelated. But you can always have a point-to-point delivery from one package can be delivered from one to another. And they can be totally outside of a default side of block. So that's why I'm saying the restriction is much less nowadays. But what should I say? Because traditionally, people operating in a way with some side of block restrictions with different hubs. So if we are going to, what should I say? Unless you are building something totally new, you probably just want to add a DNS to allow you to have a certain flexibility. And that flexibility is going to reward you in case you make a change. Got it. Thanks. OK. Any other questions? Hi, great talk. I was wondering about the plug-in system that you showed. The thing I'm wondering is, if they are chaining together, how do you know that they're not going to step on each other? So how as a plug-in writer do you know where do you plug-in compared to other plug-ins? Are you asking about question about all of the plug-in? Yeah. OK, so that is actually interesting. So you probably noticed that in quoting us, at least the plug-in has to be compiled. At least you cannot easily, let's say, dynamic load a plug-in. That's actually by design because sometimes you may need to recompile the code. If you don't recompile the code, there is an order that's specified in plug-in.config file. And it will walk through one by one. And that's one of the reasons you see the init function to initialize and set up the plug-in because if a plug-in is not in use, you probably even don't want them to go through the chain. So let me show you one example. Like in this case, if you only build a demo and your coding as you recompile with only demo, then in this case, it will only work through a demo plug-in. All other plug-in will not even be touched. But the order you can define, the order is specified in the plug-in.cfg file. Thank you. OK. A security requirement in my cluster is that I may want one tenant application to have a short list of DNS zones, which they are allowed to make lookups to. And then I have another application with a different short white list of DNS zones. And I saw your example plug-in. And I was wondering, would it be possible to, based on the caller pod's namespace and not the caller pod's IP, to serve a different IP address for the same domain? Would it be feasible to write such a plug-in? OK, so are you asking the question of, OK. So in DNS case, DNS normally have a query and a response. And the query normally carries a query name plus the source IP. Because that's only to reliable information, right? Are you trying to say that if we're manipulating the record based on the query name, if a query name is in namespace-based, is that the question? No, suppose the one DNS request originates from some particular namespace. And from that namespace, I want that only lookups towards the Google.com zone should succeed, whereas all other queries should be dropped. OK, so that might be a little tricky. So when DNS, let's say the DNS query, the only reliable information as I mentioned is the query name and the source IP. If you say you want the DNS reply to be based on the namespace, which means the namespace is going to be within a Kubernetes cluster, I think that's the question, right? In this case, I think you first have to make sure different namespace are potentially pointing to different DNS servers, right? Or maybe they point to the same server, but you have to make sure they expose a different, let's say, the DNS IP address so that you can distinguish them. I've already written such an implementation, but I was wondering if I had made things harder than they'd have to be. I'm going to say you probably need to go into the go long to make something happen. I'm not sure you can just grab a call file and make some call file manipulation to make this happen. I think some go long implementation might be needed to achieve what you want. OK, thank you. OK, any other questions? Thank you very much for the great talk. I was wondering whether you just said plugins have to be compiled, but is it possible to control Cordeon as a runtime, for example, using custom operators or custom resource definitions? So basically, I'm asking, is it possible to write a Cordeon as plugin that watches custom resources and adjusts, for example, routing at runtime? I think you mentioned the plugin compile. Are you talking about a dynamic loading a plugin? So no, when the plugin is already running in Cordeon as, is it possible that the plugin accesses the Qube API and reacts to changes dynamically? The Cordeon as a plugin, including us, actually will map the Cordeon as APIs, the back end data. So it's already achieving that. If you have any special request, special need to manipulating those data, many times it's already possible, but you have to be a little creative in manipulating core file if you don't want to go with a goal on road. Otherwise, for some of the, at least, community members, I noticed that they feel like it's just a little, no, like too hard core to go into manipulating different core file to get a little creative. They just say, OK, so it's not difficult to write a goal on, so they just write a goal on, because that's not too difficult to write a Cordeon as a plugin, as you can see, right? OK, thank you very much. OK, any other questions? OK, if no other questions, I think that's it for today. Thanks everyone for joining this session. Have a great day.