Lập Trình

Kubernetes sẽ không còn hỗ trợ Docker?

6446

Theo thông báo mới nhất từ Kubernetes thì nền tảng này sẽ loại bỏ Docker làm container runtime sau phiên bản 1.20. Tuy nhiên đừng hoảng hốt bởi vì sự việc chưa đến mức tệ đến thế.

Xem thêm Kubernetes là gì?

Tóm tắt: Docker, với chức năng runtime cơ bản sẽ không được sử dụng Container Runtime Interface (CRI) đuợc tạo cho Kubernetes. Tuy vậy, Docker image vẫn hoạt động trong cluster với mọi runtime như từ trước đến giờ.

20 trường hợp sử dụng lệnh Docker cho developer

Docker là gì? Kiến thức cơ bản về Docker

Đối với end-user của Kubernetes thì sẽ không thay đổi nhiều lắm. Thông tin này không đồng nghĩa sẽ khai tử Docker và cũng không có nghĩa bạn không thể, hay không nên dùng Docker làm development tool nữa. Docker vẫn sẽ là tool hữu ích để build container và các image từ việc chạy docker build vẫn có thể chạy trong Kubernetes cluster.

Nếu bạn đang sử dụng các service quản lý bởi Kubernetes như GKE, EKS, hay AKS (ser mặc định là container) thì bạn cần xác định là các node đang sử dụng container runtime được hỗ trợ trước khi Docker bị loại bỏ trong các phiên bản tương lai của Kubernetes. Nếu bạn có node customize thì có thể phải cập nhật dựa trên yêu cầu môi trường và runtime. Vì vậy hãy work với service provider để update việc testing và planning phù hợp.

Tham khảo việc làm hot nhất do global cybersoft tuyển dụng

Nếu bạn dùng cluster riêng thì bạn cần thay đổi để tránh cluster bị sập. Với phiên bản 1.20, sẽ có cảnh báo loại bỏ Docker. Khi Docker runtime support bị xóa trong các bản release tiếp theo của Kubernetes, nó sẽ không được support và lúc đó bạn cần đổi sang các container runtime khác, như containerd hay CRI-O. Hãy đảm bảo chọn runtime sẽ support cấu hình docker daemon bạn đang dùng (ví dụ như logging).

Tại sao đây là tin chấn động?

Chúng ta đang đề cập đến hai môi trường hoàn toàn khác nhau, dẫn đến dễ bị nhầm lẫn. Bên trong Kubernetes cluster, container runtime chịu trách nhiệm đẩy và chạy container image. Thì Docker là lựa chọn phổ biến cho runtime đó (lựa chọn khác là containerd và CRI-O) nhưng Docker không được thiết kế để tương thích với Kubernetes, đây là khi vấn đề nảy sinh.

Cái ta gọi là “Docker” không chỉ làm một việc – nó là toàn bộ tech stack, một phần của nó được gọi là “containerd” bản thân đã là container runtime high-level rồi. Docker rất cool ngầu và hữu dụng bởi vì nó có nhiều cải tiến UX giúp người dùng dễ dàng tương tác khi làm các công việc development nhưng những cải tiến này thật sự không cần thiết đối với Kubernetes, vì đơn giản Kubernetes không phải là “human”.

Kết quả của việc tạo ra lớp thân thiện với người dùng này là Kubernetes cluster phải dùng công cụ khác gọi là Dockershim để tích hợp – containerd. Điều này khá là phiền bởi vì chúng ta có thêm một cái để maintain và tăng khả năng mất kết nối. Thật ra thì Dockershim đã bị loại bỏ khỏi Kubelet từ phiên bản v1.23 cũng như bỏ hỗ trợ cho Docker như là container runtime luôn. Tới đây nhiều người thắc mắc, nếu containerd có bên trong Docker stack thì Kubenetes cần Dockershim làm gì nữa?

Docker không tuân theo CRI. Nếu có thì ta không cần shim chi nữa, nhưng đây không phải là vấn đề. Bạn chỉ cần đổi container runtime từ Docker sang một koại khác được hỗ trợ mà thôi.

Một điểm cần lưu ý là nếu đang dựa trên docker socket cơ bản (/var/run/docker.sock) trong workflow của cluster thì việc chuyển runtime khác có khả năng không dùng được nữa. Pattern này thường được gọi là Docker in Docker. Có nhiều lựa chọn cho trường hợp này như là kaniko, img và buildah.

Điều này có nghĩa là gì? Có cần phải viết Dockerfiles và build các thứ với Docker nữa không?

Thay đổi một môi trường khác sẽ tốt hơn cố gắng tương thích với Docker. Môi trường Docker bạn đang dùng để develop sẽ không liên quan đến Docker runtime bên trong Kubernetes cluster. Mình biết nó khá rắc rối. Đối với lập trình viên thì Docker vẫn hữu ích về mọi mặt trước khi có sự thay đổi lớn này. Container Image mà Docker tạo ra không theo Docker-specific image, mà nó theo chuẩn OCI (Open Conatiner Initiative). Bất kỳ Container Image tương thích với chuẩn OCI, dù tool bạn dùng là gì, đều tương thích với Kubernetes. Cả containerd và CRI-O đều xử lý và chạy Container image như nhau, đó là lý do vì sao có chuẩn dành riêng cho containers của chúng ta.

Tóm lại, sẽ có nhiều thay đổi diễn ra và phát sinh một vài vấn đề, nhưng chung quy đây không hẳn là hung tin hay biến động lớn gì cả. Tùy vào cách mà bạn tương tác với Kubernetes mà việc này ảnh hưởng nhiều hay ít. Xét về mặt lâu dài thì lợi nhiều hơn hại. Tất nhiên sẽ có rất nhiều câu hỏi được đặt ra vì không ai là chuyên gia 100% về lĩnh vực này cả. Hãy chờ xem những update tiếp theo ở các bản release từ Kubernetes nhé.

TopDev via Kubernetes.io