blixtra's comments

A former rkt dev here. rkt was archived by the CNCF with our blessings. Was just speaking to other rkt folks at FOSDEM about archiving the project on GH as well, which should happen shortly. We will also announce deprecation of rkt in Flatcar Container Linux very soon. rkt really changed the container runtime landscape for the best and we're happy to see that other projects improved because if it and that the space was able to consolidate a bit.

Chris from Kinvolk here. Our Flatcar builds are already completely independent of CoreOS builds. This is quite exciting for us as we can finally start updating the included software versions. We've been doing this a while for the edge channel (https://www.flatcar-linux.org/releases/) and have been waiting to do that with the other channels.

The whole point of CoreOS Container Linux was to deliver a steady stream of security/software updates. We've been eager to update packages for Flatcar Container Linux but have wanted to maintain as much compatibility as possible for as long as possible. Fairly soon, however, we'll be introducing an updated kernel and user space (systemd, Docker, etc.) into the alpha channel. For us, this will mark the point where we feel like we're fully taking the reins from CoreOS and carrying forward the original objectives.

Just to reiterate what others have said, because this comes up quite a bit. You should not use CoreOS or Flatcar images as the base for your containers. They are intended to be the host operating system upon which you run the containers. Their key features that make them an awesome host OS for containers (no package manager, for example) make them unsuitable for use as the base image of containers.

Chris from Kinvolk here.

We're happy to talk about what you need on the security front. Some of the folks working on Flatcar Container Linux have a very strong security background; worked on AWS' EC2 security team, do regular pentesting for distributed systems[1], have reported dozens of security issues to upstream projects packaged in Flatcar Container Linux, including the kernel.

We've just now started breaking away from the upstream project, and updating packages. Addressing any open security issues is front and center in our efforts. If you have concerns we'd love to hear them.

We worked with CoreOS team for years (was our founding project) and they trusted us on the security front. We feel that if you trusted CoreOS and know our team + background, you should have just as much trust in Kinvolk.

[1] https://www.youtube.com/watch?v=ze1vgh8sjlE

