# A. Giới thiệu các khái niệm chung về Kubernetes ## 1. Kubernetes là gì? `Kubernetes` là một hệ thống mã nguồn mở giúp quản lý các container. `Kubernetes` giúp bạn tự động hóa việc triển khai, mở rộng và quản lý các ứng dụng chứa trong các container. Nó là hệ thống quản lý container phổ biến nhất hiện nay và nó là một đám mây trung tính (cloud-neutral) với khả năng chạy trên nhiều hệ thống đám mây công cộng, riêng tư hoặc hệ thống vật lý. `Kubernetes` cung cấp cho người dùng với 1 `framework` để chạy các hệ thống phân tán một cách ổn định. Nó quan tâm tới việc mở rộng, khả năng chịu lỗi cho ứng dụng và cung cấp các mẫu triển khai ứng dụng. Nó cung cấp với các tính năng như: - `Service discovery and load balancing`: `Kubernetes` có thể khám phá các dịch vụ và phân phối các yêu cầu đến các dịch vụ đó. **`Có thể thay thế Eureka Server trong Spring Cloud`**. - `Container & storage orchestration`: `Kubernetes` cho phép bạn tự động chuyển các container đến các máy chủ mới khi cần thiết. - `Automated rollouts and rollbacks`: `Kubernetes` cho phép bạn thực hiện triển khai mới mà không cần gián đoạn dịch vụ cũng như quay lại phiên bản cũ nếu cần. - `Self-healing`: `Kubernetes` có khả năng tự động khôi phục các container khi chúng bị lỗi. - `Secret and configuration management`: `Kubernetes` cho phép bạn quản lý và lưu trữ các thông tin nhạy cảm như `password`, `OAuth tokens` và `SSH keys`. ## 2. Kiến trúc của Kubernetes `Kubernetes` có kiến trúc `master-slave` với các thành phần chính như sau: 1. `Control Panel/Master Node`: Chịu trách nhiệm quản lý toàn bộ `cluster`. Nó giám sát việc kiểm tra tình trạng của tất cả các `node` trong `cluster`, lưu trữ thông tin của các thành viên liên quan đến các `node` khác nhau, lập kế hoạch cho các `container` được lên lịch cho các `Worker Node` nhất định, giám sát các `container` và `node`, v.v. Vì vậy, khi một `Worker node` bị lỗi, `Master node` sẽ di chuyển khối lượng công việc từ `node` bị lỗi đến `Worker Node` khỏe mạnh khác. - `API Server`: Là giao diện chính để tương tác với `K8s cluster`. Nó show ra các API của `k8s`, cho phép người dùng và các thành phần khác giao tiếp với các `cluster`. Tất cả lệnh điều khiển, hoạt động của quản trị viên được gửi tới `API Server` và nó sẽ thực thi và xác thực các yêu cầu đó. - `Scheduler`: Có trách nhiệm đặt các `Pod` vào các `node` có sẵn trong `cluster`. Nó sẽ tính đến các yếu tố như `yêu cầu tài nguyên`, `mối quan hệ`, `chống đối quan hệ`, và các ràng buộc khác để đưa ra quyết định thông min xem `node` nào sẽ chứa `Pod`. `Scheduler` liên tục theo dõi các `cluster` đảm bảo các `Pod` được phân phối 1 cách tối ưu. - `Controller Manager`: Trình quản lý việc duy trì các `cluster`. Nó xử lý các lỗi `node`, nhân bản các thành phần, đảm bảo đúng số lượng `Pod` chạy và các `controller` khác. Nó luôn giữ hệ thống ở trạng thái mong muốn bằng cách so sánh trạng thái hiện tại với trạng thái mong muốn. - `etcd`: Là kho lưu trữ `key-value` phân tán, đóng vai trò là kho lưu trữ dữ liệu chính của `cluster`. Nó lưu trữ các `dữ liệu cấu hình` và `trạng thái mong muốn` của hệ thống, bao gồm thông tin về `Pods`, `Services`, `Replication Controllers`, `Endpoints` và `Nodes`. `API Server` tương tác với `etcd` để đọc và ghi dữ liệu `cluster`. 2. `Worker Node`: Không gì khác ngoài một `máy ảo` (VM) chạy trên đám mây hoặc tại chỗ. Vì vậy, bất kỳ phần cứng nào có khả năng chạy thời gian chạy container đều có thể trở thành `Worker Node`. Các `node` này hiển thị khả năng tính toán, lưu trữ và kết nối mạng cơ bản cho các ứng dụng. Các `Worker Node` thực hiện công việc nặng nhọc cho ứng dụng chạy bên trong `Kubernetes Cluster`. Đồng thời, các `node` này tạo thành một `cluster` - việc phân công khối lượng công việc được thực hiện bởi thành phần `Master Node`, tương tự như cách người quản lý giao nhiệm vụ cho một thành viên trong nhóm. Bằng cách này, chúng sẽ có thể đạt được khả năng chịu lỗi và nhân rộng. - `Pod` là đơn vị triển khai nhỏ nhất trong Kubernetes cũng như container là đơn vị triển khai nhỏ nhất trong Docker. Để hiểu một cách dễ hiểu, chúng ta có thể nói rằng `pod` không là gì ngoài những `máy ảo nhẹ trong thế giới ảo`. Mỗi nhóm bao gồm một hoặc nhiều container. Mỗi khi một nhóm hoạt động, nó sẽ nhận được một địa chỉ IP mới với dải IP ảo do giải pháp mạng nhóm chỉ định. - `Kubelet`: Là một thành phần chạy trên mỗi `Worker Node` và giao tiếp với các thành phần trong `control plane`. Nó nhận được hướng dẫn từ `control plane`, chẳng hạn như tạo và xóa `Pod` và đảm bảo duy trì trạng thái mong muốn của `Pod` trong `node`. `Kubelet` chịu trách nhiệm cho việc `bắt đầu`, `dừng lại`, `giám sát` các `container` dựa trên thông số kỹ thuật của `Pod`. - `Kube-proxy`: Là một proxy mạng chạy trên mỗi `Worker Node` trong `Cluster`, triển khai một phần nội dung của `Kubernetes Service`. `Kube-proxy` duy các `quy tắc` mạng trên các `node`. Các `quy tắc` này cho phép giao tiếp mạng tới `Pod` từ các phiên mạng bên trong hoặc bên ngoài `Cluster`. - `Container Runtime`: Chịu trách nhiệm `chạy` và `quản lý` các `container` trên `Worker Node`. Kubernetes hỗ trợ nhiều `container runtime`, trong đó Docker được sử dụng phổ biến nhất. Các `runtime` khác như `containerd` và `rkt` cũng được hỗ trợ. `Container Runtime` lấy `container image`, tạo và quản lý các phiên bản `container` cũng như xử lý các hoạt động trong vòng đời của `container`. # B. Cài đặt `Kubernetes` trên `Docker Desktop` (Xây dụng Kubernetes cục bộ) ## 1. Settings trong `Docker Desktop` Để deploy `Kubernetes` trên `Docker Desktop`, xem hướng dẫn tại đây [Deploy on Kubernetes with Docker Desktop](https://docs.docker.com/desktop/kubernetes/) ## 2. Cài đặt `Helm` `Helm` là một công cụ quản lý gói cho `Kubernetes`. Nó cho phép bạn định nghĩa, cài đặt và quản lý các ứng dụng `Kubernetes`. Để cài đặt `Helm`, xem hướng dẫn tại đây [Installing Helm](https://helm.sh/docs/intro/install/) Sau khi cài xong, kiểm tra phiên bản `Helm` bằng câu lệnh: ```bash helm version ``` ## 3. Cài `Kubernetes UI` (Dashboard) trên máy cục bộ ### 3.1. Để cài `Kubernetes UI` trên máy cục bộ, trước hết cần phải có `Kubernetes` và cần cài `Helm` trước. Sau đó, tham khảo hướng dẫn tại đây [Kubernetes Dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) Câu lệnh cài đặt `Kubernetes UI`: ```bash # Add thư viện Kubernetes Dashboard helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/ # Cài đặt Kubernetes Dashboard với namespace kubernetes-dashboard helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard ``` ### 3.2. Sau khi cài đặt xong, sử dụng câu lệnh sau để kiểm tra xem `kubernetes-dashboard-kong-proxy` đã được cài đặt thành công chưa: ```bash # Lấy ra các service trong namespace kubernetes-dashboard kubectl -n kubernetes-dashboard get svc ``` ### 3.3. Để khởi động `Kubernetes UI`, sử dụng câu lệnh sau: ```bash # Khởi động Kubernetes UI kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443 ``` > Sau khi khởi động thành công, truy cập vào `https://localhost:8443` để xem `Kubernetes UI`. Lưu ý, cần phải giữ phiên làm việc của Terminal để chạy `Kubernetes UI`. ### 3.4. Để đăng nhập vào `Kubernetes UI`, cần phải lấy ra `token` để đăng nhập. Trước hết cần phải tạo một `Service Account` và `Cluster Role Binding` cho `Service Account` đó. Tham khảo các bước tại [Creating sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 1. Tạo một `Service Account` với tên `admin-user` trong namespace đã tạo là `kubernetes-dashboard`, cấu hình trong file `dashboard-adminuser.yaml`: >`dashboard-adminuser.yaml` ```yaml apiVersion: v1 # Version của API dùng để tạo Service Account kind: ServiceAccount # Loại tài khoản metadata: # Thông tin về Service Account name: admin-user # Tên Service Account (giống như username) namespace: kubernetes-dashboard # Namespace của Service Account (giống như group) ``` Sau đó, sử dụng câu lệnh sau để tạo `Service Account`: ```bash kubectl apply -f dashboard-adminuser.yaml ``` 2. Tạo `Cluster Role Binding` để cấp quyền cho `Service Account` vừa tạo, cấu hình trong file `dashboard-adminuser-rolebinding.yaml`: >`dashboard-adminuser-rolebinding.yaml` ```yaml apiVersion: rbac.authorization.k8s.io/v1 # Version của API dùng để tạo Cluster Role Binding kind: ClusterRoleBinding # Loại quyền metadata: # Thông tin về Cluster Role Binding name: admin-user # Tên Cluster Role Binding roleRef: # Thông tin về Role apiGroup: rbac.authorization.k8s.io # Group của Role kind: ClusterRole # Loại Role name: cluster-admin # Tên Role, bất kỳ người dùng nào được gán Role này sẽ có quyền quản trị toàn bộ Cluster subjects: # Danh sách các đối tượng được cấp quyền - kind: ServiceAccount # Loại đối tượng được cấp quyền name: admin-user # Tên đối tượng namespace: kubernetes-dashboard # Namespace của đối tượng ``` Sau đó, sử dụng câu lệnh sau để tạo `Cluster Role Binding`: ```bash kubectl apply -f dashboard-adminuser-rolebinding.yaml ``` 3. Đây là bước tùy chọn. Nếu muốn tạo ra `token` của user `admin-user` để đăng nhập vào `Kubernetes UI` một cách lâu dài, vĩnh viễn thì cần thêm cấu hình sau vào file `secret.yaml`. Còn không thì mỗi lần đăng nhập sẽ phải tạo `token` mới. >`secret.yaml` ```yaml apiVersion: v1 # Version của API dùng để tạo Secret kind: Secret # Loại Secret metadata: # Thông tin về Secret name: admin-user # Tên Secret namespace: kubernetes-dashboard # Namespace của Secret annotations: # Các chú thích kubernetes.io/service-account.name: admin-user # Tên Service Account type: kubernetes.io/service-account-token # Loại Secret ``` Sau đó, sử dụng câu lệnh sau để tạo `Secret`: ```bash kubectl apply -f secret.yaml ``` > Lưu ý: Nếu không tạo `Secret`, mỗi lần đăng nhập vào `Kubernetes UI` sẽ phải tạo `token` mới. 4. Lấy ra `token` của `Service Account` `admin-user` để đăng nhập vào `Kubernetes UI`: ```bash # Lấy ra token của Service Account admin-user kubectl -n kubernetes-dashboard create token admin-user ``` Trong đó `-n` là `namespace` của `Service Account` và `create token` là câu lệnh để tạo `token` cho `Service Account`. 5. Sau khi lấy ra `token`, truy cập vào `Kubernetes UI` và nhập `token` để đăng nhập. # C. Container Orchestration (Sự điều phối, quản lý các container) sử dụng Kubernetes > LƯU Ý: CẤU HÌNH FILE `YAML` TRONG `DOCKER COMPOSE` KHÁC VỚI CẤU HÌNH FILE `YAML` TRONG `KUBERNETES`. CẦN CHÚ Ý ĐẾN CÁC THUỘC TÍNH KHÁC NHAU GIỮA 2 LOẠI FILE NÀY. > LƯU Ý: TrONG FILe `YAML` TRIỂN KHAI `APP` TRÊN `KUBERNETES` CẦN PHẢI CÓ ÍT NHẤT 2 CẤU HÌNH CHÍNH LÀ `Deployment` (Dùng để triển khai ứng dụng) VÀ `Service` (Dùng để kết nối ứng dụng với mạng bên ngoài). NGOÀI RA CÒN CÓ CẤU HÌNH `ConfigMap` (Dùng để lưu trữ cấu hình, các biến môi trường) VÀ `Secret` (Dùng để lưu trữ thông tin nhạy cảm như `password`, `OAuth tokens`, `SSH keys`). VÀ CÁC CẤU HÌNH NÀY NÊN ĐỊNH NGHĨA TRONG CÙNG **1 FILE YAML** THAY VÌ TẠO RA NHIỀU FILE YAML KHÁC NHAU, VÀ TÁCH BIỆT NHAU BỞI KÝ TỰ `---` GIỮA CÁC CẤU HÌNH, NGẦM CHO `KUBERNETES` HIỂU 2 CẤU HÌNH NÀY THỰC RA LÀ THUỘC 2 FILE `YAML` KHÁC NHAU. ## 1. Cấu hình `ConfigMap` trong `Kubernetes` để lưu trữ các biến môi trường cho `Microservices` `ConfigMap` chỉ khác `Secret` ở chỗ là `ConfigMap` không mã hóa dữ liệu, còn `Secret` thì có. `ConfigMap` được sử dụng để lưu trữ các cấu hình, các biến môi trường cho `Microservices`. Để tạo `ConfigMap`, tạo file `configmap.yml` với nội dung như sau: >configmap.yml ```yaml apiVersion: v1 # apiVersion dùng để tạo ConfigMap kind: ConfigMap # Loại cấu hình (ConfigMap) metadata: # Thông tin về ConfigMap name: bank-configmap # Tên ConfigMap data: # Dữ liệu của ConfigMap SPRING_PROFILES_ACTIVE: prod SPRING_CONFIG_IMPORT: "configserver:http://configserver:8071/" # Thuộc tính spring.config.import trong (application.properties) của ứng dụng EUREKA_CLIENT_SERVICEURL_DEFAULTZONE: "http://eurekaserver:8070/eureka/" # Thuộc tính eureka.client.serviceUrl.defaultZone trong (application.properties) của ứng dụng CONFIGSERVER_APPLICATION_NAME: configserver # Thuộc tính spring.application.name trong (application.properties) của ứng dụng configserver EUREKA_APPLICATION_NAME: eurekaserver # Thuộc tính spring.application.name trong (application.properties) của ứng dụng eurekaserver ACCOUNTS_APPLICATION_NAME: accounts # Thuộc tính spring.application.name trong (application.properties) của ứng dụng accounts LOANS_APPLICATION_NAME: loans # Thuộc tính spring.application.name trong (application.properties) của ứng dụng loans CARDS_APPLICATION_NAME: cards # Thuộc tính spring.application.name trong (application.properties) của ứng dụng cards GATEWAY_APPLICATION_NAME: gatewayserver # Thuộc tính spring.application.name trong (application.properties) của ứng dụng gatewayserver KEYCLOAK_ADMIN: admin # Thuộc tính KEYCLOAK_ADMIN khi chạy docker run KEYCLOAK_ADMIN_PASSWORD: admin # Thuộc tính KEYCLOAK_ADMIN_PASSWORD khi chạy docker run SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK-SET-URI: "http://keycloak:7080/realms/master/protocol/openid-connect/certs" # Thuộc tính spring.security.oauth2.resourceserver.jwt.jwk-set-uri trong (application.properties) của ứng dụng ``` Để sử dụng các biến môi trường trong `ConfigMap`, cần thêm cấu hình sau vào file `.yml`: ```yaml ... template: metadata: ... spec: containers: - name: ... args: ... # DÙNG ĐỂ CHẠY CÁC LỆNH TRONG CONTAINER env: # SỬ DỤNG BIẾN MÔI TRƯỜNG - name: ... # TÊN BIẾN MÔI TRƯỜNG Ở BÊN TRONG APP CONTAINER valueFrom: # LẤY GIÁ TRỊ TỪ configMapKeyRef: # THAM CHIẾU ĐẾN CONFIGMAP name: bank-configmap # TÊN CỦA CONFIGMAP key: SPRING_PROFILES_ACTIVE # TÊN CỦA BIẾN MÔI TRƯỜNG TRONG CONFIGMAP (KEY) ... ``` ## 2. Triênt khai `Keycloak` trên `Kubernetes` Trước tiên cần tạo `image` của `Keycloak` và `push` lên `Docker Hub` hoặc `GitHub Container Registry`. Sau đó, triển khai `Keycloak` trên `Kubernetes` bằng cách sử dụng `Deployment` và `Service`. >keycloak.yml ```yaml apiVersion: apps/v1 # apiVersion dùng để deploy 1 ứng dụng kind: Deployment # Loại cấu hình (Deployment) - dùng để deploy 1 ứng dụng metadata: name: keycloak # Tên Deployment labels: app: keycloak # Gán nhãn cho ứng dụng được deploy (keycloak) spec: selector: matchLabels: app: keycloak # Chọn Pod có nhãn app=keycloak để quản lý (trùng với metadata.labels.app) template: metadata: labels: app: keycloak # Nhãn của Pod (phải trùng với selector.matchLabels.app và metadata.labels.app ở trên) spec: containers: - name: keycloak # Tên container (nên đặt tên giống với metadata.labels.app ở trên) image: quay.io/keycloak/keycloak:25.0.2 args: ["start-dev"] env: - name: KEYCLOAK_ADMIN valueFrom: configMapKeyRef: name: bank-configmap key: KEYCLOAK_ADMIN - name: KEYCLOAK_ADMIN_PASSWORD valueFrom: configMapKeyRef: name: bank-configmap key: KEYCLOAK_ADMIN_PASSWORD ports: - name: http # Đặt tên cho cổng để dễ nhận biết cổng này thuộc về dịch vụ gì containerPort: 8080 # Cổng 8080 --- apiVersion: v1 # apiVersion dùng để triển khai 1 dịch vụ kind: Service # Loại cấu hình (Service) metadata: name: keycloak # Tên Service (tên này sẽ như là 1 hostname để gọi đến các Pod, trong `Docker Compose` thì sẽ là tên của service) spec: selector: app: keycloak # Chọn Pod có nhãn app=keycloak để quản lý (trùng với metadata.labels.app cấu hình `Deployment`) type: LoadBalancer # Loại Service [LoadBalancer (Map cổng ra bên ngoài), NodePort (Map cổng ra bên ngoài), ClusterIP (Chỉ sử dụng trong Cluster)] ports: - name: http # Đặt tên cho cổng để dễ nhận biết cổng này thuộc về dịch vụ gì port: 7080 # Cổng 7080 sẽ map ra bên ngoài targetPort: 8080 # Đích đến của dịch vụ (cổng 8080 của bên trong Pod) ``` Sau khi định nghĩa xong file `keycloak.yml`, sử dụng câu lệnh sau để triển khai `Keycloak` lên `Kubernetes`: ```bash kubectl apply -f keycloak.yml ``` ## 3. Triển khai `Spring Cloud Config Server` trên `Kubernetes` Trước tiên cần tạo `image` của `Spring Cloud Config Server` và `push` lên `Docker Hub` hoặc `GitHub Container Registry`. Sau đó, triển khai `Spring Cloud Config Server` trên `Kubernetes` bằng cách sử dụng `Deployment` và `Service`. >configserver.yml ```yaml apiVersion: apps/v1 # apiVersion dùng để deploy 1 ứng dụng kind: Deployment # Loại cấu hình (Deployment) - dùng để deploy 1 ứng dụng metadata: # Thông tin về Deployment name: configserver-deployment # Tên Deployment labels: app: configserver # Gán nhãn cho ứng dụng được deploy (configserver) spec: # Thông tin về cấu hình của Deployment replicas: 1 # Số lượng Pod được tạo ra từ Deployment selector: matchLabels: # Chọn Pod dựa trên nhãn app: configserver # Chọn Pod có nhãn app=configserver để quản lý (trùng với metadata.labels.app) template: # Template của Pod metadata: # Thông tin về Pod labels: app: configserver # Nhãn của Pod (phải trùng với selector.matchLabels.app và metadata.labels.app ở trên) spec: # Thông tin về cấu hình của Pod containers: # Thông tin về container (Lưu ý nên chỉ có 1 container trong 1 Pod, nếu cần nhiều container thì tạo nhiều Pod, hoặc nếu có 1 container phụ thuộc vào container chính thì sử dụng sidecar container) - name: configserver # Tên container (nên đặt tên giống với metadata.labels.app ở trên) image: dannguyenmessi/configserver:v1 # Image của container (không có prefix thì sẽ lấy image từ Local, nếu muốn lấy image từ Docker Hub thì phải thêm prefix docker.io/ trước tên image) ports: # Cổng mà container sẽ sử dụng ở bên trong Pod - containerPort: 8071 # Cổng 8071 --- # Dấu --- để phân biệt giữa các cấu hình Deployment và Service apiVersion: v1 # apiVersion dùng để triển khai 1 dịch vụ kind: Service # Loại cấu hình (Service) metadata: # Thông tin về Service name: configserver # Tên Service (tên này sẽ như là 1 hostname để gọi đến các Pod, trong `Docker Compose` thì sẽ là tên của service) spec: # Thông tin về cấu hình của Service selector: # Chọn Pod dựa trên nhãn app: configserver # Chọn Pod có nhãn app=configserver để quản lý (trùng với metadata.labels.app cấu hình `Deployment`) type: LoadBalancer # Loại Service [LoadBalancer (Map cổng ra bên ngoài), NodePort (Map cổng ra bên ngoài), ClusterIP (Chỉ sử dụng trong Cluster)] ports: # Cổng mà Service sẽ sử dụng ở bên ngoài - protocol: TCP # Giao thức TCP port: 8071 # Cổng 8071 sẽ map ra bên ngoài targetPort: 8071 # Đích đến của dịch vụ (cổng 8071 của bên trong Pod) ``` Sau khi định nghĩa xong file `configserver.yml`, sử dụng câu lệnh sau để triển khai `Spring Cloud Config Server` lên `Kubernetes`: ```bash kubectl apply -f configserver.yml ``` Tương tự với các `Microservices` khác, cần phải triển khai `Eureka Server`, `Gateway Server`, `Accounts Service`, `Loans Service`, `Cards Service` lên `Kubernetes` bằng cách sử dụng `Deployment` và `Service`. NHƯ VẬY, NẾU TẠO NHIỀU `REPLICAS` CHO 1 `DEPLOYMENT`, KHI CHẠY ỨNG DỤNG, CÁC `POD` SẼ ĐƯỢC PHÂN PHỐI ĐỀU TRÊN CÁC `NODE` TRONG `CLUSTER`. NẾU CÓ 1 `POD` BỊ LỖI HOẶC BỊ SHUTDOWN, `KUBERNETES` SẼ TỰ ĐỘNG KHÔI PHỤC `POD` ĐÓ MÀ KHÔNG CẦN PHẢI CAN THIỆP. VÀ SỐ LƯỢNG `POD` VẪN ĐƯỢC PHỤC HỒI NHƯ BAN ĐẦU. # D. Các phân loại `Service` trong `Kubernetes` Chúng ta có thể nhận ra rằng có 3 loại `Service` trong `Kubernetes` ở trong file `yml` của cấu hình `Service`: ```yaml ... type: LoadBalancer # Loại Service [LoadBalancer (Map cổng ra bên ngoài), NodePort (Map cổng ra bên ngoài), ClusterIP (Chỉ sử dụng trong Cluster)] ... ``` Có 3 loại `Service` trong `Kubernetes`: 1. `ClusterIP` Service: Dùng để kết nối các `Pod` trong `Cluster`. `ClusterIP` Service chỉ có thể truy cập từ bên trong `Cluster` và không thể truy cập từ bên ngoài `Cluster`. `ClusterIP` Service được sử dụng để kết nối các `Pod` với nhau trong `Cluster`. VD: ```yaml ... spec: selector: app: configserver type: ClusterIP ports: - protocol: TCP port: 80 targetPort: 8071 ... ``` > Chỉ có thể truy cập `configserver` từ bên trong `Cluster` thông qua cổng `80`, với `targetPort` là cổng `8071` của `Pod`. Và không thể truy cập từ bên ngoài `Cluster`. 2. `NodePort` Service: Dùng để kết nối các `Pod` trong `Cluster` và cũng có thể truy cập từ bên ngoài `Cluster`. `NodePort` sử dụng giá trị từ `30000` đến `32767` để mở cổng truy cập từ bên ngoài `Cluster`. `NodePort` Service được sử dụng để kết nối các `Pod` với nhau trong `Cluster` và cũng có thể truy cập từ bên ngoài `Cluster`. VD: ```yaml ... spec: selector: app: configserver type: NodePort ports: - protocol: TCP port: 80 targetPort: 8071 nodePort: 30001 ... ``` > Có thể truy cập `configserver` từ bên trong `Cluster` thông qua `:30001`, với `targetPort` là cổng `8071` của `Pod`. Và cũng có thể truy cập từ bên ngoài `Cluster`. 3. `LoadBalancer` Service: Dùng để kết nối các `Pod` trong `Cluster` và cũng có thể truy cập từ bên ngoài `Cluster`. `LoadBalancer` Service được sử dụng để kết nối các `Pod` với nhau trong `Cluster` và cũng có thể truy cập từ bên ngoài `Cluster`. Nó giống với `NodePort` Service nhưng có thêm `LoadBalancer` để phân phối tải. VD: ```yaml ... spec: selector: app: configserver type: LoadBalancer ports: - protocol: TCP port: 80 targetPort: 8071 ... ``` > Có thể truy cập `configserver` từ bên trong `Cluster` thông qua cổng `80`, với `targetPort` là cổng `8071` của `Pod`. Và cũng có thể truy cập từ bên ngoài `Cluster`. 4. `ExternalName` Service: Dùng để kết nối các `Pod` trong `Cluster` và cũng có thể truy cập từ bên ngoài `Cluster` bằng cách sử dụng `DNS` để map tên `Service` thành `ExternalName` (đóng vai trò là `CNAME`) phù hợp cho các tổ chức doanh nghiệp muốn sử dụng `DNS` để truy cập `Service`. VD: ```yaml ... spec: selector: app: configserver type: ExternalName externalName: my.database.example.com ... ``` > Có thể truy cập `configserver` từ bên trong `Cluster` thông qua `my.database.example.com`, với `externalName` là tên `Service` muốn truy cập. # E. Helm ## 1. Giới thiệu về `Helm` `Helm` hoạt động như một `package manager` cho `Kubernetes`. Giống như `package manager` là một tập hợp các công cụ phần mềm, tự động các tiến trình như `cài đặt`, `nâng cấp phiên bản quản lý`, `xóa các ứng dụng trên máy tính` một cách nhất quán. `Helm` cũng tự động hóa việc cài đặt, khôi phục, nâng cấp nhiều `K8s manifest` với một lệnh duy nhất. Các lợi ích của `Helm`: - `Helm` hỗ trợ đóng gói các file `YAML` thành một `chart` duy nhất: Với sự giúp đỡ của `Helm` chúng ta có thể đóng gói các file `yaml manifest` thành một ứng dụng bên trong một `chart` duy nhất. Điều tương tự có thể được phân phối lên các `public` hoặc `private repositories` để chia sẻ với cộng đồng hoặc tự sử dụng. - `Helm` hỗ trợ viễ cài đặt dễ dàng hơn: Với sự giúp đỡ từ `Helm` chúng ta có thể `thiết lập/nâng cấp/khôi phục/xóa bỏ` toàn bộ các ứng dụng bên trong K8s chỉ với `1 lệnh` duy nhất (Không cần phải chạy thủ công các lệnh `kubectl apply` cho từng tệp `manifest`). - `Helm` hỗ trợ xuất xưởng và quản lý phiên bản: `Helm` tự động duy trì lịch sử của các `manifest` đã được cài đặt. Do đó, việc khôi phục toàn bộ `K8s Cluster` về trạng thái hoạt động trước đó chỉ cần là 1 lệnh duy nhất. ## 2. Cài đặt `Helm` `Helm` là một công cụ quản lý gói cho `Kubernetes`. Nó cho phép bạn định nghĩa, cài đặt và quản lý các ứng dụng `Kubernetes`. Để cài đặt `Helm`, xem hướng dẫn tại đây [Installing Helm](https://helm.sh/docs/intro/install/) Sau khi cài xong, kiểm tra phiên bản `Helm` bằng câu lệnh: ```bash helm version ``` ### 2.1. Cài đặt `Kubernetes Dashboard` bằng `Helm` Câu lệnh cài đặt `Kubernetes UI`: ```bash # Add thư viện Kubernetes Dashboard helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/ # Cài đặt Kubernetes Dashboard với namespace kubernetes-dashboard helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard ``` ### 2.2. Cài đặt `Chart` bằng `Helm` `Chart` là một gói chứa tất cả các tệp cần thiết để tạo một ứng dụng `Kubernetes`. `Chart` bao gồm tất cả các tệp `YAML` cần thiết để triển khai ứng dụng, cũng như các giá trị mặc định cho các biến môi trường, cấu hình `Kubernetes`, và các tệp `template` để tạo `Kubernetes manifest`. Ta chỉ cần cài đặt `Chart` mà không cần phải tạo `Kubernetes manifest` một cách thủ công, và ứng dụng sẽ được triển khai một cách tự động. Ví dụ câu lệnh cài đặt `Chart` của `WordPress`: ```bash # Add thư viện Bitnami/Wordpress helm repo add bitnami https://charts.bitnami.com/bitnami # Cài đặt Chart của Wordpress helm install my-app bitnami/wordpress ``` Sau khi cài đặt xong, xem các hướng dẫn ở Terminal để có thể truy cập vào `WordPress` và `MySQL` thông qua `URL` và `password` được sinh ra. ## 3. Cấu trúc của `Helm Chart` `Helm Chart` bao gồm các thư mục và file sau: Ví dụ cấu trúc của `Helm Chart` của `WordPress`: ```bash wordpress/ |--- Chart.yml |--- values.yml |--- charts/ |--- templates/ |--- ... ``` Trong đó: - `wordpress/`: Thư mục chứa toàn bộ `Helm Chart` của `WordPress`. Là tên của `Helm Chart` mà chúng ta nhận được trong quá trình cài đặt/tạo `Helm Chart`. - `Chart.yml`: File cấu hình của `Helm Chart`. Chứa các thông tin về `Helm Chart` như `name`, `version`, `description`, `maintainers`, `source`, `dependencies`, `apiVersion`, `appVersion`,... - `values.yml`: File chứa các `giá trị động` của `Helm Chart` thông qua ký hiệu `{{ .Values. }}` ở trong các file `template`. Ngoài ra nó còn chứa các giá trị mặc định của `Helm Chart` như `image`, `replicas`, `service`, `port`, `env`,... - `charts/`: Thư mục chứa các `dependencies` cụ thể của `Helm Chart`. Các `dependencies` này sẽ được cài đặt cùng với `Helm Chart` chính. (Dependences có thể là 1 `Helm Chart` khác). - `templates/`: Thư mục chứa các file yaml `manifest template` chung của `Helm Chart`. Các `template` này sẽ được sử dụng để tạo `Kubernetes manifest` cho ứng dụng. ### 3.1. Tự tạo `Helm Chart` cho ứng dụng của mình (VD cho ứng dụng `Spring Boot` `Accounts & Loans & Cards Banking`) Các lưu ý, ký hiệu khi tạo `Helm Chart`: - `{{ .Values. }}`: Sử dụng để truy cập vào các giá trị trong file `values.yml`. - `{{ .Release.Name }}`: Tên của `Helm Release`. - `{{ .Release.Namespace }}`: `Namespace` của `Helm Release`. - `{{ .Release.Service }}`: Tên của `Service` của `Helm Release`. - `{{ .Release.Revision }}`: Số phiên bản của `Helm Release`. - `{{ .Chart.Name }}`: Tên của `Helm Chart`. - `{{ .Chart.Version }}`: Phiên bản của `Helm Chart`. - `{{ .Chart.Description }}`: Mô tả của `Helm Chart`. - `{{ .Chart.Home }}`: `URL` của trang chủ của `Helm Chart`. - `{{ .Chart.Sources }}`: `URL` của nguồn của `Helm Chart`. - `{{ .Chart.Icon }}`: `URL` của biểu tượng của `Helm Chart`. - `{{ .Files.Get }}`: Sử dụng để truy cập vào nội dung của file trong thư mục `files/` của `Helm Chart`. - `{{ .Files.Get / }}`: Sử dụng để truy cập vào nội dung của file trong thư mục `files/` của `Helm Chart`. - `{{ include "" . }}`: Sử dụng để bao gồm một `template` khác vào `template` hiện tại. - `{{ toYaml .Values. }}`: Sử dụng để chuyển đổi giá trị của `Values` thành `yaml`. - `{{ toToml .Values. }}`: Sử dụng để chuyển đổi giá trị của `Values` thành `toml`. - `{{ toJson .Values. }}`: Sử dụng để chuyển đổi giá trị của `Values` thành `json`. - `{{ .Capabilities.APIVersions.Has "" }}`: Sử dụng để kiểm tra xem `APIVersion` có tồn tại hay không. - `{{ .Capabilities.KubeVersion.Has "" }}`: Sử dụng để kiểm tra xem `KubeVersion` có tồn tại hay không. - `{{- ... -}}`: Sử dụng để loại bỏ khoảng trắng ở đầu và cuối của `template`. - `{{- if .Values. }}`: Sử dụng để kiểm tra giá trị của `Values`. Sau đó, sử dụng `{{- end }}` để kết thúc câu lệnh `if`. - `{{- range .Values. }}`: Sử dụng để lặp qua các giá trị của `Values`. Sau đó, sử dụng `{{- end }}` để kết thúc câu lệnh `range`. - `{{- define "" -}}`: Sử dụng để định nghĩa một `template` mới. Sau đó, sử dụng `{{- end -}}` để kết thúc câu lệnh `define`. - `{{- template "" . -}}`: Sử dụng để sử dụng một `template` đã được định nghĩa trước đó bằng câu lệnh `define`. #### 3.1.1. Tạo `chart` làm `dependences - chart mẫu` cho các `chart` khác ##### 3.1.1.1. Đầu tiên cần tạo tên của `Helm Chart`: ```bash helm create bank-common ``` SAU KHI CHẠY LỆNH TRÊN, MỘT THƯ MỤC MỚI SẼ ĐƯỢC TẠO RA VỚI TÊN LÀ `/bank-common`. TIẾN HÀNH XÓA CÁC `FILE` TRONG `TEMPLATES/` VÀ XÓA HẾT CÁC NỘI DUNG TRONG `values.yml` ĐỂ BẮT ĐẦU TẠO `Helm Chart` MỚI. ##### 3.1.1.2. Tạo các `file template` chung trong thư mục `templates/` (Ví dụ như `deployment.yaml`, `service.yaml`, `configmap.yaml`, `ingress.yaml`, `secret.yaml`,...). Lưu ý các `file template` sẽ là khung của `Kubernetes manifest` cho ứng dụng nên cần phải mang tính chất chung và tái sử dụng. > Ví dụ file `bank-common/templates/service.yaml`: ```yaml {{- define "common.service" -}} # Định nghĩa template service apiVersion: v1 # Version dành cho Service kind: Service # Loại cấu hình là Service metadata: name: {{ .Values.serviceName }} # Tên Service, lấy giá trị serviceName từ file values.yaml spec: selector: # Chọn Pod dựa trên label app: {{ .Values.appLabel }} # Lấy giá trị appLabel từ file values.yaml type: {{ .Values.service.type }} # Loại Service, lấy giá trị type từ file values.yaml port: - name: http # Tất cả các dịch vụ khác sẽ có chung cấu hình này protocol: TCP # Giao thức sử dụng cho tất cả các dịch vụ (Vì nó là một biến tĩnh) port: {{ .Values.service.port }} # Port của Service, lấy giá trị port từ file values.yaml targetPort: {{ .Values.service.targetPort }} # Port của Pod, lấy giá trị targetPort từ file values.yaml {{- end -}} # Kết thúc định nghĩa template service ``` > Ví dụ file `deployment.yaml`: ```yaml {{- define "common.deployment" -}} # Định nghĩa template deployment apiVersion: apps/v1 # Version dành cho Deployment kind: Deployment # Loại cấu hình là Deployment metadata: name: {{ .Values.deploymentName }} # Tên Deployment, lấy giá trị deploymentName từ file values.yaml labels: # Label cho Deployment app: {{ .Values.appLabel }} # Lấy giá trị appLabel từ file values.yaml spec: replicas: {{ .Values.replicaCount }} # Số lượng Pod, lấy giá trị replicaCount từ file values.yaml selector: # Chọn Pod dựa trên label matchLabels: app: {{ .Values.appLabel }} # Lấy giá trị appLabel từ file values.yaml template: # Template Pod metadata: labels: # Label cho Pod app: {{ .Values.appLabel }} # Lấy giá trị appLabel từ file values.yaml spec: containers: - name: {{ .Values.appLabel }} # Tên Container, lấy giá trị appLabel từ file values.yaml image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" # Image của Container, lấy giá trị repository và tag từ file values.yaml ports: - containerPort: {{ .Values.containerPort }} # Port của Container, lấy giá trị containerPort từ file values.yaml protocol: TCP # Giao thức sử dụng cho Container env: {{- if .Values.appname_enabled }} # Nếu có appname_enabled trong file values.yaml - name: SPRING_APPLICATION_NAME # Tên biến môi trường value: {{ .Values.appName }} # Giá trị biến môi trường, lấy giá trị appname từ file values.yaml {{- end }} # Kết thúc điều kiện {{- if .Values.profile_enabled }} # Nếu có profile_enabled trong file values.yaml - name: SPRING_PROFILES_ACTIVE # Tên biến môi trường valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: SPRING_PROFILES_ACTIVE # Key của ConfigMap {{- end }} # Kết thúc điều kiện {{- if .Values.config_enabled }} # Nếu có config_enabled trong file values.yaml - name: SPRING_CONFIG_IMPORT # Tên biến môi trường valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: SPRING_CONFIG_IMPORT # Key của ConfigMap {{- end }} # Kết thúc điều kiện {{- if .Values.eureka_enabled }} # Nếu có eureka_enabled trong file values.yaml - name: EUREKA_CLIENT_SERVICEURL_DEFAULTZONE # Tên biến môi trường valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: EUREKA_CLIENT_SERVICEURL_DEFAULTZONE # Key của ConfigMap {{- end }} # Kết thúc điều kiện {{- if .Values.resourceserver_enabled }} # Nếu có resourceserver_enabled trong file values.yaml - name: SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK-SET-URI # Tên biến môi trường valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK-SET-URI # Key của ConfigMap {{- end }} # Kết thúc điều kiện {{- if .Values.otel_enabled }} # Nếu có otel_enabled trong file values.yaml - name: JAVA_TOOL_OPTIONS # Tên biến môi trường valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: JAVA_TOOL_OPTIONS # Key của ConfigMap - name: OTEL_EXPORTER_OTLP_ENDPOINT # Tên biến môi trường valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: OTEL_EXPORTER_OTLP_ENDPOINT # Key của ConfigMap - name: OTEL_METRICS_EXPORTER valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: OTEL_METRICS_EXPORTER # Key của ConfigMap - name: OTEL_SERVICE_NAME valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: OTEL_SERVICE_NAME # Key của ConfigMap {{- end }} # Kết thúc điều kiện {{- if .Values.kafka_enabled }} # Nếu có kafka_enabled trong file values.yaml - name: SPRING_CLOUD_STREAM_KAFKA_BINDER_BROKERS # Tên biến môi trường valueFrom: configMapKeyRef: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml key: SPRING_CLOUD_STREAM_KAFKA_BINDER_BROKERS # Key của ConfigMap {{- end }} # Kết thúc điều kiện {{- end -}} # Kết thúc định nghĩa template deployment ``` > Ví dụ file `configmap.yaml`: ```yaml {{- define "common.configmap" -}} # Định nghĩa template configmap apiVersion: v1 # Version dành cho ConfigMap kind: ConfigMap # Loại cấu hình là ConfigMap metadata: name: {{ .Values.global.configMapName }} # Tên ConfigMap, lấy giá trị configmapName từ file values.yaml data: # Dữ liệu của ConfigMap SPRING_PROFILES_ACTIVE: {{ .Values.global.activeProfile }} SPRING_CONFIG_IMPORT: {{ .Values.global.configServerURL }} EUREKA_CLIENT_SERVICEURL_DEFAULTZONE: {{ .Values.global.eurekaServerURL }} SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK-SET-URI: {{ .Values.global.keyCloakURL }} JAVA_TOOL_OPTIONS: {{ .Values.global.openTelemetryJavaAgent }} OTEL_EXPORTER_OTLP_ENDPOINT: {{ .Values.global.otelExporterEndPoint }} OTEL_METRICS_EXPORTER: {{ .Values.global.otelMetricsExporter }} SPRING_CLOUD_STREAM_KAFKA_BINDER_BROKERS: {{ .Values.global.kafkaBrokerURL }} {{- end -}} # Kết thúc định nghĩa template configmap ``` #### 3.1.2. Tạo `chart` cho ứng dụng `Accounts, Loans, Cards, Eureka Server, GateWayServer, Cloud Config của App Banking` Do đã tạo `chart bank-common` làm `dependences - chart mẫu` cho các `chart` khác, nên việc tạo `chart` cho ứng dụng `Accounts Banking` sẽ dễ dàng hơn. Chỉ cần sử dụng các `template` đã được định nghĩa trong `chart bank-common` và chỉnh sửa một số giá trị cụ thể cho ứng dụng `Accounts Banking`. ##### 3.1.2.1. Đầu tiên cần tạo tên của `Helm Chart`: ```bash helm create accounts ``` SAU KHI CHẠY LỆNH TRÊN, MỘT THƯ MỤC MỚI SẼ ĐƯỢC TẠO RA VỚI TÊN LÀ `/accounts`. TIẾN HÀNH XÓA CÁC `FILE` TRONG `TEMPLATES/` VÀ XÓA HẾT CÁC NỘI DUNG TRONG `values.yml` ĐỂ BẮT ĐẦU TẠO `Helm Chart` MỚI. ##### 3.1.2.2. Tiến hành thêm `dependences` vào `chart accounts` qua file `Chart.yml`: > Ví dụ file `accounts/Chart.yml`: ```yaml ... dependencies: - name: bank-common # Tên của chart dependences version: 0.1.0 # Phiên bản của chart dependences (version: 0.1.0) repository: file://../../bank-common # Đường dẫn đến thư mục chứa chart dependences ``` Sau khi thêm `dependencies` vào `Chart.yaml`, tiến hành cài đặt `dependences` vào `chart accounts` bằng câu lệnh: ```bash helm dependencies build ``` Lúc này, `Helm` sẽ tải `dependences` từ `file://../../bank-common` và cài đặt vào thư mục `charts/` của `chart accounts`. ##### 3.1.2.3. Tạo các `file template` chung trong thư mục `templates/` (Ví dụ như `deployment.yaml`, `service.yaml`, `configmap.yaml`, `ingress.yaml`, `secret.yaml`,...). Chúng ta sẽ sử dụng `{{- template . -}}` để bao gồm các `template` từ `chart bank-common` vào `chart accounts`. > Ví dụ file `accounts/templates/service.yaml`: ```yaml {{- template "common.service" . -}} # Bao gồm template có tên common.service từ chart bank-common ``` > Ví dụ file `accounts/templates/deployment.yaml`: ```yaml {{- template "common.deployment" . -}} # Bao gồm template có tên common.deployment từ chart bank-common ``` ##### 3.1.2.4. Tạo `values` cho `chart accounts` trong file `values.yml` để chứa các giá trị động của `chart accounts`. > Ví dụ file `accounts/values.yml`: ```yaml deploymentName: accounts-deployment serviceName: accounts appLabel: accounts appName: accounts replicaCount: 1 image: repository: dannguyenmessi/accounts tag: v1 containerPort: 8080 service: type: ClusterIP port: 8080 targetPort: 8080 appname_enabled: true profile_enabled: true config_enabled: true eureka_enabled: true resouceserver_enabled: false otel_enabled: true kafka_enabled: true ``` TƯƠNG TỰ LẶP LẠI CÁC BƯỚC VỚI CÁC `CHART` CÒN LẠI NHƯ `LOANS, CARDS, EUREKA SERVER, GATEWAY SERVER, CLOUD CONFIG`. #### 3.1.3. Tạo `chart` chứa biến môi trường `environment` cho tất cả các `chart` trong ứng dụng `Banking` (VD cho môi trường `dev`, `qa`, `prod`) Vì đã tạo tất cả `chart` dịch vụ ở bước trên, nên việc tạo `chart` chứa biến môi trường `environment` cho tất cả các `chart` trong ứng dụng `Banking` sẽ dễ dàng hơn. Chỉ cần sử dụng các `template` đã được định nghĩa trong `chart bank-common` và thêm các dependences của tất cả các `chart` trên. ##### 3.1.3.1. Tạo `chart` chứa biến môi trường `environment` cho tất cả các `chart` trong ứng dụng `Banking`: ```bash helm create dev-env ``` SAU KHI CHẠY LỆNH TRÊN, MỘT THƯ MỤC MỚI SẼ ĐƯỢC TẠO RA VỚI TÊN LÀ `/dev-env`. TIẾN HÀNH XÓA CÁC `FILE` TRONG `TEMPLATES/` VÀ XÓA HẾT CÁC NỘI DUNG TRONG `values.yml` ĐỂ BẮT ĐẦU TẠO `Helm Chart` MỚI. ##### 3.1.3.2. Tiến hành thêm `dependences` vào `chart dev-env` qua file `Chart.yml`: Chúng ta thêm tất cả các `chart` dịch vụ, `chart bank-common` vào `dependences` của `chart dev-env`. `chart dev-env` sẽ chứa các biến môi trường `environment` cho tất cả các `chart` trong ứng dụng `Banking`. > Ví dụ file `dev-env/Chart.yml`: ```yaml ... dependencies: - name: bank-common version: 0.1.0 repository: file://../../bank-common - name: configserver version: 0.1.0 repository: file://../../bank-services/configserver - name: eurekaserver version: 0.1.0 repository: file://../../bank-services/eurekaserver - name: accounts version: 0.1.0 repository: file://../../bank-services/accounts - name: cards version: 0.1.0 repository: file://../../bank-services/cards - name: loans version: 0.1.0 repository: file://../../bank-services/loans - name: gatewayserver version: 0.1.0 repository: file://../../bank-services/gatewayserver - name: message version: 0.1.0 repository: file://../../bank-services/message ``` Sau khi thêm `dependencies` vào `Chart.yaml`, tiến hành cài đặt `dependences` vào `chart dev-env` bằng câu lệnh: ```bash helm dependencies build ``` Lúc này, `Helm` sẽ tải `dependences` từ `file://../../bank-common`, `file://../../bank-services/configserver`, `file://../../bank-services/eurekaserver`, `file://../../bank-services/accounts`, `file://../../bank-services/cards`, `file://../../bank-services/loans`, `file://../../bank-services/gatewayserver`, `file://../../bank-services/message` và cài đặt vào thư mục `charts/` của `chart dev-env`. ##### 3.1.3.3. Tạo file `configmap.yaml` trong thư mục `templates/` của `chart dev-env` để chứa các biến môi trường `environment` cho tất cả các `chart` trong ứng dụng `Banking`. Vì chúng ta đã khai báo khung `configmap` trong `chart bank-common`, nên việc tạo `configmap` cho `chart dev-env` sẽ dễ dàng hơn. Chỉ cần sử dụng `{{- template . -}}` để bao gồm các `template` từ `chart bank-common` vào `chart dev-env`. > Ví dụ file `dev-env/templates/configmap.yaml`: ```yaml {{- template "common.configmap" . -}} # Bao gồm template có tên common.configmap từ chart bank-common ``` ##### 3.1.3.4. Tạo `values` cho `chart dev-env` trong file `values.yml` để chứa các giá trị động của `chart dev-env`. LƯU Ý, NÊN SỬ DỤNG BIẾN TOÀN CỤC ĐỂ CHỨA CÁC GIÁ TRỊ MÔI TRƯỜNG CHUNG CHO TẤT CẢ CÁC `CHART` TRONG ỨNG DỤNG BANKING. SỬ DỤNG `global` ĐỂ CHỨA CÁC GIÁ TRỊ MÔI TRƯỜNG CHUNG CHO TẤT CẢ CÁC `CHART` TRONG ỨNG DỤNG BANKING. > Ví dụ file `dev-env/values.yml`: ```yaml global: # Biến môi trường chung cho tất cả các chart trong ứng dụng Banking (Biến toàn cục) configMapName: bankdev-configmap activeProfile: default configServerURL: configserver:http://configserver:8071/ eurekaServerURL: http://eurekaserver:8070/eureka/ keyCloakURL: http://keycloak.default.svc.cluster.local:80/realms/master/protocol/openid-connect/certs openTelemetryJavaAgent: "-javaagent:/app/libs/opentelemetry-javaagent-1.32.0.jar" otelExporterEndPoint: http://tempo-grafana-tempo-distributor:4317 otelMetricsExporter: none kafkaBrokerURL: kafka-controller-0.kafka-controller-headless.default.svc.cluster.local:9092 ``` TƯƠNG TỰ LẶP LẠI CÁC BƯỚC VỚI CÁC `CHART` CÒN LẠI NHƯ `QA-ENV, PROD-ENV`. ### 3.2. Sử dụng `Helm Chart` của bên thứ 3 (Ví dụ như `Bitnami/Keycloak`,...) để thêm vào ứng dụng của mình #### 3.2.1. Sử dụng `Keycloak` để xác thực người dùng. Chúng ta có thể sử dụng Docker, public `image` của `Keycloak` rồi sau đó tự viết `Helm Chart` như ở phần đầu. Tuy nhiên để nhanhm và phù hợp với `K8s` nên sử dụng `Helm Chart` của `Bitnami/Keycloak`. > LƯU Ý: KHI SỬ DỤNG `HELM CHAT` BÊN THỨ 3, VIỆC KẾT NỐI VỚI CÁC SERVICE KHÁC TRONG `CLUSTER` SẼ KHÁC SO VỚI VIỆC DÙNG IMAGE CỦA `DOCKER` LÀ CHỈ CẦN `:`. ##### 3.2.1.1. Cài đặt `Keycloak` bằng `Helm Chart` của `Bitnami/Keycloak`: Để tích hợp `Bitnami/Keycloak` vào ứng dụng của mình, chúng ta nên `download` cả thư mục `helm` trên github của `Bitnami` về máy và chỉnh sửa file `values.yml` để phù hợp với ứng dụng của mình. ```bash git clone https://github.com/bitnami/charts.git ``` SAU KHI `DOWNLOAD` XONG, CHÚNG TA COPY THƯ MỤC Ở `bitnami/keyloak` rồi ném vào thư mục chứa các `Helm Chart` của ứng dụng của mình. LÚC NÀY CHÚNG TA SẼ CÓ THƯ MỤC `keycloak` TRONG THƯ MỤC CHỨA CÁC `Helm Chart` CỦA ỨNG DỤNG CỦA MÌNH. ##### 3.2.1.2. Sửa file `values.yml` trong thư mục `keycloak` để phù hợp với ứng dụng của mình. - Sửa `auth` để đăng nhập vào `Keycloak`. ```yaml auth: adminUser: user # Tên đăng nhập của admin adminPassword: "password" # Mật khẩu của admin ``` - Sửa `service.type` thành `LoadBalancer` để có thể truy cập từ bên ngoài. ```yaml service: type: LoadBalancer ``` ##### 3.2.1.3. Tiến hành cài đặt `Keycloak` để đưa lên `K8s`: Trước khi cài đặt, ta vào thư mục của `chart keycloak` và chạy lệnh sau để build các `dependencies` của `chart keycloak`. ```bash helm dependencies build ``` Sau khi build xong, tiến hành nhảy lên thư mục chứa `chart keycloak` và chạy lệnh sau để cài đặt `Keycloak` lên `K8s`. ```bash helm install keycloak keycloak # keycloak là tên của release # keycloak là tên của chart (sử dụng ở local, vì bình thường tham số này sẽ là URL của chart) ``` Sau khi chạy lệnh, chúng ta sẽ có `Keycloak` chạy trên `K8s`. Trong `Terminal` chúng ta để ý dòng sau: ```bash Keycloak can be accessed through the following DNS name from within your cluster: keycloak.default.svc.cluster.local (port 80) ``` Đây là `DNS` của `Keycloak` trong `cluster`. Các `service` khác trong `cluster` có thể truy cập vào `Keycloak` thông qua `DNS` này. Để hiển thị `IP` và `PORT` của `Keycloak`: ```bash export HTTP_SERVICE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[?(@.name=='http')].port}" services keycloak) export SERVICE_IP=$(kubectl get svc --namespace default keycloak -o jsonpath='{.status.loadBalancer.ingress[0].ip}') echo "http://${SERVICE_IP}:${HTTP_SERVICE_PORT}/" ``` #### 3.2.2. Sử dụng `Kafla` để xử lý dữ liệu. Chúng ta có thể sử dụng Docker, public `image` của `Kafka` rồi sau đó tự viết `Helm Chart` như ở phần đầu. Tuy nhiên để nhanh và phù hợp với `K8s` nên sử dụng `Helm Chart` của `Bitnami/Kafka`. > LƯU Ý: KHI SỬ DỤNG `HELM CHAT` BÊN THỨ 3, VIỆC KẾT NỐI VỚI CÁC SERVICE KHÁC TRONG `CLUSTER` SẼ KHÁC SO VỚI VIỆC DÙNG IMAGE CỦA `DOCKER` LÀ CHỈ CẦN `:`. Các bước thực hiện tương tự như ở phần `3.2.1`. > LƯU Ý, TRONG FILE `values.yml` CỦA `KAFKA`, CHÚNG TA CÓ THỂ SỬA `REPLICATION FACTOR`, `NUMBER OF BROKERS`, `NUMBER OF PARTITIONS`, `ZOOKEEPER` ĐỂ PHÙ HỢP VỚI ỨNG DỤNG CỦA MÌNH. ĐĂC BIỆT, NẾU XÂY DỰNG Ở `LOCAL`, CHÚNG TA PHẢI SỬA TẤT CẢ KEY CÓ VALUE LÀ `SASL_PLAINTEXT` THÀNH `PLAINTEXT`. SAU KHI CÀI ĐẶT XONG, CHÚNG TA ĐỂ Ý DÒNG SAU TRONG `TERMINAL` DÙNG ĐỂ LẤY `DNS` KẾT NỐI VỚI CÁC `SERVICE` KHÁC TRONG `CLUSTER`. ```bash Each Kafka broker can be accessed by producers via port 9092 on the following DNS name(s) from within your cluster: kafka-controller-0.kafka-controller-headless.default.svc.cluster.local:9092 ``` #### 3.2.3. Sử dụng `Prometheus` để giám sát ứng dụng. Chúng ta có thể sử dụng Docker, public `image` của `Prometheus` rồi sau đó tự viết `Helm Chart` như ở phần đầu. Tuy nhiên để nhanh và phù hợp với `K8s` nên sử dụng `Helm Chart` của `Bitnami/kube-prometheus`. > LƯU Ý: KHI SỬ DỤNG `HELM CHAT` BÊN THỨ 3, VIỆC KẾT NỐI VỚI CÁC SERVICE KHÁC TRONG `CLUSTER` SẼ KHÁC SO VỚI VIỆC DÙNG IMAGE CỦA `DOCKER` LÀ CHỈ CẦN `:`. Các bước thực hiện tương tự như ở phần `3.2.1`. > LƯU Ý, TRONG FILE `values.yml` CỦA `PROMETHEUS`, CHÚNG TA SỬA CÁC THÔNG SỐ SAU ĐỂ PHÙ HỢP VỚI ỨNG DỤNG CỦA MÌNH: ```yaml ... additionalScrapeConfigs: enabled: true # Bật chức năng scrape config cho prometheus type: internal # Loại scrape config, internal hoặc external, internal là config được quản lý bởi chart, external là config được quản lý bên ngoài chart external: ## Name of the secret that Prometheus should use for the additional scrape configuration ## name: "" ## Name of the key inside the secret to be used for the additional scrape configuration. ## key: "" internal: jobList: [ { "job_name": "configserver", "metrics_path": "/actuator/prometheus", "static_configs": [ { "targets": ["configserver:8071"] } ] }, { "job_name": "eurekaserver", "metrics_path": "/actuator/prometheus", "static_configs": [ { "targets": ["eurekaserver:8070"] } ] }, { "job_name": "accounts", "metrics_path": "/actuator/prometheus", "static_configs": [ { "targets": ["accounts:8080"] } ] }, { "job_name": "loans", "metrics_path": "/actuator/prometheus", "static_configs": [ { "targets": ["loans:8090"] } ] }, { "job_name": "cards", "metrics_path": "/actuator/prometheus", "static_configs": [ { "targets": ["cards:9000"] } ] }, { "job_name": "gatewayserver", "metrics_path": "/actuator/prometheus", "static_configs": [ { "targets": ["gatewayserver:8072"] } ] } ] # Danh sách các job cần scrape bởi prometheus, chỉ theo dõi các job có trong danh sách này ... ``` SAU KHI CÀI ĐẶT XONG, CHÚNG TA CHẠY LỆNH SAU ĐỂ CÓ THỂ NHÌN THẤY `IP` VÀ `PORT` CỦA `PROMETHEUS` ĐỂ TRUY CẬP VÀO GIAO DIỆN GIÁM SÁT TỪ BÊN NGOÀI. ```bash echo "Prometheus URL: http://127.0.0.1:9090/" kubectl port-forward --namespace default svc/prometheus-kube-prometheus-prometheus 9090:9090 ``` Sau khi cài đặt xong, chúng ta sử dụng lệnh sau để lấy tên các `service` của `loki` đã triển khai trên `K8S` để phục vụ cho việc kết nối với `grafana` để hiển thị `logs`. ```bash kubectl get svc -n default ``` Sau đó, chúng ta tìm các tên của `loki` sau: - `prometheus-kube-prometheus-prometheus` với `PORT` là `9090` Dùng để kết nối tới `Grafana`. #### 3.2.4. Sử dụng `Tempo` để lưu trữ `metrics` và `traces`. Chúng ta có thể sử dụng Docker, public `image` của `Tempo` rồi sau đó tự viết `Helm Chart` như ở phần đầu. Tuy nhiên để nhanh và phù hợp với `K8s` nên sử dụng `Helm Chart` của `bitnami/grafana-tempo`. > LƯU Ý: KHI SỬ DỤNG `HELM CHAT` BÊN THỨ 3, VIỆC KẾT NỐI VỚI CÁC SERVICE KHÁC TRONG `CLUSTER` SẼ KHÁC SO VỚI VIỆC DÙNG IMAGE CỦA `DOCKER` LÀ CHỈ CẦN `:`. Các bước thực hiện tương tự như ở phần `3.2.1`. THAY ĐỔI THÔNG SỐ SAU TRONG FILE `values.yml` CỦA `TEMPO` ĐỂ PHÙ HỢP VỚI ỨNG DỤNG `HTTP` CỦA MÌNH. ```yaml otlp: http: true # Sử dụng giao thức HTTP grpc: true # Sử dụng giao thức gRPC ``` Sau khi cài đặt xong, chúng ta sử dụng lệnh sau để lấy tên các `service` của `tempo` đã triển khai trên `K8S` để phục vụ cho việc kết nối với các `service` khác trong `cluster`, cũng như `grafana` để hiển thị `logs` và `traces`. ```bash kubectl get svc -n default ``` Sau đó, chúng ta tìm các tên của `tempo` sau: - `tempo-grafana-tempo-distributor` với `PORT` là `4317`. - `tempo-grafana-tempo-querier` với `PORT` là `3200`. #### 3.2.5. Sử dụng `Loki` để lưu trữ, đọc `logs`. Chúng ta có thể sử dụng Docker, public `image` của `Loki` rồi sau đó tự viết `Helm Chart` như ở phần đầu. Tuy nhiên để nhanh và phù hợp với `K8s` nên sử dụng `Helm Chart` của `bitnami/grafana-loki`. > LƯU Ý: KHI SỬ DỤNG `HELM CHAT` BÊN THỨ 3, VIỆC KẾT NỐI VỚI CÁC SERVICE KHÁC TRONG `CLUSTER` SẼ KHÁC SO VỚI VIỆC DÙNG IMAGE CỦA `DOCKER` LÀ CHỈ CẦN `:`. Các bước thực hiện tương tự như ở phần `3.2.1`. Sau khi cài đặt xong, chúng ta sử dụng lệnh sau để lấy tên các `service` của `loki` đã triển khai trên `K8S` để phục vụ cho việc kết nối với `grafana` để hiển thị `logs`. ```bash kubectl get svc -n default ``` Sau đó, chúng ta tìm các tên của `loki` sau: - `loki-grafana-loki-gateway` với `PORT` là `80` Dùng để kết nối tới `Grafana`. #### 3.2.6. Sử dụng `Grafana` để hiển thị `logs`, `metrics`, `traces`. Kết nối tới `Prometheus`, `Tempo`, `Loki`. Chúng ta có thể sử dụng Docker, public `image` của `Grafana` rồi sau đó tự viết `Helm Chart` như ở phần đầu. Tuy nhiên để nhanh và phù hợp với `K8s` nên sử dụng `Helm Chart` của `bitnami/grafana`. > LƯU Ý: KHI SỬ DỤNG `HELM CHAT` BÊN THỨ 3, VIỆC KẾT NỐI VỚI CÁC SERVICE KHÁC TRONG `CLUSTER` SẼ KHÁC SO VỚI VIỆC DÙNG IMAGE CỦA `DOCKER` LÀ CHỈ CẦN `:`. Các bước thực hiện tương tự như ở phần `3.2.1`. THAY ĐỔI THÔNG SỐ `datasources` SAU TRONG FILE `values.yml` CỦA `GRAFANA` ĐỂ CÓ THỂ KẾT NỐI VỚI `PROMETHEUS`, `TEMPO`, `LOKI`. CÁC THÔNG SỐ ĐÃ ĐƯỢC GIẢI THÍCH Ở CÁC FILE `DOCKER COMPOSE` ```yaml datasources: secretName: "" secretDefinition: apiVersion: 1 deleteDatasources: # Xóa các datasource cũ trước khi thêm datasource mới - name: Prometheus - name: Loki - name: Tempo datasources: # Danh sách các datasource cần thêm vào Grafana - name: Prometheus # Tên datasource type: prometheus # Loại datasource uid: prometheus # UID của datasource url: http://prometheus-kube-prometheus-prometheus:9090 # URL của datasource (Prometheus) access: proxy orgId: 1 basicAuth: false isDefault: false version: 1 editable: true jsonData: httpMethod: GET - name: Tempo # Tên datasource type: tempo # Loại datasource uid: tempo # UID của datasource url: http://tempo-grafana-tempo-query-frontend:3200 # URL của datasource (Tempo) access: proxy orgId: 1 basicAuth: false isDefault: false version: 1 editable: true jsonData: httpMethod: GET serviceMap: datasourceUid: 'prometheus' # Tạo nút liên kết giữa datasource Prometheus và Tempo - name: Loki # Tên datasource type: loki # Loại datasource uid: loki # UID của datasource access: proxy orgId: 1 editable: true url: http://loki-grafana-loki-gateway:80 # URL của datasource (Loki) jsonData: httpHeaderName1: "X-Scope-OrgID" derivedFields: # Tạo navigation link giữa Loki và Tempo - datasourceUid: tempo matcherRegex: "\\[.+,(.+),.+\\]" name: TraceID url: '$${__value.raw}' secureJsonData: httpHeaderValue1: "tenant1" ``` SAU KHI CÀI ĐẶT CHÚNG TA SỬ DỤNG CÁC CÂU LỆNH SAU TRONG `TERMINAL` ĐỂ LẤY `IP` VÀ `PORT` CỦA `GRAFANA` VÀ CŨNG ĐỂ LẤY `USENAME` VÀ `PASSWORD` ĐỂ ĐĂNG NHẬP VÀO `GRAFANA`. ```bash ## Lấy IP và PORT của Grafana echo "Browse to http://127.0.0.1:8080" kubectl port-forward svc/grafana 3000:3000 & ## Lấy username và password để đăng nhập vào Grafana echo "User: admin" echo "Password: $(kubectl get secret grafana-admin --namespace default -o jsonpath="{.data.GF_SECURITY_ADMIN_PASSWORD}" | base64 -d)" ``` ### 3.3. Chạy ứng dụng trên `K8s` bằng `Helms Chart`. Sau khi đã `install` và `chạy` các phụ thuộc bên thứ 3. Để chạy các `service` của ứng dụng `Banking` trên `K8s` bằng `Helm Chart`, chúng ta sẽ thực hiện các bước sau: 1. Truy cập vào folder `environments`. 2. Chạy bất kỳ 1 trong 3 profile `dev`, `qa`, `prod` bằng lệnh sau: ```bash helm install ``` NHƯ VẬY CHÚNG TA ĐÃ CÀI ĐẶT VÀ CHẠY ỨNG DỤNG `BANKING` TRÊN `K8S` BẰNG `HELM CHART`. SỞ DĨ CHỈ CẦN CHẠY Ở `ENVIRONMENTS` LÀ DO CHÚNG TA ĐÃ TẠO RA `DEPENDENCIES` GIỮA CÁC `CHART` TRONG ỨNG DỤNG `BANKING` Ở HẾT TRONG ĐÂY RỒI. --- *** > LƯU Ý: NHIỀU LÚC `K8S` BỊ LỖI DO `Persistant Volume Claim` TẠO RA. CẦN PHẢI XÓA `PVC` ĐỂ KHẮC PHỤC LỖI. ```bash kubectl get pvc -n kubectl delete pvc -n ``` *** ### 3.4. Sử dụng lệnh `upgrade` để cập nhật ứng dụng trên `K8s`. Để cập nhật ứng dụng trên `K8s` bằng `Helm Chart`, chúng ta sử dụng lệnh `upgrade` để cập nhật `release` đã được cài đặt trước đó. Mục đích của việc này là vừa có thể cập nhật ứng dụng trong môi trường `K8S` mà vẫn giữ được bản cũ trước đó, thuận tiện cho việc `rollback` nếu cần. ```bash helm upgrade ``` Sau khi `upgrade`, một `Revision` mới sẽ được tạo ra. Chúng ta có thể xem `Revision` bằng lệnh sau: ```bash helm history ``` > LƯU Ý: TRƯỢC KHI CẬP NHẬT THAY ĐỔI, sử dụng câu lệnh `helm dependencies build` để cập nhật các `dependencies` của `chart` trước khi `upgrade`. ### 3.5. Sử dụng lệnh `rollback` để quay lại phiên bản cũ của ứng dụng trên `K8s`. Sau khi `upgrade`, thực tế là sẽ tạo ra 1 `Revision` mới. Để quay lại phiên bản cũ, chúng ta sử dụng lệnh `rollback` để quay lại `Revision` cũ. ```bash helm rollback ``` Để xem `Revision` của `release`, chúng ta sử dụng lệnh sau: ```bash helm history ``` ### 3.6. Sử dụng lệnh `uninstall` để gỡ ứng dụng khỏi `K8s`. Để gỡ ứng dụng khỏi `K8s`, chúng ta sử dụng lệnh `uninstall` để gỡ `release` khỏi `K8s`. ```bash helm uninstall ``` Để xem danh sách các `release` đã cài đặt trên `K8s`, chúng ta sử dụng lệnh sau: ```bash helm list ``` # Các câu lệnh cơ bản trong Kubernetes 1. `kubectl config get-contexts`: Hiển thị danh sách các `context` trong `kubeconfig`. 2. `kubectl config use-context `: Chuyển đổi giữa các `context` trong `kubeconfig`. 3. `kubectl get nodes`: Hiển thị danh sách các `node` trong `cluster`. 4. `kubectl get deployments`: Hiển thị danh sách các `deployment` trong `cluster`. 5. `kubectl get pods`: Hiển thị danh sách các `pod` trong `cluster`. 6. `kubectl get services`: Hiển thị danh sách các `service` trong `cluster`. 7. `kubectl get namespaces`: Hiển thị danh sách các `namespace` trong `cluster`. 8. `kubectl get replicaset`: Hiển thị danh sách các `replicaset`(bộ nhân bản) trong `cluster`. 9. `kubectl apply -f `: Áp dụng, chạy cấu hình từ file `yaml` vào `cluster`. 10. `kubectl delete -n default --now --cascade=background`: Xóa `các dịch vụ tên cấu hình như deployment, configmap,...` có tên `` trong `namespace` mặc định `default`. 11. `kubectl get events --sort-by=.metadata.creationTimestamp`: Hiển thị các sự kiện trong `cluster` được sắp xếp theo thời gian tạo. 12. `kubectl scale deployment --replicas=`: Scale `deployment` có tên `` lên với số lượng `replicas` là ``. Cách này giúp tăng hoặc giảm số lượng `replicas` của `deployment` một cách nhanh chóng. Thay vì phải sửa file `yaml` và `apply` lại, ta có thể sử dụng câu lệnh này để thay đổi số lượng `replicas` của `deployment`. 13. `kubectl exec -it -- /bin/bash`: Truy cập vào `container` của `pod` có tên `` và thực thi lệnh `/bin/bash`. Cách này giúp truy cập vào `container` của `pod` một cách nhanh chóng và dễ dàng. 14. `kubectl logs `: Hiển thị `logs` của `pod` có tên ``. Cách này giúp hiển thị `logs` của `pod` một cách nhanh chóng và dễ dàng. 15. `kubectl describe pod `: Hiển thị thông tin chi tiết của `pod` có tên ``. Cách này giúp hiển thị thông tin chi tiết của `pod` một cách nhanh chóng và dễ dàng. 16. `kubectl set image deployment = --record`: Thay đổi `image` của `container` trong `deployment` có tên `` thành `image` mới là ``. Cách này giúp thay đổi `image` của `container` trong `deployment` một cách nhanh chóng và dễ dàng. 17. `kubectl get configmaps`: Hiển thị danh sách các `configmaps` trong `cluster`. 18. `kubectl get secrets`: Hiển thị danh sách các `secrets` trong `cluster`. 19. `kubectl rollout history deployment `: Hiển thị lịch sử `rollout` của `deployment` có tên ``. Cách này giúp hiển thị lịch sử `rollout` của `deployment` một cách nhanh chóng và dễ dàng. 20. `kubectl rollout undo deployment --to-revision=`: Rollback `deployment` có tên `` về phiên bản `revision` có số ``. Cách này giúp rollback `deployment` về phiên bản trước đó một cách nhanh chóng và dễ dàng. # Các câu lệnh cơ bản trong Helm 1. `helm repo add `: Thêm `repository` có tên `` và `url` là `` vào `Helm`. 2. `helm repo list`: Hiển thị danh sách các `repository` trong `Helm`. 3. `helm repo update`: Cập nhật danh sách các `repository` trong `Helm`. 4. `helm search repo `: Tìm kiếm `repository` có tên `` trong `Helm`. 5. `helm install `: Cài đặt `chart` có tên `` từ `repository` vào `Helm`. Và đẩy lên `K8s`. 6. `helm ls`: Hiển thị danh sách các `chart` đã cài đặt trong `Helm`. 7. `helm upgrade `: Nâng cấp `chart` có tên `` từ `repository` trong `Helm`. 8. `helm uninstall `: Gỡ cài đặt `chart` có tên `` từ `repository` trong `Helm`. Và gỡ cài đặt trên `K8s`. 9. `helm show values `: Hiển thị các giá trị mặc định của `chart` có tên `` trong `Helm`. 10. `helm show chart `: Hiển thị thông tin chi tiết của `chart` có tên `` trong `Helm`. 11. `helm show readme `: Hiển thị `readme` của `chart` có tên `` trong `Helm`. 12. `helm show all `: Hiển thị tất cả thông tin của `chart` có tên `` trong `Helm`. 13. `helm rollback `: Rollback `chart` có tên `` về phiên bản `revision` có số `` trong `Helm`. 14. `helm history `: Hiển thị lịch sử `chart` có tên `` trong `Helm`. 15. `helm get values `: Hiển thị các giá trị của `chart` có tên `` trong `Helm`. 16. `helm get manifest `: Hiển thị `manifest` của `chart` có tên `` trong `Helm`. 17. `helm get all `: Hiển thị tất cả thông tin của `chart` có tên `` trong `Helm`. 18. `helm create `: Tạo `chart` mới có tên `` trong `Helm`. 19. `helm dependencies build`: Xây dựng các `dependencies` của `chart` trong `Helm`. 20. `helm template `: Hiển thị `manifest` của `chart` trong `Helm`.

Kubernetes: Sử dụng Kubernetes để triển khai hệ thống Microservices