Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Docker Depricated in Kubernetes, What about Podman

Estu Fardani
December 15, 2020

Docker Depricated in Kubernetes, What about Podman

Salindia untuk Kelas Tech Cloud Akakom

Estu Fardani

December 15, 2020
Tweet

More Decks by Estu Fardani

Other Decks in Technology

Transcript

  1. Docker Deprecated in Kubernetes. It is true? Yes it is

    true. But not like what you think. In short, what it means here is that Docker does not support Kubernetes Runtime API called CRI(Container Runtime Interface). Kubernetes people have been using a bridge service called "dockershim". It converts Docker API and CRI, but it will no longer be provided from Kubernetes side within a few minor releases. In short: Design of Docker is not well-perfect use when running at Kubernetes How Kubernetes Part will communicate? Kubernetes is an infra orchestration tool that groups up many different compute resources such as virtual/physical machines and make it look like a huge compute resource for your application to run and share with others. In this architecture, Docker, or a container runtime, is used only to run those applications in an actual host by being scheduled by Kubernetes control plane
  2. Each Kubernetes node talks to the control plane. kubelet on

    each node fetch metadata and it execs CRI to run create/delete containers on the node.
  3. But why is Docker deprecated? Having more features while you

    never use, itself can be a security risk. The less features you have, the smaller the attack surface becomes.
  4. Not all docker feature need on kubernetes And features are

    not modular, so move to other container runner / CRI. Container Runtime Interface (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a protocol buffers and gRPC API, and libraries, with additional specifications and tools under active development. - containerd - cri-o TL;DR: CRI is an API that Kubernetes provides to talk to a container runtime in order to create/delete containerised applications
  5. Last support~ dockershim as bridge service. kube 1.20 still can

    run with docker, but will print error. It will not be removed before Kubernetes 1.22, meaning the earliest release without dockershim would be 1.23 in late 2021.
  6. CRI Runtimes containerd Containerd is actually used inside of Docker

    to do all the "runtime" jobs. They provides CRI and it's 100% what Docker provides, too. containerd is 100% open source so you can see docs on GitHub and even contribute to it too. https://github.com/containerd/containerd/ CRI-O Mainly developed by Red Hat folks, used in Red Hat OpenShift now. Yes, they do not depend on Docker anymore. Interestingly, RHEL 7 does not officially support Docker either. Instead, they provide Podman, Buildah and CRI-O for container environment. https://github.com/cri-o/cri-o CRI-O's strength is its minimalism. They are pure CRI runtime so CRI-O does not have anything that CRI does not require. It can be more challenging to migrate from Docker to CRI-O because of that, it still provides what you needs to run applications on Kubernetes.
  7. So what a CRI runtime does is the following 1.

    Get the gRPC request from kubelet 2. Create OCI json config following the spec
  8. OCI Runtimes OCI runtimes are responsible for spawning a container

    using Linux kernel system calls such as cgroups and namespace. - runc - gvisor
  9. runc runC spawns containers after CRI executes the binary by

    calling Linux system calls. That indicates runC relies on the kernel that is running on your Linux machine. It also implies that if you ever discover runC's vulnerability that makes you take the root privilege of your host, a containerized application can also do so. A bad hacker could take your host machine's root and boom! Things surely will get bad. This is one of the reasons why you should keep updating your Docker(or any other container runtimes) too, not just your containerized application.
  10. gVisor gVisor is an OCI runtime that were originally created

    by Google folks. It actually runs on their infrastructure to run their Cloud services such as Google Cloud Run, Google App Engine(2nd gen), and Google Cloud Functions(and even more!) gVisor has a "guest kernel" layer which means a containerised applications cannot directly touch to the host kernel layer. Even if they think they do, they only touch the gVisor's guest kernel. Notable differences from runC is as follows. • Performance is worse • Linux kernel layer is not 100% compatible • Not supported by default
  11. Istilah Podman Podman adalah mesin kontainer tanpa daemon untuk mengembangkan,

    mengelola, dan menjalankan Kontainer OCI di Sistem GNU/Linux. Kontainer dapat dijalankan sebagai root atau dalam mode tanpa root. Sederhananya: `alias docker = podman`. Dan jalankan opsi perintah seperti menjalankan docker.
  12. Podman Suffice it to say that there were several reasons

    why Docker users were concerned about this approach as usage went up. To list a few: • A single process could be a single point of failure. • This process owned all the child processes (the running containers). • If a failure occurred, then there were orphaned processes. • Building containers led to security vulnerabilities. • All Docker operations had to be conducted by a user (or users) with the same full root authority.
  13. Podman - run interface - can using containerd or cri-o

    - using OCI(open container initiative) images - run on rootless from https://opensource.com/article/19/2/how-does-rootless-podman-work - need config for container network and volumes - podman-compose - Yaml generator
  14. Podman and container images When you first type podman images,

    you might be surprised that you don’t see any of the Docker images you’ve already pulled down. This is because Podman’s local repository is in /var/lib/containers instead of /var/lib/docker. This isn’t an arbitrary change; this new storage structure is based on the Open Containers Initiative (OCI) standards.
  15. podman run -dt -p 8000:80 --name demo quay.io/libpod/alpine_nginx:latest podman ps

    podman generate kube demo > demo.yml cat demo.yml Podman dan Kubernetes # Script
  16. Buildah Buildah (named for fun because of Dan Walsh’s Boston

    accent when pronouncing “builder”) fit this bill. - builder container images However, if we want to use the same Kubernetes cluster to do builds, as in the case of OpenShift clusters, then we needed a new tool to perform builds that would not require the Docker daemon and subsequently require that Docker be installed. Such a tool, based on the containers/storage and containers/image projects, would also eliminate the security risk of the open Docker daemon socket during builds, which concerned many users.
  17. Buildah Notes There are a couple of extra things practitioners

    need to understand about Buildah: 1. It allows for finer control of creating image layers. This is a feature that many container users have been asking for for a long time. Committing many changes to a single layer is desirable. 2. Buildah’s run command is not the same as Podman’s run command. Because Buildah is for building images, the run command is essentially the same as the Dockerfile RUN command. In fact, I remember the week this was made explicit. I was foolishly complaining that some port or mount that I was trying wasn’t working as I expected it to. Dan (@rhatdan ) weighed in and said that Buildah should not be supporting running containers in that way. No port mapping. No volume mounting. Those flags were removed. Instead buildah run is for running specific commands in order to help build a container image, for example, buildah run dnf -y install nginx. 3. Buildah can build images from scratch, that is, images with nothing in them at all. Nothing. In fact, looking at the container storage created as a result of a buildah from scratch command yields an empty directory. This is useful for creating very lightweight images that contain only the packages needed in order to run your application.
  18. sudo zypper in podman sudo bash -c 'echo 10000 >

    \ /proc/sys/user/max_user_namespaces' sudo bash -c "echo $(whoami):100000:65536 > /etc/subuid" sudo bash -c "echo $(whoami):100000:65536 > /etc/subgid" echo "alias docker='podman'" >> .bashrc source .bashrc docker pull nginx:stable Instalasi dan Limitasi # Install and Config Script
  19. <!DOCTYPE html> <html> <head> <title>Echo World</title> </head> <body> <center><pre>it work

    v2!</pre></center> </body> </html> Praktik Build # index.html # Dockerfile FROM nginx:stable COPY ./index.html /usr/share/nginx/html/index.html Bahan
  20. docker login docker.io docker images docker build --format=docker -t \

    docker.io/tuanpembual/hello . docker run --rm --name hello -p 8080:80 \ docker.io/tuanpembual/hello docker push docker.io/tuanpembual/hello docker rmi docker.io/tuanpembual/hello Praktikum # Bash Script
  21. Tantangan? gitlab-runner with podman and buildah as executor open issue:

    - https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27119 - https://gitlab.com/ozapp-public/buildah-podman-ci-example/-/tre e/master
  22. Conclusion Podman and Buildah solved the Kubernetes runtime issue with

    CRI-O and runC. It allows operators to examine containers and images with commands they are familiar with using. And it also provides developers with the same tools. So Docker users, developers, or operators, can move to Podman, do all the fun tasks that they are familiar with from using Docker, and do much more.
  23. Bahan Bacaan - https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-d o-i-do-e4m - https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/ - https://kubernetes.io/blog/2020/12/02/dockershim-faq/ -

    https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-do cker-users/ - https://developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml/