Mirantis Blog

Mirantis (https://www.mirantis.com) | Ceph/DevOps/SRE | Remote[US|EU] | Full Time I am looking to add Ceph engineers to my product engineering team! Join us to help us to provide the best opensource storage experience to our customers by integrating Ceph with OpenStack and K8s using Salt, Python and Go. Apply direct here: USA - https://grnh.se/a442fd061 EU - https://grnh.se/9b82f31e1

We are hosting the Bespoke Kubernetes Challenge, an exclusive contest where participants have the chance to win a grand prize of $10,000 USD! This contest is designed to showcase your skills and expertise in Kubernetes, the leading container orchestration platform. I believe that your experience and knowledge in this field make you a perfect fit for this challenge. It's a fantastic opportunity to demonstrate your prowess in Kubernetes and potentially win a significant cash prize. To learn more about the contest and how to participate, simply visit the following link: https://www.mirantis.com/kubernetes-challenge/

Swarm is on its way out. Mirantis bought that part of Docker and they said this: "The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users." https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-plat…

I worked a little bit with OpenStack about four years ago, and my impression was that it was very design by committee. Design by committee doesn't work too well in software: https://sourcemaking.com/antipatterns/design-by-committee I think a lot of the enterprise companies supporting OpenStack, like Mirantis (https://en.wikipedia.org/wiki/Mirantis), realized this one way or another, got themselves acquired, and then used the new funding to pivot to Kubernetes or another open-source IaaS offering: https://www.mirantis.com/ Without any promise of enterprise support, there's really no way for the large companies targeted by OpenStack to adopt it and make that adoption sticky. So that's how it died.

> ...it doesn't burn much CPU at all unless... You noticed that I said "(intermittently) half of the CPU power", yeah? > Third, try to remember that you're running a tool that provides most of what you need to run a service... I already get everything that I need to run a service with old-ass systems like OpenRC+netifrc or -hack, gag- systemd and its swarm of dependencies. "Run a service on a *nix box" is a thing that we've had pretty well nailed down for decades now. It is -after all- how the services that run Kubernetes get run. Do note that you're talking to someone who does Linux system administration both as a hobby and professionally. > Sorry I meant k0s. Off by one error at 3 am. Sure, no problem. Shit happens. So, k0s? Compared to minikube, the official minimum spec tables [0] indicate that -if you colocate the controller and worker- it cuts the CPU and RAM needs in half, and cuts the disk space by a factor of ten. That's nice, but that's still an eighth of the RAM and (intermittently) a quarter of the CPU of our hypothetical-but-plausible castoff laptop. That's still a lot of resources. And compared to what it costs you, you don't get much. If we were talking about some big, bad, mutually-untrusted-multitenant situation, it could be worth the cost, but -despite what folks like the CNCF might like you to believe- that's not the only scenario out there. Also Mirantis is responsible for k0s? [1][3] After their rugpull with their Openstack distro way back when, I…

Sandboxing. The new way of doing containers. I'd think of it as plugins everywhere, like L7 proxies [1]. The code for a network filter could be reloaded in the server upon detection to a configuration change. I believe the startup mad dash is on to capture who is going to run the container runtimes, and host the plugin repositories. So my guess is that Fermyon Technologies with Spin could be looking to follow the Vercel with NextJS model where everything will be open source and runnable from the development runtime, but there eventually will be features like Edge Functions [2] in five years that will only be available when you deploy to their hosted service. They'll likely work towards that with web services with Spin [3] and CMS with Bartholomew [4] for starters. Instead of everything linked together in a NodeJS app directly, your code will run from a WASM library in a sandbox. But my guess about the Vercel model could be slightly wrong after checking out their solid founding team [5] -- the bios emphasize the WASM and Kubernetes worlds. The problem if it is something like the Docker model is that the standard will just be made with the big players like OpenContainer [6] and the enterprise business sold off [7], and/or folded into one of the cloud infra players (with the data centers). [1] https://github.com/proxy-wasm/spec [2] https://vercel.com/docs/concepts/functions/edge-functions [3] https://spin.fermyon.dev/ [4] https://github.com/fermyon/bartholomew [5]…

Kubernetes requires a tool which implements the Container Runtime Interface (CRI), a standardized API for starting & managing containers. This is from 2015-2016[1]. The CRI interface is defined by & owned by Kubernetes, and there's a lot of implementations: runc, crun, youki, dockershim and likely more. For a while Kubernetes has included something called the "dockershim", it's own implementation of a CRI interface that, under the hood, calls Docker or Podman, so Kubernetes "pods" run in Docker/Podman. There's also tools like Kind[3] ("kubernetes in docker") that go further- not just hosting Kubernetes worker containers in Docker, but hosting the main kubernetes daemons also in Docker. Kubernetes deprecated Dockershim, formally in December 2020, but is just throwing the switch now in the upcoming 1.24, expected mid-April[4]. A company Mirantis has pledged to take over support of Dockershim[5], and is calling the new effort "cri-dockerd"[6]. This should allow Kubernetes workers to continue to run via Docker or Podman. Kind is unaffected, since it runs the main Kubernetes controllers in Docker, which then launch their own opencontainerd (one off the main CRI implementations) inside that Docker container, nested like, so no dockership/cri-dockerd is needed). Worth re-noting that Podman includes tools to try to run Kubernetes pods directly, without running the rest of Kubernetes. [1] https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-… [2]…

> Mirantis is just some cloud hosting provider and from what I can tell it has no connection to Docker. I'm generally interested in why all the FUD around Docker and Swarm. Can you support these FUD statements with some legit news stories or blog posts from the people involved at Docker? https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-plat… > Today we announced that we have acquired the Docker Enterprise platform business from Docker, Inc. including its industry leading Docker Enterprise and 750 customers. > What About Docker Swarm? > The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users. Mirantis owns essentially all of Docker, outside of Docker for Desktop (someone correct me here if I'm wrong), now. They are saying that Swarm is not the future of Docker. It's entirely possible that the remainder of Docker, now a developer tooling company, will continue with Swarm, but it seems unlikely. Also possible the community will keep it alive. None of those maybes are things I'd bet my platform on though.

