Forem: Kohei Ota

Wait, Docker is deprecated in Kubernetes now? What do I do?

Kohei Ota — Wed, 02 Dec 2020 20:11:39 +0000

tl;dr

For developers

Don't panic, Docker containers and images are still alive. It's not that it will change everything.

Also worth reading:

https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

https://kubernetes.io/blog/2020/12/02/dockershim-faq/

For K8s admins

Read this carefully and start considering Docker alternatives

Is it true?

Yes, it is true. Docker is now deprecated in Kubernetes.

Ref. https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.

In short, what it means here is that Docker does not support Kubernetes Runtime API called CRI(Container Runtime Interface) and 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.

Docker in local is a very powerful tool to create dev environment for sure, but in order to understand what's causing this, you need to understand what Docker does in the current Kubernetes architecture.

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.

Look at the architecture diagram. You can see that 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.

But why is Docker deprecated?

Again, Kubernetes only talks in CRI and talking to Docker requires a bridge service. So that's reason 1.

To explain the next reason, we have to see the Docker architecture a bit. Here's the diagram.

So yeah, Kubernetes actually needs inside of the red area. Docker Network and Volume are not used in Kubernetes.

Having more features while you never use, itself can be a security risk. The less features you have, the smaller the attack surface becomes.

So this is where you start considering alternatives. It's called CRI runtimes.

CRI runtimes

There are two major CRI runtime implementations.

containerd

If you just want to migrate from Docker, this is the best option as containerd is actually used inside of Docker to do all the "runtime" jobs as you can see in the diagram above. 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

CRI-O is a CRI runtime mainly developed by Red Hat folks. In fact, this runtime is 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 in my opinion is its minimalism because it was created to be a "CRI" runtime. While containerd started as a part of Docker trying to be more open source, 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.

One more thing...

When we talk about Container Runtimes, we need to be careful which type of runtime you're talking about. We do have two types of runtimes; CRI runtimes and OCI runtimes.

CRI runtimes

As I described, CRI is an API that Kubernetes provides to talk to a container runtime in order to create/delete containerised applications.

They talk in gRPC via IPC as kubelet and the runtime runs on the same host, and a CRI runtime has responsibility for getting request from kubelet and execute OCI container runtime to run a container. Wait, what? Maybe I should explain with a diagram for this one.

So what a CRI runtime does is the following

Get the gRPC request from kubelet
Create OCI json config following the spec

OCI runtimes

OCI runtimes are responsible for spawning a container using Linux kernel system calls such as cgroups and namespace. You might have heard about runc or gVisor. This is what they are.

appendix1: how runC works

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.

appendix2: how gVisor works

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!)

What's interesting here is that 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.

gVisor's security model is actually very interesting and worth reading the official doc.

Notable differences from runC is as follows.

Performance is worse
Linux kernel layer is not 100% compatible
- Look at the compatibility section on official doc
Not supported by default

Conclusion

1. Docker is surely deprecated but only in Kubernetes, so if you're a K8s admin, you should start thinking to adopt a CRI runtime such as containerd and CRI-O.

a. containerd is Docker compatible where the core components are the same.
b. CRI-O can be a strong option where you want more minimal functionality for Kubernetes

2. Know what the difference of CRI and OCI runtime responsibility and scope

Depending on your workload, runC might not be always the best option to use!

Kubernetes is not just about Tech. It has a huge community!

Kohei Ota — Sun, 01 Dec 2019 00:13:35 +0000

Intro

When talking about Kubernetes, the philosophy inherited from Google and the advantages of container technology are of course indispensable.

But Kubernetes has evolved so far not only in technology but also because of the large ecosystem and the presence of the community.

This time, I will introduce the various things that support Kubernetes.

Kubernetes and SIGs

Kubernetes has several community types, all of which belong to the kubernetes/community repository.

SIG (Super Interest Group)
UG (User Group)
WG (Working Group)

As you can see, SIG has many groups :D

If you would like to see the full list, see here.

On the list, you can see there are lots of chairs(persons who lead each group) and they are from different organizations for vendor neutrality.

Why different organizations

Kubernetes was originally rewritten in Golang based on the idea of a distributed application platform called Borg that was originally developed by Google. Therefore, it started as an OSS led by Google.

Starting with the release of Kubernetes 1.0, the organization “CNCF (Cloud Native Computing Foundation)” launched by Google and the Linux Foundation has been managed by Kubernetes and has restarted as an open community independent of vendors. For more details, see This TechCrunch article.

Since then, various efforts have been made to ensure that all users contribute equally and participate in the community.

Kubernetes itself is a product with a clear idea, and it aims to make itself independent of any vendor.

However, in real-world, you would probably want something like these

AWS integration
Ease with on-prem bare metal
L7 load balancers management on Kubernetes

The context of using Kubernetes changes in various usage scenes.
e.g.) Running Kubernetes as a batch platform, Using GPUs, or Running various web applications.

