Giới thiệu về Kubernetes

Sự ra đời của Microservices

Trước đây khi app được build theo dạng Monolithic services, tức là 1 ứng dụng lớn handles tất cả mọi thứ từ xử lý các request của người dùng đến kết nối đến database. Tuy nhiên, những app được build theo cách truyền thống này rất khó để có thể hiểu được logic hoạt động và sau một khoảng thời gian, khi có các công nghệ mới xuất hiện, việc update nó là một thử thách khi tất cả các phần dính chặt vào nhau, một khi có thay đổi ở phần nào cũng ảnh hưởng cả hệ thống.

Cùng với sự phát triển của Cloud, các ứng dụng dần chuyển sang Microservices, phân chia ứng dụng lớn trước đây thành những ứng dụng siêu nhỏ, mỗi ứng dụng sẽ cung cấp 1 chức năng riêng lẻ và khi join chúng lại thì sẽ được 1 ứng dụng đầy đủ chức năng.

Tuy nhiên, để xây một ứng dụng có tất cả các chức năng thì cần hàng chục đến hàng trăm ứng dụng siêu nhỏ cùng hoạt động nên đem lại các vấn đề như:

1. Phân chia port: Mỗi ứng dụng cần chạy trên 1 port khiến việc ghi nhớ và phân chia các port trở nên khó khăn.
2. Dependencies: Để có thể chạy được, mỗi ứng dụng cần có các gói package, model riêng với các version khác nhau điều này rất khó đáp ứng được trên physical.
3. Gọi lẫn nhau: Các ứng dụng đôi khi cần phải gọi đến ứng dụng khác để lấy data hoặc sử dụng một chức năng nào đó, điều này yêu cầu các ứng dụng phải hoạt động cùng lúc với nhau ở một mức độ nào đó.

Điều này ở mô hình triển khai trên physical tốn rất nhiều resource, chi phí để vận hành và công sức quản trị, còn trên VM thì lại quá nặng vì mỗi khi tạo một môi trường mới thì các resource như CPU, RAM, ROM lại bị nhân đôi. Và Docker hay bao quát hơn là container là phương pháp thay thế tốt nhất, nó sẽ giúp các ứng dụng này có môi trường riêng biệt lại không phải tốn nhiều resource và cũng như dễ dàng chia sẻ người khác.

Quản trị Container

Khi container dần được ứng dụng trong doanh nghiệp đồng nghĩa với cần phải quan tâm đến việc quản lý resource cũng như scheduling chúng. Làm cách nào để đảm bảo tất cả các container có thể chạy cùng nhau, được giám sát và thay thế khi cần thiết.

 💡  Nhiều công nghệ đổ bộ vào thị trường: Mesos giới thiệu Marathon; Docker tạo ra Swarm; Hashicorp phát hành Nomad; và Google đã tạo ra một mã nguồn mở cho nền tảng Borg nội bộ của mình và đặt tên cho công nghệ này là Kubernetes (từ tiếng Hy Lạp có nghĩa là thuyền trưởng của một con tàu).

Kubernetes nổi bật hơn các công cụ quản lý container còn lại với 2 concepts: declarative infrastructure và the reconciliation loop.

Procedurally

Trước khi có các công cụ quản lý, “thủ tục” tạo ra một container thường diễn ra như sau:

“Tôi sẽ tạo ra một container rồi mở port cho container đó listen. Sau đó, gắn một số file lên container. Chờ đến khi mọi thứ khởi động xong thì kiểm tra lại container có hoạt động hay không, nếu như mọi việc trơn tru thì hoàn thành công việc”.

Declarative

Với Kubernetes, tất cả mọi việc người dùng cần làm là “khai báo”.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Người dùng chỉ cần khai báo như trên thì Kubernetes sẽ đọc và thực hiện các công việc còn lại

Các dòng sát bên trái có thể được xem là một khai báo, các khai báo được thực hiện theo thứ tự từ trên xuống dưới

• apiVersion: khai báo loại api sẽ sử dụng
• kind: khai báo loại resource sử dụng
• metadata:
  • Khai báo metadata có tên nginx-deployment
  • Khai báo nhãn nginx
• spec:
  • Tạo 3 pod giống nhau
  • Lựa chọn nhãn nginx để gắn lên các pod vừa tạo
  • Chạy image có tên nginx:1.14.2 listen port 80 trên pod có tên nginx, đăt tên container vừa được tạo là nginx

Reconciliation loop

Để hiểu được cách khai báo như trên, Kubernetes thực hiện “vòng lặp đối chiếu”, nó đối chiếu giữa trạng thái hiện tại (current state) của mình với trạng thái mong muốn (desired state) của người dùng

• “Ngươi dùng cần một metadata có tên nginx-deployment, đã có chưa? Nếu có bỏ qua, nếu chưa thì tạo”.
• “Người dùng cần nhãn nginx, đã có chưa? Nếu có bỏ qua, nếu chưa thì tạo?”
• “Người dùng cần 3 pod nginx chạy image nginx1.14.2 listen trên pod 80, đã có chưa? Nếu chưa thì tạo, nếu có bỏ qua”
• …

😯 Fun fact

Tại sao Kubernetes còn được gọi là K8S?

Do trong quá trình làm việc, người dùng muốn giao tiếp với nhau một cách ngắn gọn hơn, họ mới nghĩ ra các thay thế các chữ cái “ubernete” với số 8 tượng trưng cho những ký tự được rút gọn, cách gọi này dần trở nên phổ biến và trở thành tên gọi thứ 2 của Kubernetes.