Cloud Native Computing Foundation Cloud Native + Open Source Virtual Summit China 2020, 11 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introduction to NATS Streams and Services on Kubernetes - Waldemar Quevedo, Synadia

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Introduction to NATS Streams and Services on Kubernetes - Waldemar Quevedo, Synadia

Streams and Services are the two main building blocks for creating applications using NATS. Streams are perfect for emitting and consuming data whereas Services can be used for endpoints that expect a response (aka RPC). Furthermore, with NATS v2 features you can use these to model the flows of your data with imports and exports that are isolated via account namespaces for multi-tenancy. In this talk, you will learn how to architect your distributed application in terms of streams and services all plugged into NATS, as well as how to best use the tooling in the `nats-io/k8s` to setup a secure multi-region NATS deployment in Kubernetes using NATS Gateways and Leafnodes.

https://sched.co/cpAq

A

Hey everyone: this is an introduction to nat's streams and services on kubernetes, my name is valdi marquevedo, I'm one of the nat's core maintainers. I currently work at scientific communications where many of the nats score maintainers are working.

A

I've been using nuts-based systems for a number of years, almost for eight years already, and I wrote a book about nets, practical nets which I was released a couple of years ago, covering many of the core concepts of using nets.

A

So in this talk, I want to briefly cover uh what is snatch. It's going to be an introduction, we'll talk about some of the abstractions when you uh talk about nets which are streams and services, uh talk about the different network, topologies that you can form by using uh nets, uh what we call the adaptive edge architectures and also give a couple of demos of using uh nuts clusters and deploying with helm on kubernetes, followed by questions.

A

So what is nuts nuts is a 10 year old this year? It's a very battle-tested system, cloud-native messaging system made for developers and operators that want to spend more time doing their work and less time worrying about how to do messaging.

A

uh What distinguishes nets is its performance, the simplicity, security and availability, trade-offs that are implicated in the design it has. A multiple quality of service has about at most once delivery and at least one delivery. uh Thanks to the simple protocol, it has multiple communication and multiple client implementations and it supports multiple communication patterns. We joined the cncf last year in 2018 under this in the landscape, cncf landscape.

A

You can see that under the streaming and messaging section next to grpc, for example, and since the uh nats contributions are ramping up for a new few years already has thousands of contributors. Many not public reports.

A

Also about over 50 million uh downloads for the nat server and live streaming server images, the slack community is also increasing and is continuously increasing. That's v2 was released a couple of years now, but uh so we're currently in the 2.17 version of the server and the performance is still pretty fast. 18 million messages per second in a single server many times a single server is all it takes.

A

If you use multiple data scenes, you can even get it to 80 million messages per second with a very beefy machine, and that's it's a single binary. It's uh has no other dependencies, uh it's very lightweight uh docker container.

A

I use that eight gigabytes. uh The protocol, which has almost not changed uh in this uh almost a decade from nets. um It's it's very simple: uh it takes base protocol. You can just use the telnet to type in the protocol and interact with the system. It doesn't take a lot of configuration. um You just should just work by default and the api is a first step forward. Just a power subscribe, one of the cool things from nets is that it uh there's a gossiping of the topology.

A

So, just as nodes join and go from the system, um they will uh their clients, will gossip each other about the network endpoints so that they can use to fail over, as I mentioned before, uh has at most once delivery for the course system. But you can also have at least one delivery by using some other sub modules, such as nut streaming and also the jet stream, which another take on that and I'm not streaming or the persistence of messages in nets.

A

That is in the work right now in the works right now and let's lead to a couple of very good features. uh Interesting features that made it are the authority and authorization schemes. You have things like end keys, which, like private and public, based uh authentication, so the centralized identities used in the jbl teams.

A

We can also have use the sans from the tls search for auth, as well as a svit from spfe certificates, also that that system became a multi-tenant using accounts, have isolation, or so you can have name spaces for the subjects and also have multiple network.

A

Topologies is more flexible and we call them um not only uh cluster connections. That has a gateways and leaf node connections that will talk about them in a bit and also uh websocket support has landed already.

A

