 Good afternoon, thanks for coming to this talk. My name is Yang Tang. I'm a maintainer of Quoding S project. In today's talk, I'm going to mostly focus on the introduction and deep dive of Quoding S project. This is my profile and my GitHub page. By the way, if anyone has any questions you want to ask, you can always reach me at GitHub with my GitHub handle, Yang Tang. So I should be available most of the time on GitHub. So this is a agenda for today's talk. So first of all, I'm going to introduce about the Quoding S project. And it's a summary of its history and its functionality. I'm also going to share the status update. Since last year, next, it's going to be the discussion of our Google summer code environment, which is one of the highlights of Quoding S. At the end, I'm going to discuss about technical deep dive of Quoding S. I'm also going to share a demo plugin. Going to show you a demo, how to write a Quoding S plugin in, let's say, 50 lines of code. Hopefully, anyone that's interested in writing a Quoding S plugin can learn something and contributing from now on. OK, first of all, Quoding S. So what is Quoding S? I guess most of people in this room already heard of Quoding S as part of the project. Quoding S is a flexible DNS server written in Go. It has a focus on survey discovery. One of the nice features of Quoding S is it's a plugin-based architecture, which means you could easily extend additional functionality if you know how to write in Go. In other words, if you see any functionality that's missing and you know how to write in Go, you can just grab your laptop and write several lines of code. Hopefully, you can come up with something that's going to be useful for you. Quoding S is a default DNS server in Quoding S now. We have been part of the DNS release since Kubernetes 1.11 and in 1.13, we became the default DNS server. Quoding S itself supports different protocols. We have support for DNS over TOS and DNS over GRPC. In addition to integration with Kubernetes, Quoding S also has roughly three DNS data sync up. So if you deploy your Quoding S in a Kubernetes cluster, you can actually wire up Quoding S with roughly three AWS backend. In this way, for any roughly three change in AWS, it can be popular to your Kubernetes cluster. This allows easy integration of your on-prem deployment with your cloud deployment and also allow a mixture of hybrid cloud deployment. Quoding S itself is started and lead by Nick Chippen. He, when Quoding S started, he used to work for Google, but now he works for another company. Actually, one interesting about the Quoding S is that when Nick started Quoding S project, he actually focused source code from Kati, HCP. I mean, I'm not sure anyone heard of Kati, HCP server before? Please go ahead. Yeah, that's great. Yeah, as you may know, Kati HCP is an HCP server with a focus on HCP tool. And then Nick actually grabbed the Kati source code, and the Fox source code. And even though Kati has nothing to do with DNS, he somehow managed to make that happen to just change the source code so that it became a DNS server. So that's why interesting. That's also one of the good things about the Golang by itself because Quoding S is really in Golang. And with Golang, a lot of things are so easily programmed such that if you want to make a niche, it's so convenient. So that's just some of the interesting trivial about the Quoding S project. I want to discuss about the Quoding S community. When Quoding S compare with some other project like Kubernetes, Quoding S is a relatively small community. However, our community is expanding. And we have a HLC 150 plus contributor at the moment. We have 14 maintenance. One thing about the Quoding S maintenance is that most of the maintenance by Quoding S are actually not sponsored by company. So we spend our time, we spend our spare time to contribute to Quoding S. So that's a distinction between Quoding S and other projects in CNCF. We also have 30 public adopters. Adopter means if a company or institution use Quoding S and they want to share us with their name and make the name public, they can announce them as adopters. So of course, we have much more users or much more company using Quoding S because of the Quoding S integration. But so far, we have 30 adopters that allow us to use their name. So that's a good thing. And also, we have 4,000 plus staffs that's in GitHub. That's probably the only thing that matters. By the way, if anyone feel like the Quoding S itself is helpful and you want to help Quoding S as well, if you haven't done so, you can certainly push a star button on GitHub. With respect to Quoding S community, the most active one obviously is GitHub. Me and me are available on GitHub most of the time. If you have any questions, you can always ask questions on GitHub. We're glad to solve the issue. We also have Slack channel as part of the CNCF with Quoding and Slack channel. This one is less popular, mostly because nowadays you have a lot of ways to do the messaging. So people use VChat here. In the United States, people may use GitHub, may use Slack. So I cannot say you will find a lot of help from Slack. But that's also, it's one of the active channels that you can utilize if you want to help. We have some other resources, but I'm not sure it's going to be very active at the moment. Since 2017, Quoding has participated with Google Summer Code program. That's a program sponsored by Google, essentially Google for any student that hasn't graduated. If you're still registered in school, you can participate in Google Summer Code. Essentially, you'll complete a project in several months. And Google will pay you money during that period. So that's a nice return for both for you and for the community. As part of this project, Quoding has participated in Google Summer Code three years in a row. The first year, we have contributed as countering to DNS tab. The second year, we have contributed as essentially have integration of ETCD. And this year, we have proposed or accepted not going to announce his name yet because he hasn't finished the Google Summer Code. So next year, I'm going to show his name here. By the way, if anyone in this room knows anyone else that is interested in participating in Google Summer Code, you can certainly apply there next year. And like I said, that's a nice return for yourself if you're a student because Google pays you money. It's also a good involvement for you to be participating in the community. So I'm going to start with technical deep dive here. The first thing I'm going to discuss is some discovery with DNS. Then I'll update some of the Kubernetes use cases because obviously, Quoding itself gets a lot of popularity because of the Kubernetes integration. I'm going to show how query are resolved. And finally, I'm going to give you a demo to just see how you can build a Quoding as plug-in in, let's say, 50-line code. So first of all, service discovery. As we all know, Quoding as a focus on service discovery. So a lot of people actually ask a question. In this day and age, with software-defined networks, everything could be virtual. You have an IP. Your IP, you can assign any IP you like in a virtual way if you deploy your networking. So why DNS is still an option? Or why DNS still could be useful nowadays? So there are several reasons for you to use DNS, even though SDN can solve most of the problems. So first of all, DNS is a very nice and flexible interaction. Research interaction allows you to stay away from future change. For example, let's say you want to migrate from one cloud to another. And your servers may be forced to have IP address change. You don't want to disrupt your user experience because you don't want to tell every user, say, I'm going to make a change because I move from, let's say, AWS to Ali Cloud or from AWS to Google Cloud. In this way, if you have DNS as an indirection, you tell the customer, say, you continue to use the same DNS name. And we'll do the back-end changes so nothing will be impacted. So that's the indirection you always want because you never know what's going to happen in the next year or the next 10 years. 10 years is probably too long. But even for the next year, you could have lots of change for your service. Another thing is that DNS itself is very easy and simple. This is a protocol that has been there for so long, such as dev developers, DevOps, and IT admins. Both of them knows. So this is very important because you could introduce a new concept like SDM, but not everyone knows what an SDM is. So with DNS, you can do a lot of things and talk to different levels and different communities. And this is very important for you when you try to deploy your service. And also, DNS has been very stable and old protocol, which means it has been there for a long time with your existing IT infrastructure. So your IT infrastructure may not be so advanced to know how to set up SDM, but they certainly know how to set up DNS. I'm pretty sure about that. So that's why you want to choose this protocol if you have a chance. Also, with DNS, you could work with a hybrid environment. Like I mentioned, we have some integration of Route 53 cloud sync up with AWS. So that means if you deploy something on AWS and you have another Kubernetes cluster, the information on both of them can be synced up and they can share each other so that you can see where the service endpoint is. And finally, and most importantly, DNS itself is a distributed system in nature. It may not be the most sophisticated distributed system, but it still scales well. So if you have a very big system that has like a thousand of nodes or even hundreds of nodes with DNS, you can easily scale up. That's not something you can achieve with other solutions. Let's go to the next topic about the update for Kubernetes. Code DNS itself is part of the Kubernetes release. So anything related to code DNS might impact Kubernetes as well. We are here for crew accounts. So I'm going to discuss about some of the changes that have an impact. So first of all, in Kubernetes, 1.11 to 1.14, we use code DNS 1.2.6. There are some, fortunately, there are some incompatible changes of code DNS which may impact things. For example, in code DNS 1.5, the health plug-in itself has been replaced with health already. GRPC plug-in has been introduced. Also, there are some other changes. For example, the multi-APS server endpoint no longer supported. You can still, if you have a code that talks to Kubernetes and your code DNS is not part of the Kubernetes cluster, you can still point, you can still talk to Kubernetes, but you cannot talk to multiple API servers anymore. And also, the API server resync has been disabled. This is quite debatable, but the decision is that we want to move forward with the disabled API server resync. Just for your convenience, that's a backward incompatible change. So if you're going to update to code DNS 1.5.0, you need to take notice of those changes that may impact your Kubernetes cluster. So this is a diagram that shows how code DNS results query. So first of all, code DNS for each query is always based on the root of your query domains. In this way, here you could see different domain names have different plugins enabled, like for organization.com. You have errors, cache, and forward plug-in enabled. By default, you have a much larger list of plugins enabled, like errors, chaos, Kubernetes, and also forwards. When query comes in, first it's going to find out the suffix domain. That's going to see if it's a match. If it is a match, it's going to go through each plugin and traverse through the plugin one by one until one plugin decides this plugin is going to do the job. If this plugin do the job, it's going to return back, give you the query, and the process will stop. If the plugin captures a query and this plugin cannot figure out if it needs to process one out, then this plugin will essentially let the query to follow through to the next plugin. So the next plugin will pick up the query and decide if they want to return one out. So that's a workflow of resulting a query in code DNS. Now let's get to the point of the demo. I know everyone probably want to see some true demos nowadays. So the demo plugin is a very simple thing. It's essentially a source IP-based survey discovery. We talk about service discovery. We talk about code DNS. So what exactly is survey discovery? Survey discovery, essentially, is a way to resolve an endpoint to IP address. But if you say I have a service and I know this IP is static, so that's not a point. Because if it's one-to-one match, what's the point of having a map by itself? So here I'm going to show you why survey discovery could have complications. Let's say you have a cluster. And your cluster has internal IPs and external IPs. Of course, when some of the nodes try to contact your service, it might be outside of the cluster. It might be also inside the cluster. If it's outside of cluster, it might contact the endpoint. That's actually going to the public IP. If your node is inside the cluster itself, you'll probably want to assign a private IP. So in this case, as you can see, let's say you have a cluster with a private IP of 172.0.0.8, which is very common, if you've ever played with Kubernetes. Let's just do it this way. Let's say from outside, if a query is from outside, and your query is example.org, let's say for some testing purpose, we're just going to return your IP of 8.8.8.0. It may carry some meanings, but it's probably relevant. Let's say internally, if a node tries to query the DNS with a record of example.org, it's going to return a different IP address. Let's just assume it's 1.1.1.1. So let's set up to demo in this demo plugin. By the way, it's 8.8.8.0. That's DNS server provided at Google. And 1.1.1.1.1 is a DNS server provided by Cloudflare. They have different purpose and different strengths. I'm not going to discuss about which DNS is a good one, so it's up to you to decide. So let's just go to the source code directly. So I'm going to walk through the source code so you could take a look and see how easy it is to write a query as plug-in. So before you want to write a plug-in, so first thing is that you need to initialize. You need to set up your plug-in. To set up plug-in is fairly easy. As you can see, there is an init function that's actually in Golang. Essentially, it's going to just bring this plug-in. Bring this plug-in up. You'll register yourself, which is a demo. And then you'll register an action, which is a setup. The setup is actually doing almost nothing, except it just acknowledges that this setup capture the content of the call file, say, I'm going to be responsible for demo plug-in. So that's fairly straightforward, right? So let's get to the serve DNS. The serve DNS is the main body of a plug-in. With serve DNS, you essentially implement this function to decide what you're going to do with the DNS query. As we can see here, serve DNS passes a DNS response writer. It also passes a message. So R is the DNS message. That's a query message that you need to take a look and see what you want to do. Response writer, it's up to you to decide if you want to just return back to give the query the response. Or you want to let the plug-in process to fall through to the next plug-in. The first line, as you can see, is just to try to state equals request dot request. This is essentially just allow you to capture the state of the request. You get a queue name. That's a query name. And you can decide if you want to reply IP address. As we discussed here, you want to reply different IP address based on where the query comes from. If the query is coming from a private IP address, let's say 172, which means it's actually internal. Or if a query is from IP address of 127, which actually means it's actually local query, you're going to return 1.1.1.1.1. Otherwise, you're going to return an IP address of 8.8.8. The next line, as you can see, is just a printout. This printout is unnecessary. But for the demo purpose, you want to just print out something so you can see what's happening. So let's continue. So we get the first part, the second part is essentially you can decide what you want to reply. Now you need to construct a DNS packet, reply packet. The packet, essentially, is just you have a resource record of header with type A. And the class is an INET type. You, as we discussed, we have different IP address to be returned. So we just take the IP address and inject that into the response packet of a DNS. And we decide to return. That's actually pretty much it for our plug-in. If anyone has ever played with coding, as you'll probably know, in order to set up coding, you also need a core file. A core file itself is also very straightforward. As you can see, by default, our plug-in is disabled. You find the INET-1 plug-in, you just write the line. In our case, we have a demo. We just enable demo. And that's it. So we don't want to have any other configurations. Of course, if you have an interest, you can dig deep into the core file setup and see how play with the coding as plug-in. The next step, as we mentioned, we already have everything ready. The next step, of course, is how to build that. We have a source code of a setup. We have source code of a DNS. We have a core file. Now, the next step is to build a code-in. To build a code-in, it's also very fairly easy. You add a demo, column demo, to plug-in.config. This is all you need to enable everything. The next step is to compile. In order to help everyone and to make the process convenient, there is one way to build a plug-in. That is to reuse a docker. I've been with the docker community for a long time, so I'm certainly more familiar with this concept. If you want to build a, of course, you can build your code-in as in a go-long environment. But in case you don't want to install go-long, or in case your go-long environment has some setup, you are not feeling comfortable to mess up with. You can just install docker, and as long as you have a docker installing a machine, all you need is just one line to compile that. See, if you look at this line, this line essentially just grabs a go-long as 1.12 for a docker image. And this allows you to run a command line inside a go-long. And in our case, we are going to use make.gen, which is going to generate the necessary, generate additional files that's required to build a plug-in. And the next step is make, which is going to give you the binary. And that should be it. If you run a code-in as from your command line, that's all you need. So I'm going to escape the PowerPoint slide and show you the demo. So just to make it simple, I already set up file here. As you can see, one file is a plug-in.config, which is essentially just one line changed. That's fairly easy. Another thing is, let's just add everything so we can see which file has been changed. Only add two files. The first file is setup.go. If you look into this one, that's straightforward. So how many lines? That's only 20 lines. So that's all you need to set up and register demo plug-in. So next file, let's take a look. OK, this is slightly more than several lines. But as you can see, it's still pretty much straightforward. We have a serveD as which is the main body of your process. The logic is quite clear. As I mentioned, by default, we are going to return a.a.a.a. But if it's an internal IP, it's from an internal IP, from a private IP, then we are going to say, OK, let's just return a different IP address. That's going to be 1.1.1.1.1.1. So that should be it. So let's just run this command. Let's see how we could build everything. Oh, OK, let me. OK, yeah, it's actually building. So let's just wait probably like one minute to wait until the binary has been built. And then I'm going to show you. Use dig to see how to query that from internal and external interface and see how different IP addresses are being replied. I already opened a two-window here. One window is actually part of the machine. This one is on the same machine as the machine building. So you could consider this one as an internal node. And I have another machine. I have another window that's actually to my laptop. Of course, this one is external. So ideally, if I'm going to set everything up, we should be able to see different results if we do the query. Almost there. It's going to take some time, but I think we're almost there. OK, now let's see. We have a binary file, which is coding as it's already. The binary has already been generated. We need a core file, which is just one line. Let's actually just remove the one line. OK, that's pretty good. It's up and running. Let's just go into the same machine. Let's just do a dig. By the way, since I set the port number to be 1053, so I'm going to use a minus p to talk to a different port number, because the default port number is actually occupied by your system. But that should be easily configurable if you're in a true production environment. Let's just, as you can see, because it's internal, so that's going to be 1.1.1.1. I'm actually pointing to 172, which is a private IP address. Now let's get to my local machine. My local machine that's actually outside of this cluster. So I'm going to dig with a different IP address. Let me see which one. See, that's a result we expect, because I'm actually query the DNS from my laptop. My laptop is not a part of the build server that's running on the left side. So you see that's 8.8.8. That actually gives you the idea of how to build a plugin. You can see everything has pretty much packed into two files with a favorite line of code. That's all you need for having to write a plugin. So the last thing I want to mention is if you already showed how to write a plugin, so if you have interest to contribute, of course, we will command contributions. You have several ways to help coding as. You can start coding as in GitHub. If the company you work for or the institution you work for use the coding as, and you're willing to share your name, you can start it as a name to adopt.md. This is also a way to open your first pull request and become a contributor. You can also participate in GitHub or select discussions. And finally, if you have an interest, you want to be a maintainer. Actually, if you are a maintainer, coding as you are also a CNCF maintainer. So it's just kind of like a badge. Give you some nice frame if you are interested in that. So the way to become a maintainer, the barrier is pretty low if you can complete a pull request with a significant content. Of course, if it's just a typo, that's not going to count as a maintainer. But if you can add a functionality, that's going to be significant. And there's just one pull request, that's all you need. If you can find an existing maintainer that's a sponsor to be a maintainer, then you're part of the coding as maintainer community. And also your CNCF maintainer now, which is a very nice thing for everyone. I think that's pretty much it for today's talk. Just any questions? Anyone want to discuss? Yeah, sure. Which one? Sorry. Wait. You mentioned that there is no longer need upstream. Is that replaced by the plug-in, plug-in mechanism? I think this is handled automatically. Unfortunately, this part is not very familiar with the way the upstream works. But if you have some question, I think you can open the e-show in GitHub. If I think I can find someone to answer your question. Any other questions? One question. Does coding support DASDAQ to IPv3, IPv4, and DOSDAQ? Can you repeat the question again? Does coding support DASDAQ or dual stack? Sorry. Oh, you mean dual stack, IPv4, combination of IPv4 and IPv6, right? Actually, that's the question, right? That's an interesting question. I believe it should, but no one tested that before. But you can open the e-show. If it doesn't support, I'll try to make sure it works. Yes. Any other questions? Okay, yeah, sure. Okay, we are almost running out of time, but I can quickly just explain a little bit. Qubi-DNS was part of a Kubernetes at one point, and it's actually just a combination of different software. This Qubi, it's actually just a small script with DNS mass scale, which is a DNS server written by C, and this is another container. So, in order to deploy Qubi-DNS, you need to have three containers. In Qubi-DNS, they actually combine that into one. At one point, actually, it's a collaboration between Qubi-DNS team and the Google, and the Red Hat, and the Kubernetes team. So, we collectively decide that Qubi-DNS probably is a solution moving forward. So, we essentially just say, okay, let's introduce Qubi-DNS as a default DNS server, and let's deprecate Qubi-DNS. So, Qubi-DNS will be deprecated pretty soon. Any other questions? Oh, okay, one more question. I run Qubi-DNS in some offline environment, and then I cannot connect to upstream DNS server. So, how can I configure Qubi-DNS upstream? I configure Qubi-DNS. Upstream? The upstream? When I cannot connect to outside the DNS server, then I configure Qubi-DNS, Qubi-Fail upstream, then I configure upstream, upstream or configure. I cannot, just I run Qubi-DNS, then report me on I run loop detected, and the Qubi-DNS cannot start up. I can't say I'm not so sure about your question, if you can, I think in contact issue, we can fix the upstream with Qubi-DNS. I think if that's the case, maybe I would encourage you to open an issue in GitHub, so I can take a look because it's hard to give you answer without all the contacts at the moment. Okay, okay, thank you. Yeah, okay, yeah. Like I said, if you have any questions, you can always open an issue on GitHub, both me and me could probably should be available most of the time, so yeah. Hopefully that can help solve some of the issues you guys encounter. Okay, I think that's it. Thank you so much for coming here. Have a wonderful day, and enjoy your stay. Thank you.