I did describe both (Google could do a much better job with the integration on GCP/GKE), but by "Kubernetes first" I meant the latter. Databases run fine on Kubernetes and have been doing fine since 1.7, and the meme that Docker is bad for stateful apps is a getting a bit old. The challenges are mostly the same as with running databases on a VM or bare metal. In particular, you need to know how to manage HA. The weakest point is perhaps that Kubernetes's scheduler completely ignores disk I/O, so you have to bare careful to avoid sharing a node with multiple disk-heavy apps that will compete for resources. This is includes the file system cache; for example, PostgreSQL works best when it can rely on the OS to cache pages, so you don't want other apps (including Docker and Kubernetes themselves) to compete there. That said, I wasn't saying that a hosted solution shouldn't also offer VMs. Just that Kubernetes should be the main entrypoint and control plane. And someone figured out a way to run VMs via Kubernetes [1], which is a neat example of a solution to the lack of integration I was complaining about earlier. [1] https://www.mirantis.com/blog/virtlet-run-vms-as-kubernetes-pods/

Mountain View Ca - Fulltime: Mirantis is an OpenStack solutions and technology company help the wider adoption of OpenStack as well as contributing substantially to it development, and extending its capabilities via our own technology and products. We are hiring a range of positions: Engineering - http://www.mirantis.com/careers/ Cloud Platform Services Architect Mountain View, CA, United States Customer Engagement Program Manager Mountain View, CA, United States OpenStack Cloud Architect Mountain View, CA, United States OpenStack Deployment Engineer Mountain View, CA, United States OpenStack Operations Engineer Mountain View, CA, United States Python Engineer – OpenStack Community Mountain View, CA, United States Sales/Solutions Engineer Mountain View, CA, United States Sustaining Engineer for OpenStack Deployment Well funded, great customers large, complex and interesting projects - great pay, benefits and flexibility. Email me: [email protected]

Swarm is a Mirantis product now. You just ask the wrong people Read more on https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-plat… and "What About Docker Swarm?" section

Swarm isn't dead: Mirantis still puts engineering resources into it and has plenty of businesses relying on it. Bunch of new features just released for https://www.mirantis.com/blog/announcing-the-23-0-major-release-for-mi…

Good question. - Mirantis (the new maintainers of SwarmKit) have an article on that https://www.mirantis.com/blog/kubernetes-vs-swarm-these-companies-use-… - A recent list is here: https://github.com/collabnix/dockerswarm#companies-using-docker-swarmo… - I sell two Swarm courses on Udemy that are purchased daily and I've noticed more questions on Swarm lately. Not a lot, but more than a few each week. - My Discord server had enough chatter on Swarm that a few months back we made a #swarm channel and it's now a top-3 channel (12k members) https://devops.fan

Source? It is rather the opposite based on mirantis latest blog post on Swarm https://www.mirantis.com/blog/docker-swarm-webinar-qa-long-live-docker… > It all stems from when Mirantis first acquired the Docker Enterprise business two years ago, they put out a blog saying, “We’re gonna support Swarm for at least two more years and we’re gonna take that time to kind of see what the need is, what the market dictates…” > Unfortunately, some third parties took that and said, “Oh, they’re only going to support it for two years and then they’re going to sunset it.” That’s not true at all. This is important to us and to our future direction. We continue to invest in it and we have lots of large enterprise customers using Swarm in production at scale.

You're not wrong to worry (scroll down to "What about Docker Swarm?") https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-plat…

"conversations have led us to the conclusion that our customers want continued support of Swarm without an implied end date." https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-de…

> Swarm is a (sadly) soon-to-be-abandoned way to spin up a cluster of multiple hosts with Docker daemons; don't waste your time on it. It seems this inevitable abandonment has been abandoned as of Feb 24, 2020... https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-de…

It was announced a ~month ago that Mirantis (Aquirer of Swam and Docker Enterprise) will continue to develop Swarm with no implied death date. https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-de… It is also an open source project, so even if the corporate overlords abandon it, the code could live on!

Anyway, it fills the gap between single node docker-compose and k8s. Because you can use docker-compose against swarm instance (so your app is running across multiple hosts) Swarm is so simple. Few commands and you can start scaling, routing, load balancing, desired state reconciliation https://docs.docker.com/compose/production/#running-compose-on-a-swarm… Yeah, there is a concern about the docker swarm future: https://github.com/docker/swarm/issues/2965 But mirantis just last week announced they will support and INVEST in docker swarm: https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-de…

Here's a commitment from Docker's new overlords to support swarm for the next 2 years: https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-de…

Kubeadm works just fine with a single node configuration, you just need to untaint the master so it can run non-control plane components. https://www.mirantis.com/blog/how-install-kubernetes-kubeadm/ has a decent step-by-step. It's mostly just the standard install but they have details on the untaint bit too.

I was at their keynote in one of the Openstack summit. I can guarantee that at least the VP that spoke about it knows nothing about openstack, and were just using Mirantis to deploy. They just threw Buzzwords around, one of which was Fuel[0] [0]: https://www.mirantis.com/software/openstack/fuel/