Happy to answer any questions about Flatcar Container Linux (https://www.flatcar-linux.org/).

It should be noted that we went a step further than CoreOS by releasing the update service we use to manage updates as an open source project, Nebraska (https://github.com/kinvolk/nebraska).

We started Flatcar Container Linux to provide the option of continuing as is. We don't like to see perfectly good software be discarded simply because of an acquisition. We understand the hassle with porting configurations and have found a good number of organizations who are supporting our effort through support contracts to continue in the manner they intended when they chose to use CoreOS Container Linux.

We also released the update service as an open source project, Nebraska (https://github.com/kinvolk/nebraska). That was something that was closed source with CoreOS. This allows you to be in control of your updates.

Kinvolk (https://kinvolk.io), the Kubernetes Linux experts | Berlin, Bengaluru ONSITE or REMOTE | Full Time

Kinvolk is a company focused on services and products for open-source cloud native Linux technologies. While having started out 4+ years ago as a consulting company (we built rkt with CoreOS, for example), we've recently added products to the mix. The first of which is Flatcar Container Linux, our drop-in replacement for CoreOS Container Linux. Building on this, we've introduced Lokomotive, our Kubernetes distribution, a major focus of development for us atm. In addition, we're building a collection of tools for debugging and security based on BPF and other low-level Linux technologies which will be integrated with our Linux + Kubernetes stack.

Kinvolk only works on/with open source technologies and all our products will be fully open source, NOT open core.

We're also the folks behind Cloud Native Rejects (https://cloud-native.rejekts.io/) and All Systems Go! (https://all-systems-go.io/)

If you're interested in working with an expert team that fully understands the the system, is passionate about open source, and building cutting edge technologies then by all means, apply within!

We have a number of openings in BERLIN, BEGELURU and remote:

* Technical Account Manager

* Visual and Brand Designer

* Events coordinator

* Kubernetes Operations Engineer (especially interested in this role being distributed to have follow-the-sun support)

* Cloud Infrastructure Engineer

* Linux Software Engineer

Find the full details at https://kinvolk.io/careers/

Kinvolk (https://kinvolk.io), the Kubernetes Linux experts | Berlin, Bengaluru ONSITE or REMOTE | Full Time

Kinvolk is a company focused on services and products for open-source cloud native Linux technologies. While having started out 4+ years ago as a consulting company (we built rkt with CoreOS, for example), we've recently added products to the mix. The first of which is Flatcar Container Linux, our drop-in replacement for CoreOS Container Linux. Building on this, we've introduced Lokomotive, our Kubernetes distribution, a major focus of development for us atm. In addition, we're building a collection of tools for debugging and security based on BPF and other low-level Linux technologies which will be integrated with our Linux + Kubernetes stack.

Kinvolk only works on/with open source technologies and all our products will be fully open source, NOT open core.

We're also the folks behind Cloud Native Rejects (https://cloud-native.rejekts.io/) and All Systems Go! (https://all-systems-go.io/)

If you're interested in working with an expert team that fully understands the the system, is passionate about open source, and building cutting edge technologies then, by all means, apply within!

We have a number of openings in BERLIN, BEGELURU and remote:

* Technical Account Manager

* Kubernetes Operations Engineer (especially interested in this role being distributed to have follow-the-sun support)

* Cloud Infrastructure Engineer

* Linux Software Engineer

* Events coordinator

* Visual and Brand Designer

Find the full details at https://kinvolk.io/careers/

True, the current Lokomotive repository consists of mostly code forked from Typhoon, something we state in the article. There are a number of small and largish modifications: support for Packet, additional PSPs, etc. But this is just the base Kubernetes portion of Lokomotive. Lokomotive includes 4 main parts, 2 of which have been release thus far. The other public portion of Lokomotive ist the underlying OS, Flatcar Linux. The integration with the recently announced Flatcar Linux Edge channel is the main motivation for releasing at this point; stay tuned for some projects that build on top of this. The other 2 parts will be rolled out this summer. Those are lokoctl, the installer, and Lokomotive Components, a collection of base cluster component.

As to why we'd do it in the first place, the answer is that our mission as a company is to support foundational Linux technologies for cloud-native infrastructure. We're not looking to create new technologies, but to improve and support those that exist and are widely used already. Container Linux fits that description to a T. Additionally, as we mention in the FAQ, we were already being asked to support Container Linux. Thus, we knew that there was demand and it fits our company mission.

So when the acquisition was announced, it was a rather easy decision to make; one that we'd already been considering. But knowing that it was also likely to face changes under new "owners" allows us to also be in the position of preserving a technology that we feel is fundamentally sound.

That's a very valid question and one we also asked ourselves before taking on the task. There are three main considerations that made us feel this is doable. Firstly, Flatcar is a minimal Linux distro, with more effort made to reduce the number of packages rather than expand. Secondly, Flatcar has not only Container Linux as an upstream, but also Gentoo, which is also a common upstream for Chrome OS and Container-optimized Linux, so well tended to. Thirdly, the technologies (kernel, systemd, containers, low-level Linux userspace) are our core focus as a company. These three considerations are what led us to feel confident in picking up the project and have the motivation to do so.

The way I personally see it, if you were ok with using an OS from a team of veteran Linux/open-source contributors in 2013 you should be ok with using one from a team of veteran Linux/open-source contributors in 2018. But this time it's from a team that does not take venture funding.

Lastly, it is telling that the ppl that have the most confidence in us pulling this off are the ppl we've worked with as clients or through open source collaborations. We're happy to start there and prove ourselves along the way to other.

Chris from Kinvolk here.

Flatcar Linux is generally available and we are committed to keeping it as a drop-in replacement for Container Linux for the long-term. We were excited about the idea of CoreOS when it was announced in 2013 and think it's a project worthy of sustaining.

Happy to answer questions about it.

Chris from Kinvolk here.

It's open for general use now. :)

Chris from Kinvolk here. As Jimmy mentioned, we've done a good chunk of the work on rkt with CoreOS and are happy to support customers using rkt, and have done so for CoreOS, BlaBlaCar, NASDAQ and others in the past.

But we've chosen not to go the startup route, which means we can only really afford to work on rkt in the context of paid work. We're looking at doing more of this in the future through support contracts for Flatcar Linux[0], a fork of CoreOS' Container Linux, which includes rkt in the images, and through the contracts we get here and there from users looking for new features in, or support for, rkt directly.

But rkt, as is, remains a great container runtime. It's our preferred runtime when running outside of Kubernetes, atm. The Kubernetes integration via rktlet[1] works well but does not have 100% functional parity with the default CRI implementation. It probably needs about 3 person-months of work to get there at this point.

So yeah, it works well, but does indeed need a bit more love. If you're interested in helping out, get in touch.

[0] https://www.flatcar-linux.org/

[1] https://github.com/kubernetes-incubator/rktlet

Right, Clear Containers is a feature of both rkt and cri-o container runtimes. rkt has had that feature for a couple years, if I recall correctly.

Kinvolk | Linux and Cloud Infrastructure Engineers | Berlin, DE | Full-time | ONSITE (or REMOTE for those that have done it before)

Kinvolk is a small (currently 12 ppl) software engineering team/consultancy focused on open-source systems-level Linux and distributed systems projects. Some our our specialties are container runtimes, (e)BPF, systemd and Kubernetes. We mostly work in Golang, C and Rust. We've worked with some of the best companies in the cloud infrastructure space; CoreOS on rkt, WeaveWorks on Weave Scope, Chef on Habitat+Kubernetes, etc.

Most of what we do is in the open, so check out our Github activity: https://github.com/kinvolk/

We are not VC funded, but work almost exclusively with companies that are.

Please see https://kinvolk.io/careers/ for the positions. INTERNS are also welcome.

We hire based on cooperativeness, respectfulness, attention to detail, and technical skill; in that order.

If not in the EU, we can help with a VISA to Germany provided you have a college degree.

Right, thx for pointing that out. This post is a follow-up to the talk Alban gave.