13 ms·

Canonical introduces high-availability Micro-Kubernetes

210 points by sandGorgon 6y ago

InTheArena 6y ago
Microk8s just works, and it's a big reason that I am running a ubuntu derivative rather then RHEL or Centos for my homelab. It's got the right level of feature enablement with the addons, and supports the whole set out of the box. ETCD is a nice piece of nick, but I am still disappointed that other options haven't displaced it, such as consul. That said, I am not sure I am ready to trust a new distribute store for this. Its hard to get that right.
koeng 6y ago
Anyone know how this compares to k3s? I’ve been using k3s for a while, and there have been a few bugs that made me a bit annoyed
- ivan_ah 6y ago
  Same question, but with minikube.
  - koeng 6y ago
    I think minikube is for local usage. I use K3S for deploying an actual production cluster, so I’m more curious about how micro-k8s acts on that scale
    - thor24 6y ago
      > I use K3S for deploying an actual production cluster You mean when you want to run a small cluster of let's say less than 10 nodes (anything in single digits)? Why doesn't normal k8 work this way? like same tech but just less scale? (I should probably read more on the side myself as well, new to this K8 world).
      - koeng 6y ago
        Yep, it’s a small self hosted cluster on my own server hardware (VMs on Proxmox) I’m sure k8s would work, but k3s made it really easy for me to get going so now just has inertia.
        thor24 6y ago
        I see, I assumed logically Kubernetes as a community would want to keep thing simple and keep it same across scale. For large scale there could be different variations (like switching storage backend) but for small/low scale tier keep it dead simple. I am guessing there were valid reasons for the offshoots (k3s, microk8s etc.).
      - moondev 6y ago
        It does. Upstream kubeadm - authentic kubernetes - can even run on a single node. Not sure why people choose k3s or microk8s when you can just as easily deploy the real thing.
        geerlingguy 6y ago
        For smaller needs, K3s runs fast/stable on servers with 1-2 GB of RAM, whereas K8s proper tends to be a little shaky until you go to 2-4 GB, minimum.
        moondev 6y ago
        I hear this a lot but have any actual, tangible comparisons been done with k3s vs kubeadm arm resource use?
        wichert 6y ago
        kubeadm is very bare bones though; it gives you a running node but you are still responsible for configuring network and storage providers, an ingress controller and probably a load balancer.
        thor24 6y ago
        That's exactly what i am confused about when only reading these things in isolation.
- rektide 6y ago
  The first thing I think of with microk8s is their available addons, which are fairly comprehensive, opinionated, "just works" solutions for microk8s. https://microk8s.io/docs/addons#heading--list https://microk8s.io/docs/addons#heading--list As a k3s user (for local dev & my very small personal prod envs), I end up having to assemble a lot of these solutions myself. I prefer my own picks, my own solutions, and learning, but microk8s having these instantly available would be really good for a lot of folks. Until now though it has never felt like those advantages would be useful in a real prod environment, that microk8s was not interested in being in prod, but HA signals to me that they are interested in broader adoption.