So uh nets is its core. um Is a public subscribe messaging? uh Has uh when we're talking about the apis from nets? You can do a request reply, which is a one-to-one um singing message, expecting a response back, you can do, publish and subscribe, which is receiving um any messages well. Having a number of consumers receive the message and you can also enable uh load balancing of these uh subscriptions uh request.

A

Replies uh works by having an inbox to each one of the for each one of the messages that the other subscriber can respond used to respond so yeah at the api levels. You have a subscription, an asic handler, and you can respond into that that message.

A

Whereas poly subscribe, you can publish it and continue to publish messages and then an end number of subscribers will uh receive receive it and again, at the api level. Just uh subscribe on a subject then receive a message and use publish on through. You will receive that message.

A

You can enable load balancing for any of them, where only one member of part of that group will receive that message, so you can do um create a queue groups where you can share the work distribution distributed work among a group, the api for that is uh subscribe, and it's very similar just uh to subscribe.

A

You can also have a wildcard support. There are two different types of wildcards. You have asterisk, which is matches on a single level of the other subject, and you also have the greater than or full wildcard which will match all of the subjects um all of the world match anything that is after that that part of the subject, so um those are still at the api level. When we talk about request, reply and publish and subscribing, but when we're talking about the architecture of the system, it helps having more higher level abstractions.

A

In this case, whenever we talk about sending a request and explaining a response, what we're talking about is a service, so we start calling this and starting from not to v2 what we call these services.

A

Whereas if you have a sequence of events um that are going to be consumed by an n number of uh consumers, uh we call them streams and you can enable load load, balancing, of course, to either streams or services. But now we'll have this. uh Other level of level of abstractions will help for, especially when talking about the isolation and the permissioning about how to configure this, because they work kind of differently.

A

So for a stream against uh just a flow or just a re sequence of messages that can be consumed and will be found out, whereas service is something that is expected to require a receiver request and then do something and return a result, and the recommendation is to for this to always be load balanced when using the accounts, installation features from nets.

A

For example, in this case we have a couple of accounts: one is acme and the cncf, and we can see already how it helps having to use these abstractions for streams where we say that the account will export export, a stream named acme, which is uh the greater uh that is basically any event that is published after the greater than wildcard here, and the cnc cncf account can import from the the acme account into the acme subject, with a import prefix to receive all the events.

A

So now we can have a ticker just publishing those events on this uh any subject after acme and then the subscriber on the cncf account is going to be receiving those events.

A

On the other hand, when we talk about the stream services, we say it is expected to have a response for for that message.

A

So in this case, we have a q subscription for the hello subject that is going to be uh provided by the acme account and then the cncf account can enable data sharing between those accounts by mounting that api or the hello api from the acme account into the cncf account, and so now that under the cncf account, you make a request on cncf.hello and we receive a request, a reply back from this uh producer or world service on their acme account and all of these um another thing that um made into the nuts v2 are the flexible.

A

um They became more flexible about the architecture that you can build, um so one of the missions from nets version 2 is that make it more flexible to expand across a single data center. The vision is to not have more silos and be able to connect and not use nets, to be able to connect everything, so they have more building blocks. You can use not only clusters that were part of nasa b1.

A

You can have a gateways to connect multiple data centers and also have something called a lymph nodes which create extensions of a super cluster of a single cluster to have a hop-and-spoke type of topologies, so the classic nets architecture was, uh if we want, was to have, for example, let's say like a load balancer that is exposing the number of http endpoints and then behind. That is using nets for the internal communication using that services and, of course, that could be a highly available and that's clustered with.

A

If you, if one of those go away, then if clients will reconnect and be able to find, it still continue to talk to each other by using failover into another. That's a server.

A

So the idea with nats v2 is to have um be able to expand not only from a single data center into into a multiple ones have global deployments. In this case, we have uh super clusters which are cluster cluster of clusters, and you also have the leaf nodes that can connect connect to a super cluster, either a super cluster or a cluster, and can also uh they can even kind of be a daisy chain as well.

A

So you can have like very arbitrary topologies. Now the super clusters are optimized for one or one network links and high latency. um So where are the? The cluster type of connections are meant to be in a single data center? The gateways are more like um uh at most will give you like three hops from when routing a message from one cluster to another cluster in another region and the leaf nodes. uh Allow you to extend them, extend these.