Kubernetes is very scalable for these demands.

Custom controller
Custom scheduler
Custom metrics

These can be combined to suit your needs.

People submit various discussions, suggestions, and efforts every day in these communities to make Kubernetes a better place in the world.
Conversely, if you want to get involved with Kubernetes, the first thing you should get started with is the Kubernetes community.

What the flip are QUIC and HTTP/3?

Kohei Ota — Tue, 13 Nov 2018 08:06:17 +0000

TL;DR

IETF(Internet Engineering Task Force) has agreed to rename HTTP-over-QUIC to HTTP/3. What the flip are they anyway?

Describe QUIC and HTTP/3 in one sentence each.

Note: QUIC != HTTP/3, iQUIC + HTTP/2 API == HTTP/3

QUIC is a new transport protocol originally proposed by a Google developer to resolve many of problems which the current HTTP/1.1 and HTTP/2 have.

HTTP/3, previously called HTTP-over-QUIC, is a protocol stack integrated with QUIC and HTTP/2.

Before you learn them

OK, as you've read the describes already, before you get to know about them, you would need to know how current HTTP works.

HTTP(HyperText Transport Protocol) is an application layer protocol to deliver HyperText Documents such as HTML and XML. Nowadays it's used pretty much everywhere on the Internet for many different purposes and it's now so-called "World Wide Web".

Why did they need changes?

HTTP was originally made by a CERN scientist called Tim Berners-Lee but the very original protocol was very simple and just has GET method. It was so simple that it has only one single page documentation.

Now we use HTTP/1.1 for the most traffics but it has the following problems

HTTP is a pretty-much-30-years-old protocol
Security layer is not included in the protocol
- Any traffic could be watched by someone unless server maintainer enables TLS
- Ref: https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html
- Even TLS 1.2 has some problems(Don't use older than TLS 1.1 without a valid reason :P)
HoL Blocking can be a huge problem when you have huge traffic
- Both HTTP/1.1 and TCP have this problem from different aspect
- HTTP/2 addressed the problem from HTTP wise
- As long as HTTP relies on TCP, HoL Blocking based on TCP cannot be resolved even if you enable HTTP/2
- One packet lost makes all stream wait until the package is received

How does HTTP/3 resolve these problems?

QUIC works on UDP protocol(!)
QUIC layer gives...
- Encryption integrated with TLS 1.3 with 0-RTT handshake
- Ref: https://speakerdeck.com/kazuho/security-privacy-performance-of-next-generation-transport-protocols
- Congestion control without "good old" TCP
- High accessibility under mobile network w/ Connection UUID(Switching Wi-Fi <-> LTE won’t make renegotiation)

Protocol Overview

Image credit

Translation note

認証・鍵交換: Certification/Key exchange
優先度制御: Priority control
多重化: Multiplexing
暗号化: Encryption
トランスポート: Transport

Hope it helps you understand what they are :)

Do you really need Docker or Kubernetes in your system?

Kohei Ota — Thu, 04 Oct 2018 04:52:51 +0000

Abstract

From several years ago, Docker has given us the very strong ecosystem that makes your code work on pretty much everywhere with the essential components in one minimized unit just like a physical "container".

As for Kubernetes, it gave a very congregative platform not just for the operating environment integrated with the containerized system based on what Docker created, but also with logging, monitoring and so on.

Moreover, the concept of DevOps and SRE have become very important to understand how to operate your system in the modern Internet world to reflect your business demand and updates continuously.

But here's a question. Do you really need Docker and its ecosystem, or Kubernetes in your system environment?

Yes, I am asking you, not anybody else. When you decide what technology to use in your system, you have to understand why it matters and how.

Here are some thoughts of mine for what you should do with containers and what you shouldn't. Please give me your opinions in the comment section if you have :)

1. Docker itself is not "production ready".

First of all, Docker is a great platform in many ways. But it triggers a lot of pains especially with Networking, Monitoring and Logging.
It is simply because Docker was created in order to deal with the App execution environment as mentioned above as dotCloud was a PaaS like Heroku.

It is very easy to handle a single container as one service but you don't really use it as a whole platform. You will need a Web server(or more than that), a Database server, an Application server, and maybe Memcached/RabbitMQ etc...

Combining those with Docker itself is not that hard, but you can't do clustering, self-healing, replicating because they are not natively provided Docker which is required on system platform in most cases.

2. Kubernetes is too much for just a web application

So, I mentioned that Docker is too less for a production platform in the previous section. Kubernetes and Docker Swarm solves a lot of those problems.
They both have, in common, clustering, scaling and networking. Kubernetes has more features and it looks good. Yes it does. But it's actually too much for just a single web application. The more you use Kubernetes features, the more complicated it becomes. I have seen lots of people saying this "I just wanted to orchestrate container system smartly. But now I am maintaining the Kubernetes clusters, master node, and etcd everyday." It's a well architected for complicated systems and to keep it available. But do you really need the complexity? I'd say no.(though it really depends!)

