
What Kubernetes users should know about the rkt container engine - pradeepchhetri
https://coreos.com/blog/rkt-and-kubernetes.html
======
philips
If you want to just try the integration today try minikube
[https://github.com/kubernetes/minikube#using-rkt-
container-e...](https://github.com/kubernetes/minikube#using-rkt-container-
engine)

This integration is about 90% complete and will completed going into 2017.

------
bkeroack
It's a shame AppC is going away[0]. OCI is pretty much just a formalization of
what Docker already does, so we're stuck with (IMO) implementation details
like layers as part of the core image spec.

0\. [https://github.com/appc/spec](https://github.com/appc/spec)

~~~
stevvooe
AppC has layers[0]. In fact, an ACI is just a layer.

While layers are codified into the OCI specification, the manifest system is
flexible and allows for future extension. The main goal of OCI is to provide a
specification for what is already widely deployed without introducing too many
new concepts.

[0]:
[https://github.com/appc/spec/blob/master/spec/aci.md#image-m...](https://github.com/appc/spec/blob/master/spec/aci.md#image-
manifest)

Disclosure: OCI Maintainer, Docker Employee

------
markbnj
It's really cool to see this stuff emerging, and the CoreOS folks put out some
good info at kubecon. We're currently running k8s on the docker engine like
probably just about everyone, but for the same reasons as just about everyone
we're interested in seeing the development of standard runtimes for containers
and orchestration. Having said that, I'm not sure I'm all in on this idea of
"pod sandboxes" as the environment in which application components are
grouped. I may just need to wrap my head around it, but after getting
comfortable with the cluster as the sandbox for applications composed of pods
I guess I haven't grasped the utility of the additional abstraction.

~~~
philips
The pod sandbox is the abstraction that replaces the "pause" container that is
used to keep namespaces open in every Kubernetes pod today.

Some techinical explanation here:
[https://groups.google.com/forum/#!topic/kubernetes-
users/jVj...](https://groups.google.com/forum/#!topic/kubernetes-
users/jVjv0QK4b_o)

So,a normal Kubernetes user will never know about rkt pod sandboxes and
Kubernetes pods will just work as expected. Only you won't have all of these
weird "pause" containers everywhere.

~~~
thockingoog
+1 Death to `pause` (and it's largely my fault in the first place)

------
djsumdog
I'm stating to really get into containers. They make sense and can keep sane
environments; keeping you away from dependency hell (at the expense of
potential security issues if you don't have tools that regularly scan and tell
you when packages within containers have security issues).

Unfortunately, the orchestration formats are all over the place. Kubernetes,
DC/OS and Docker-compose all have their own json schema. DC/OS doesn't even
support docker container volumes. Rancher can take docker-compose, and it
looks like it can deploy those apps on K8s/DCOS, however I haven't messed with
it enough to see if that actually works.

Rkt just adds even another container format. What once seemed like a nice one-
stop isolated application that you could run anywhere is becoming more
complicated and more tightly coupled to the underlying container engine and
orchestration system you chose to use.

~~~
brndnmtthws
DC/OS most certainly supports Docker volumes. What made you think it doesn't?

~~~
brndnmtthws
Or perhaps you're referring to the data volume containers. Regardless, you can
pass arbitrary arguments to the Docker daemon if you choose.

------
sandGorgon
using rkt on platforms other than coreos is hard... or maybe harder than
docker. a lot of us first try these things on our desktop and then attempt to
put them in production.

for example, the mucking about SELinux on fedora is a recipe for disaster.

my request would be to package it better. its not a bad idea to use the new
snap package (like docker).

and a page with docker cmd <-> rkt cmd would be very welcome!

------
bogomipz
The article states:

"In parallel to the image format, OCI is developing the so-called runtime-spec
for describing the runtime execution environment that container engines should
provide."

I thought the run-time spec was formalized and that we were waiting on the OCI
image format to be standardized. Is that not the case? This was from a recent
conversation I had with someone at CoreOS.

~~~
philips
The OCI runtime and image specs are currently 1.0.0-rc3. Hoping they both hit
1.0.0 final in early 2017.

~~~
bogomipz
Ah OK, thank you. Yes lets hope it arrives soon.

------
zwischenzug
Does anyone use rkt?

~~~
meddlepal
Rkt really is missing good on-boarding / Getting Started instructions. I don't
have time to figure out all the details and I really want to know how to do
the following things:

1\. Create Dockerfile like equivalents for Rkt images

2\. Share and publish Rkt images.

3\. Consume Rkt images in a Kube cluster that already supports Docker on AWS.

~~~
wyldfire
I gave it a try. The docs are good, but they could definitely be better [1]. I
found a couple doc errors and got PRs merged quickly.

[1]
[https://github.com/coreos/rkt/blob/master/Documentation/tryi...](https://github.com/coreos/rkt/blob/master/Documentation/trying-
out-rkt.md#building-an-app-container-image)

~~~
meddlepal
Thanks!

------
beders
No mention of Kontena.io ? Too new or too European?