- pmahoney 6y ago
  This doesn't answer your question, but I'm piggy-backing with comments on k3s. For me, using k3s for development (not prod), the killer feature is running it in --docker mode where the node uses the local dockerd to run containers (vs. managing its own containerd instance). This allows building images locally with `docker build` and immediately using them in kubernetes pods _without_ first pushing to a (possibly local) image repository and having k3s pull the images. Last time I investigated, none of kind, microk8s, or minikube supported this mode. For large images (gigabyte or more, and I've got a handful of these), it's very space-inefficient to have a copy in my docker and in a local registry _and_ in k3s's containerd at the same time. How is this problem typically solved? (I note the kubernetes included in Docker Desktop on macOS works in the same way: images built with `docker build` are available to kubernetes without going through a registry.)
  - moduspol 6y ago
    We're using img [1] with a helper script. The helper script runs a pod in the (potentially) remote Kubernetes cluster that takes the container build context as stdin, then runs img to build the image, and then imports it into the host's containerd instance. It also maps in the right host volumes so that the image build is cached between subsequent runs. I was surprised to be unable to otherwise find a good local / remote container development workflow, but this was built to replace what we were previously doing, which is setting DOCKER_HOST to point to the remote (single-node) cluster's Docker daemon (over SSH), so that docker CLI commands would execute on that remote box. In both cases, you'll still want to take steps to minimize the size of your container image build context, but the size of the images doesn't matter. I'm not sure if it'd fit your needs or not, though. [1] https://github.com/genuinetools/img https://github.com/genuinetools/img
  - TeamTeaTime 6y ago
    FYI minikube supports this via minikube docker-env https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushin...
  - bryanlarsen 6y ago
- candiddevmike 6y ago
  It uses distributed sqlite (dqlite) vs etcd/RDBMS (postgresql and friends). It's also not part of the CNCF like k3s is (yet?).
  - timClicks 6y ago
    dqlite is a RDBMS, it's just sqlite + raft
- hinkley 6y ago
  k3s swaps etcd for kine, which is an app that implements enough of the etcd API to support kubernetes. It uses dqlite under the hood, but you can use a different database if you want (though it's not clear to me if you still get Raft if you do so). It looks like Canonical is just using dqlite directly.
- sandGorgon 6y ago
  I'm running k3s in production. K3s has hooks to setup Prometheus, autoscaling (for spot instances), etc. I don't see all of these in microk8s. I'm not sure if this is on the roadmap. I'm also not sure how customisable microk8s is. We run k3s with haproxy ingress (which is not the default) and calico for network (again nog the default)
  - merb 6y ago
    sadly you need to run with kube-proxy and can't use calico's own sauce. but I already raised an issue for that, if I would use it more instead of kubespray (which I will deprecate soon) than I maybe fix it on my own time.
  - ericflo 6y ago
    microk8s has a Prometheus add-on that you can enable with one command: https://microk8s.io/docs/addons https://microk8s.io/docs/addons I'm using it and it's been great so far.
- elderbarry 6y ago
  Several commenters here say they have fewer bugs with MicroK8s, makes sense since it’s less of a modification than k3s. Slightly bigger since it keeps api and worker processes as separate binaries albeit in a single package.
candiddevmike 6y ago
This is very interesting, we're seeing a lot of Kubernetes "flavors" coming out that remove the etcd requirement. It's no secret that etcd is a key part of why Kubernetes is complex--etcd scaling/securing/recovery is really hard. I think Kubernetes would do well to make swapping out the storage backend possible without having all of these forks. Kubernetes is too tightly coupled to etcd, and for little benefit. I would wager a lot of customers would trade the guarantees etcd provides for a simpler deployment.
- jrockway 6y ago
  To some extent, the distributed consensus is kind of the important part. If you have a bunch of components that don't know what state they're supposed to be in, you don't really have a cluster. Looking at the marketing documentation (I didn't read the code), they just wrote their own consensus and datastore instead of using etcd. So the underlying fundamental computer science problems still exist, but nobody has been burned by this particular implementation yet. That doesn't inspire much confidence for me; if etcd blows up, at least someone else's cluster has blown up in the same way before. Now if it happens to you, you get to be the first person to debug it. Fun. In general, I'm not blown away with Canonical's track record. I used microk8s in its early days and it kind of blew up my coworker's computer. Networking stopped working. Making a request to localhost:5000 would return an nginx error page, even though nginx wasn't running anywhere on that machine or the network. It even persisted itself through reboots! We just reinstalled the machine eventually. It was weird stuff and I haven't touched it again. (I prefer kind locally and k3s for small "real" clusters.) Then there's Snap, major breaking changes to Ubuntu for no reason, etc. I just don't trust Canonical much, and I'm not quite ready to take a leap of faith on their new distributed database. But maybe it's great, and we'll all be using this in a year. A stopped clock is right twice a day.
  - lifty 6y ago
    Microk8s uses dqlite as a distributed database, which uses RAFT for consensus. They have their own implementation called C-raft. So if their implementation is decent it should be fairly comparable to etcd’s raft implementation.
zemo 6y ago
writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's the gist of the industry? that's really what we're doing these days?
- manigandham 6y ago
  No, that's not what we're doing at all. I agree that "microservices" is mostly useless hype but running applications reliably and efficiently is an ongoing challenge which Kubernetes solves pretty well. Of course it does shift the complexity into the underlying K8S so installing and operating it can be difficult but there are manys to avoid that as a user. Overall you gain much more in productivity and usability, which is why it's taken off so much.
  - krimeo 6y ago
    > Running applications reliably and efficiently is an ongoing challenge Is it? I can take a program written for Windows 95 and run it on Windows 7 (maybe even newer) just fine and it will run reliable and efficiently and integrate better than containers. It is problem only on Linux because user space ABI keeps breaking. Notice that the containers run on the same linux kernel and not in VMs, why? Because "we do not break userspace!".
    - lifty 6y ago
      What are you talking about? The Linux ABI is very stable.
      - krimeo 6y ago
        Linux kernel ABI is stable as rock. To answer your question, I'm talking about Linux userspace ABI - you can't rely on ABI of essential libraries, openssl for example. That's why docker was born back then.
manigandham 6y ago
Nice to see. Always thought that the API server should just be part of the cluster since it's nothing more than a proxy service over the already distributed etcd datastore.
heavyset_go 6y ago
Is there a run down on how much memory these Kubernetes flavors use? I run Docker Swarm at home because my cluster is older, decommissioned machines. The Swarm daemon uses about 50MB of resident memory, which leaves a lot of room to run containers with little overhead.
- gavinray 6y ago
  In my experience the memory usage from the underlying process are pretty negligible, and then you also need the controller/scheduler pods running. It doesn't use a ton, but in order of least-to-most lightweight IME it's Minikube -> Microk8s -> k3s But again, the overhead is marginal so it's not a world of difference. If you can run Swarm you can definitely run one of the lightweight k8s distributions.
asim 6y ago
Not to be confused with https://github.com/micro/micro https://github.com/micro/micro
gavinray 6y ago
I am all for this trend. Microk8s and k3s are both a joy to develop with (though I have ran into a few bugs with k3s so tend to prefer Microk8s). How many folks are running self-managed k8s in production though, out of curiosity? It seems so economical to deploy k3s or use something like Rancher on dirt cheap VPS's from some place like Hetzner -- but what's the ops burden and failure risk like? Never tried it myself because it seems intimidating. Use managed k8s services.
- tuananh 6y ago
  > (though I have ran into a few bugs with k3s so tend to prefer Microk8s). i tried both in my homelab and this is my experience as well. microk8s seems to has less bug for me.
- kavalg 6y ago
  Maybe not the answer you are looking for, but for small and not that critical workloads, I've so far been happy with docker swarm workloads on cheap cloud/VPS.
  - nurgasemetey 6y ago
    We run our platform in different cities and they are all on-prem(custom server or managed hypervisor). After hearing horror stories about kubernetes on prem, we are happy that we decided to go with docker swarm.
    - jakupovic 6y ago
      K8s is the new platform, you're just delaying the inevitable. Get with the program or suffer when your lack of knowledge makes you deficient in the platform uptake.
      - akvadrako 6y ago
        However, being an early adopter is not usually wise. Better to wait until lots of other people have found the bugs and improved the documentation.
whatsmyusername 6y ago
Have they pulled it out of snap yet? Not being able to pin or control when upgrades happen is a nonstarter for us.
- timClicks 6y ago
  Just pin to a channel.
  - whatsmyusername 6y ago
    If they update the channel and it causes me a production problem, no.
    - elderbarry 6y ago
      Just defer updates and do them when it suits you
blinkingled 6y ago
MicroK8s is great. The only issue I have with it is I have to use snap - things get needlessly complicated and failure prone.
nerdbaggy 6y ago
Would this be a good use case for docker swarm replacement? Right now I have about 100 containers on prem and need to find something to replace swarm
- emptysongglass 6y ago
  It's what we switched to from Swarm and it works great on anything larger than the equivalent of a t3.micro instance.
ablekh 6y ago
How is this different from multi-node k3s (aside from minor differences in CLI and, obviously, different development teams)?
pjmlp 6y ago
Some Microsoft teams also dislike k8s complexity for .NET backend development, hence Project Tye. https://devblogs.microsoft.com/aspnet/introducing-project-tye/ https://devblogs.microsoft.com/aspnet/introducing-project-ty...

210 points by sandGorgon 6y ago

Microk8s just works, and it's a big reason that I am running a ubuntu derivative rather then RHEL or Centos for my homelab. It's got the right level of feature enablement with the addons, and supports the whole set out of the box. ETCD is a nice piece of nick, but I am still disappointed that other options haven't displaced it, such as consul. That said, I am not sure I am ready to trust a new distribute store for this. Its hard to get that right.

koeng 6y ago

Anyone know how this compares to k3s? I’ve been using k3s for a while, and there have been a few bugs that made me a bit annoyed

ivan_ah 6y ago
Same question, but with minikube.
- koeng 6y ago
  I think minikube is for local usage. I use K3S for deploying an actual production cluster, so I’m more curious about how micro-k8s acts on that scale
  - thor24 6y ago
    > I use K3S for deploying an actual production cluster You mean when you want to run a small cluster of let's say less than 10 nodes (anything in single digits)? Why doesn't normal k8 work this way? like same tech but just less scale? (I should probably read more on the side myself as well, new to this K8 world).
    - koeng 6y ago
      Yep, it’s a small self hosted cluster on my own server hardware (VMs on Proxmox) I’m sure k8s would work, but k3s made it really easy for me to get going so now just has inertia.
      - thor24 6y ago
        I see, I assumed logically Kubernetes as a community would want to keep thing simple and keep it same across scale. For large scale there could be different variations (like switching storage backend) but for small/low scale tier keep it dead simple. I am guessing there were valid reasons for the offshoots (k3s, microk8s etc.).
    - moondev 6y ago
      It does. Upstream kubeadm - authentic kubernetes - can even run on a single node. Not sure why people choose k3s or microk8s when you can just as easily deploy the real thing.
      - geerlingguy 6y ago
        For smaller needs, K3s runs fast/stable on servers with 1-2 GB of RAM, whereas K8s proper tends to be a little shaky until you go to 2-4 GB, minimum.
        moondev 6y ago
        I hear this a lot but have any actual, tangible comparisons been done with k3s vs kubeadm arm resource use?
      - wichert 6y ago
        kubeadm is very bare bones though; it gives you a running node but you are still responsible for configuring network and storage providers, an ingress controller and probably a load balancer.
      - thor24 6y ago
        That's exactly what i am confused about when only reading these things in isolation.
rektide 6y ago
The first thing I think of with microk8s is their available addons, which are fairly comprehensive, opinionated, "just works" solutions for microk8s. https://microk8s.io/docs/addons#heading--list https://microk8s.io/docs/addons#heading--list As a k3s user (for local dev & my very small personal prod envs), I end up having to assemble a lot of these solutions myself. I prefer my own picks, my own solutions, and learning, but microk8s having these instantly available would be really good for a lot of folks. Until now though it has never felt like those advantages would be useful in a real prod environment, that microk8s was not interested in being in prod, but HA signals to me that they are interested in broader adoption.
pmahoney 6y ago
This doesn't answer your question, but I'm piggy-backing with comments on k3s. For me, using k3s for development (not prod), the killer feature is running it in --docker mode where the node uses the local dockerd to run containers (vs. managing its own containerd instance). This allows building images locally with `docker build` and immediately using them in kubernetes pods _without_ first pushing to a (possibly local) image repository and having k3s pull the images. Last time I investigated, none of kind, microk8s, or minikube supported this mode. For large images (gigabyte or more, and I've got a handful of these), it's very space-inefficient to have a copy in my docker and in a local registry _and_ in k3s's containerd at the same time. How is this problem typically solved? (I note the kubernetes included in Docker Desktop on macOS works in the same way: images built with `docker build` are available to kubernetes without going through a registry.)
- moduspol 6y ago
  We're using img [1] with a helper script. The helper script runs a pod in the (potentially) remote Kubernetes cluster that takes the container build context as stdin, then runs img to build the image, and then imports it into the host's containerd instance. It also maps in the right host volumes so that the image build is cached between subsequent runs. I was surprised to be unable to otherwise find a good local / remote container development workflow, but this was built to replace what we were previously doing, which is setting DOCKER_HOST to point to the remote (single-node) cluster's Docker daemon (over SSH), so that docker CLI commands would execute on that remote box. In both cases, you'll still want to take steps to minimize the size of your container image build context, but the size of the images doesn't matter. I'm not sure if it'd fit your needs or not, though. [1] https://github.com/genuinetools/img https://github.com/genuinetools/img
- TeamTeaTime 6y ago
  FYI minikube supports this via minikube docker-env https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushin...
- bryanlarsen 6y ago
candiddevmike 6y ago
It uses distributed sqlite (dqlite) vs etcd/RDBMS (postgresql and friends). It's also not part of the CNCF like k3s is (yet?).
- timClicks 6y ago
  dqlite is a RDBMS, it's just sqlite + raft
hinkley 6y ago
k3s swaps etcd for kine, which is an app that implements enough of the etcd API to support kubernetes. It uses dqlite under the hood, but you can use a different database if you want (though it's not clear to me if you still get Raft if you do so). It looks like Canonical is just using dqlite directly.
sandGorgon 6y ago
I'm running k3s in production. K3s has hooks to setup Prometheus, autoscaling (for spot instances), etc. I don't see all of these in microk8s. I'm not sure if this is on the roadmap. I'm also not sure how customisable microk8s is. We run k3s with haproxy ingress (which is not the default) and calico for network (again nog the default)
- merb 6y ago
  sadly you need to run with kube-proxy and can't use calico's own sauce. but I already raised an issue for that, if I would use it more instead of kubespray (which I will deprecate soon) than I maybe fix it on my own time.
- ericflo 6y ago
  microk8s has a Prometheus add-on that you can enable with one command: https://microk8s.io/docs/addons https://microk8s.io/docs/addons I'm using it and it's been great so far.
elderbarry 6y ago
Several commenters here say they have fewer bugs with MicroK8s, makes sense since it’s less of a modification than k3s. Slightly bigger since it keeps api and worker processes as separate binaries albeit in a single package.

candiddevmike 6y ago

This is very interesting, we're seeing a lot of Kubernetes "flavors" coming out that remove the etcd requirement. It's no secret that etcd is a key part of why Kubernetes is complex--etcd scaling/securing/recovery is really hard. I think Kubernetes would do well to make swapping out the storage backend possible without having all of these forks. Kubernetes is too tightly coupled to etcd, and for little benefit. I would wager a lot of customers would trade the guarantees etcd provides for a simpler deployment.

jrockway 6y ago
To some extent, the distributed consensus is kind of the important part. If you have a bunch of components that don't know what state they're supposed to be in, you don't really have a cluster. Looking at the marketing documentation (I didn't read the code), they just wrote their own consensus and datastore instead of using etcd. So the underlying fundamental computer science problems still exist, but nobody has been burned by this particular implementation yet. That doesn't inspire much confidence for me; if etcd blows up, at least someone else's cluster has blown up in the same way before. Now if it happens to you, you get to be the first person to debug it. Fun. In general, I'm not blown away with Canonical's track record. I used microk8s in its early days and it kind of blew up my coworker's computer. Networking stopped working. Making a request to localhost:5000 would return an nginx error page, even though nginx wasn't running anywhere on that machine or the network. It even persisted itself through reboots! We just reinstalled the machine eventually. It was weird stuff and I haven't touched it again. (I prefer kind locally and k3s for small "real" clusters.) Then there's Snap, major breaking changes to Ubuntu for no reason, etc. I just don't trust Canonical much, and I'm not quite ready to take a leap of faith on their new distributed database. But maybe it's great, and we'll all be using this in a year. A stopped clock is right twice a day.
- lifty 6y ago
  Microk8s uses dqlite as a distributed database, which uses RAFT for consensus. They have their own implementation called C-raft. So if their implementation is decent it should be fairly comparable to etcd’s raft implementation.

zemo 6y ago

writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's the gist of the industry? that's really what we're doing these days?

manigandham 6y ago
No, that's not what we're doing at all. I agree that "microservices" is mostly useless hype but running applications reliably and efficiently is an ongoing challenge which Kubernetes solves pretty well. Of course it does shift the complexity into the underlying K8S so installing and operating it can be difficult but there are manys to avoid that as a user. Overall you gain much more in productivity and usability, which is why it's taken off so much.
- krimeo 6y ago
  > Running applications reliably and efficiently is an ongoing challenge Is it? I can take a program written for Windows 95 and run it on Windows 7 (maybe even newer) just fine and it will run reliable and efficiently and integrate better than containers. It is problem only on Linux because user space ABI keeps breaking. Notice that the containers run on the same linux kernel and not in VMs, why? Because "we do not break userspace!".
  - lifty 6y ago
    What are you talking about? The Linux ABI is very stable.
    - krimeo 6y ago
      Linux kernel ABI is stable as rock. To answer your question, I'm talking about Linux userspace ABI - you can't rely on ABI of essential libraries, openssl for example. That's why docker was born back then.

manigandham 6y ago

Nice to see. Always thought that the API server should just be part of the cluster since it's nothing more than a proxy service over the already distributed etcd datastore.

heavyset_go 6y ago

Is there a run down on how much memory these Kubernetes flavors use? I run Docker Swarm at home because my cluster is older, decommissioned machines. The Swarm daemon uses about 50MB of resident memory, which leaves a lot of room to run containers with little overhead.

gavinray 6y ago
In my experience the memory usage from the underlying process are pretty negligible, and then you also need the controller/scheduler pods running. It doesn't use a ton, but in order of least-to-most lightweight IME it's Minikube -> Microk8s -> k3s But again, the overhead is marginal so it's not a world of difference. If you can run Swarm you can definitely run one of the lightweight k8s distributions.

asim 6y ago

Not to be confused with https://github.com/micro/micro https://github.com/micro/micro

gavinray 6y ago

I am all for this trend. Microk8s and k3s are both a joy to develop with (though I have ran into a few bugs with k3s so tend to prefer Microk8s). How many folks are running self-managed k8s in production though, out of curiosity? It seems so economical to deploy k3s or use something like Rancher on dirt cheap VPS's from some place like Hetzner -- but what's the ops burden and failure risk like? Never tried it myself because it seems intimidating. Use managed k8s services.

tuananh 6y ago
> (though I have ran into a few bugs with k3s so tend to prefer Microk8s). i tried both in my homelab and this is my experience as well. microk8s seems to has less bug for me.
kavalg 6y ago
Maybe not the answer you are looking for, but for small and not that critical workloads, I've so far been happy with docker swarm workloads on cheap cloud/VPS.
- nurgasemetey 6y ago
  We run our platform in different cities and they are all on-prem(custom server or managed hypervisor). After hearing horror stories about kubernetes on prem, we are happy that we decided to go with docker swarm.
  - jakupovic 6y ago
    K8s is the new platform, you're just delaying the inevitable. Get with the program or suffer when your lack of knowledge makes you deficient in the platform uptake.
    - akvadrako 6y ago
      However, being an early adopter is not usually wise. Better to wait until lots of other people have found the bugs and improved the documentation.

whatsmyusername 6y ago

Have they pulled it out of snap yet? Not being able to pin or control when upgrades happen is a nonstarter for us.

timClicks 6y ago
Just pin to a channel.
- whatsmyusername 6y ago
  If they update the channel and it causes me a production problem, no.
  - elderbarry 6y ago
    Just defer updates and do them when it suits you

blinkingled 6y ago

MicroK8s is great. The only issue I have with it is I have to use snap - things get needlessly complicated and failure prone.

nerdbaggy 6y ago

Would this be a good use case for docker swarm replacement? Right now I have about 100 containers on prem and need to find something to replace swarm

emptysongglass 6y ago
It's what we switched to from Swarm and it works great on anything larger than the equivalent of a t3.micro instance.

ablekh 6y ago

How is this different from multi-node k3s (aside from minor differences in CLI and, obviously, different development teams)?

pjmlp 6y ago

Some Microsoft teams also dislike k8s complexity for .NET backend development, hence Project Tye. https://devblogs.microsoft.com/aspnet/introducing-project-tye/ https://devblogs.microsoft.com/aspnet/introducing-project-ty...