There are lots of products that's on the Kubernetes such as Rancher/OpenShift but none of them would decrease the operation costs for the "features" of Kubernetes to me.(No offence. They are very good tools as well!)

3. Docker Swarm is good but...

OK, tell me I'm wrong. I haven't used Swarm much, honestly.

Anyway, meanwhile Kubernetes is too much, Docker Swarm is lighter and it looks the best to deal with smaller applications. The performance is actually much faster than Kubernetes as well!

The thing that made me stop to think is that I want to use container orchestration tools for less operations in the beginning. While Kubernetes is supported by lots of cloud benders, Docker Swarm is not. Technically they have tried but not anymore.
It is not very convenient because I, personally, don't really want to use EC2 or any physical machine to manage clusters and stuff. Only if I could make clusters Swarm easily on AWS.... that'd be legendary!
Oh and as another thing for me, I'm Japanese and lots of people want Japanese language support for Enterprise solution and Swarm doesn't have it as long as I know.

Summary

The TL;DR is super boring. Know what you are using. New things are cool but it's not perfect and you always have to try comparing what's good and what's not for you :)

How I learnt English by myself being Japanese

Kohei Ota — Tue, 27 Mar 2018 06:33:07 +0000

About this post

I believe there are some people who want to learn another language and it can be so varied. English, Spanish, French, Korean, Chinese... Yes, there are too many to count.

Today I want to share how I learnt English from the level I could not even say this simple sentence "I am 19 years old." to the level that I can contribute an OSS community as an interpreter, though not simultaneously.

I said Japanese just 'cause Japanese and English are very different and what I basically want to say by this is it's not too late to try if you could not deal with a language very well when you were young.

Who are you?

I am not a great person. Just a native Japanese speaker who likes eating and tinkering with computers.

You must have been to a good college/university

I did not even go to a university. I went to a science college thing which is like a technical high school and college combined. It's a special type of school even in my country so I don't really know how to describe this but I was just a slacker as I dropped out anyway :)

So how did you do this?

I don't actually think methods really matter. But you need some of these mindsets.

Have a short-term goals and long-term goals.

You need an object when you try to aim at something. Making an effort for nothing particularly is not very efficient and you should have something realistically possible.
Think of yourself what you want to do in the future with using the target language and if you want to do it, you need to keep trying.

Short-term goals are very important to make yourself keep trying. Long-term goals can be really boring sometimes simply because it takes so much time. Setting short-term goals that can be archived possible makes you feel better whenever you make the achievement and can be a good sign to show you are actually improving. Short-term goals are something like "memorizing 100 words", "passing some level of an exam" and "being able to say some silly jokes in the language".

Long-term goals are very important to make yourself not get easily "satisfied" with yourself. If you want to be really good at something you should just keep making an effort no matter how you're told you're good. Surprise yourself in the next few years with the effort you will have made :)

Know the difference between holding conversations and reading/writing technical/business sentences

Honestly I am the best at speaking in English and my writing is frigging bad. I could use to express how bad I am at writing but not for now ;P I can write stupid things on IRC, enjoy sitcom without subtitles, say lame jokes to my Aussie girlfriend and even have a serious/huge argument with her.
Even so, I cannot write completely "natural" English like a native speaker because I am lacking of vocabulary and practice. You need to practice literally every day to be really good at language. No matter what. It is really hard to be a complete bilingual without knowing those languages from childhood.

I know a lot of Japanese people who can comprehend English articles. But mostly they translate into Japanese in their brain and break it down slowly to understand. They can write enough good English to tell what they want to say in E-mails too but can't talk a lot including daily conversation because they have not practiced a lot.

In my opinion, all of the language skills; reading, writing, listening, speaking, are separated but strongly related at the same time. If you want to be good in general, you have to practice all of them evenly.

Do not mind your mistakes too much, but care a bit.

A lot of people say "I'm afraid of making mistakes." but it will hold you back when you want to improve. Fake confidence can be a really strong weapon sometimes because you can pretend you are so sure about what you're saying.
Think of a man who's making a speech, without confident, his voice would be so low and with his mumbling you can't hear it.

But don't rely on the "fake" confidence too much. It does not mean you don't have to make an effort. You have to know you need to keep trying while you don't look like so.

Enjoy what you are doing

Language is just a tool. You use it to express yourself, enjoy contents from other culture, understand the culture and share ideas to/from the world. It is not just your goal and more, what really matters is what you want to do with the tool.

This is what I have been doing to learn English for these seven years. I didn't have anyone correct this so this is purely my "English". I'm sorry if I wrote something wrong. But I hope everyone will understand this and learn something from this post.

Thank you for reading.

Kohei Ota