Can Kubernetes implement a container that is not a Docker container?

Kubernetes can orchestrate a container which is not a Docker one, and that is because of cri-o

As explained in Kubic:

Contrary to what you might have heard, there are more ways to run containers than just the docker tool.
In fact there are an increasing number of options, such as:

• runc: a CLI tool for spawning and running containers according to the OCI specification.
  (OCI: Open Container Initiative: An open governance structure for the express purpose of creating open industry standards around container formats and runtime)

• rkt from CoreOS, now (June 2019) almost dead, and with multiple pending security issues.

• frakti: an hypervisor-based container runtime for Kubernetes, which lets Kubernetes run pods and containers directly inside hypervisors via runV.
  It is light weighted and portable, but can provide much stronger isolation with independent kernel than linux-namespace-based container runtimes.

• cri-containerd: the Containerd Plugin for Kubernetes Container Runtime Interface (it started as a standalone cri-containerd binary, which is now (since March 2018) end-of-life. cri-containerd is transitioning from a standalone binary that talks to containerd to a plugin within containerd.

• and more.

Most of these follow the OCI standard defining how the runtimes start and run your containers, but they lack a standard way of interfacing with an orchestrator.
This makes things complicated for tools like kubernetes, which run on top of a container runtime to provide you with orchestration, high availability, and management.

Kubernetes therefore introduced a standard API to be able to talk to and manage a container runtime. This API is called the Container Runtime Interface (CRI), Dec. 2016.

Existing container runtimes like Docker use a “shim” (dockershim) to interface between Kubernetes and the runtime, but there is another way, using an interface that was designed to work with CRI natively. And that is where CRI-O comes into the picture.

Introduction to CRI-O

Started little over a year ago, CRI-O began as a Kubernetes incubator project, implementing the CRI Interface for OCI compliant runtimes.
Using the lightweight runc runtime to actually run the containers, the simplest way of describing CRI-O would be as a lightweight alternative to the Docker engine, especially designed for running with Kubernetes.

As of 6th Sept 2018 CRI-O is no longer an incubator project, but now an official part of the Kubernetes family of tools.

So it is important to understant cri-o, in order to get the relationship between Kubernetes and the containers it orchestrates.

See "Cloud Native Computing Foundation adopts CRI-O container runtime+tutorial"

It includes the architecture schema:

Sequence of launching new pod

1. Kubernetes control plane contacts the kubelet to launch a pod.
2. kublet forwards the request to the CRI-O daemon via kubernetes CRI (Container runtime interface) to launch the new pod.
3. CRI-O then uses the containers/image library to pull the image from a container registry.
4. Downloaded image is unpacked into the container’s root filesystems, using containers/storage library.
5. After the rootfs has been created for the container, CRI-O generates an OCI runtime specification json file describing how to run the container.
6. CRI-O then launches an OCI Compatible Runtime using the specification to run the container process.
   Default OCI Runtime is runc for now.
7. Each container is monitored by a separate conmon process.
8. Networking for the pod is setup through use of CNI (Container Network Interface), so any CNI plugin can be used with CRI-O.

Kubernetes implements a wrapper over the existing docker container(s), the wrapper named as pods. The reason behind using pod rather than directly container is that kubernetes requires more information to orchestrate the containers like restart policy, liveness probe, readiness probe. A liveness probe defines that container inside the pods is alive or not, restart policy defines the what to do with container when it failed. A readiness probe defines that container is ready to start serving.

So, Instead of adding those properties to the existing container, kubernetes had decided to write the wrapper on containers with all the necessary additional information.