A

um We say that error ideal for edge computing or iot, because you can delegate some of the work through the leaf nodes. For example, you can have a leaf node that is bound to localhost, so a device that can just start using a tls is very constrained. I can't talk to the leaf node, but the lymph node itself is has a secure connection to there and not super clustering. Has credentials so, let's say, for example, we have in the the pink dots they are clients. um They are connected to a leaf node.

A

We can be sending messages from a region in san francisco and then uh it is going to make it make it across the gateway connection. To let's say in this case it's gonna be an amsterdam cluster that will be building in the demo, but it is going through a leaf, node and then receiving the message.

A

So this client is not connecting directly to the super cluster but to a leaf node connection, and in case there is no connection uh here. If it was a new subscriber, then the message will be routed to another uh cluster that it can fail over to, in this case, for example, in singapore.

A

So let's build uh that type of topology uh using helm in kubernetes, so it's gonna be actually two demos. uh One is gonna, be using uh gateways uh connections between san francisco, amsterdam and singapore and from the second demo, we're gonna, create the same bot using a super cluster for communicating uh across regions, so you'll notice that the difference between uh the configuration between these two uh deployments.

A

So, let's start with uh helm. First, we have a. I really prepared a cluster in digital ocean where we have a couple of a few fireball ports open at four to two for them: nuts, clients to connect for uh 7422 for the leaf nodes and also for the gateway connection, 75 22.

A

So first I'll generate the.

A

Urls for the gateways and then I'm you're going to use it to create a helm and yammer file.

A

That has this each one of the endpoints explicitly defined. These are the external ip addresses for the node, the modes uh because it is by it, is binding into the host port from each one of these cubelets.

A

uh You could change this into using dns, for example, or a node port, if you, if it's your deployment and which is actually recommend recommended for uh production, so I will deploy this as a signal access.

A

So, let's deploy this and in case you don't have it added already. You can add the helm, charts.

A

For net now, we'll deploy into the three regions.

A

And once it is deployed, we will created a stream which essentially a a consumer of messages in san francisco san francisco. It is running this ip right now.

A

Now it's connected to san francisco and I'll send a message from singapore.

A

It's still not up yet so, let's wait a little bit okay, so you can see now the message got routed across different regions. If I make a quick telnet connection to this, endpoint you'll see that the they're very different clusters- these are cluster in san francisco once again and they connect your elsa. Basically, when the client gets to be able to identify what are the other servers uh brokers that it can uh use for to fail over when singapore is a very different cluster, but still there's communication between these?

A

uh By with the gateway connections, now we will create a service. Instead, uh let's go use a reply with foo and send a request again from singapore.

A

You can see that you can make requests across the from region to region.

A

A

Not too difficult to set up but um see easy ball involves it's a super cluster, so you involve like having to take into account the dns and having this public external. All the gateways need to talk to each other, because otherwise uh there would be partitions, but unfortunately, there's already a super cluster that you can use.

A

You can use a lyft node connections, so I've already tore down this cluster and just to compare I'm going to create a a leaf node based multi-region cluster. That is just another super cluster. To able to stitch all those regions together for this you'll need uh credentials for that super closer. In this case, I'm using an ngs super cluster and I.

A

Will use those credentials and connect as a leaf node to this other super cluster?

A

So now I will deploy this uh with helm, so you can see that the configuration is gonna be uh simpler because you already are using leveraging another super cluster for the communication between uh different uh regions.

A

This one is still connected, so I'm gonna disconnect it.

A

Represent okay, um yeah.

A

So now I will subscribe from what is that singapore now san francisco and publish messages from singapore in this communication using the leaf node connection.

A

Make a service.

A

And request response across regions.

A

They're both connected to this ngs super cluster, which is just a super cluster.

A

Yeah, that's what enables the the routing so but the roadmap. There are a few things in the pipeline uh this year, and notably the jet stream, which is the reworking of not streaming message headers, which are some of it, has already merged merchant master, but still not released yet there's a new work for exposing this service and stream apis into the client.

A

Also incoming, is mqtt support and more enhancement for monitoring and zero trust and security, and also in the future, is a more entire integration with a web assembly.

A

So that's it for my talk and as a time for questions.