Kubernetes: Setup project ASP.NET core trên minikube - Day 4

Trong bài viết này, chúng ta sẽ triển khai 1 ứng dụng ASP.NET trên minikube từ đầu đến cuối.

Trước khi bắt đầu, bạn cần tìm hiểu về Docker, cách cài đặt minikube trên máy cá nhân trước. Sau đó tìm hiểu về Images, Containers, Pods, Services.

Docker và Minikube

Docker là một dự án mã nguồn mở giúp tự động triển khai các ứng dụng Linux và Windows vào trong các container ảo hóa.

Sự khác biệt cơ bản là Docker chỉ quản lý 1 node (nhiều container trong 1 node) duy nhất trong khi Kubernetes quản lý 1 cụm các node.

Pods là một khái niệm trừu tượng của Kubernetes, đại diện cho một nhóm gồm một hoặc nhiều ứng dụng containers

Service được xác định dựa trên label, đại diện cho một entry point để truy cập vào ứng dụng.
Minikube thực sự tạo ra một Máy ảo (VM) bên trong docker và trong máy ảo này, nó chạy các vùng chứa docker

Để khởi động minikube, bạn gõ:

minikube start --vm-driver=hyperv

Trường hợp bạn sử dụng driver khác, tham khảo tại đây: https://minikube.sigs.k8s.io/docs/drivers/

Pod in Kubernetes

Pod là đơn vị nhỏ nhất trong Kubernetes. Một Pod có thể chứa 1 hoặc nhiều containers

Trong phạm vi bài viết này, chúng ta chỉ deploy 1 container duy nhất.

Tạo ứng dụng ASP.NET Core

Các bạn có thể tại source code: https://github.com/anbinhtrong/minikube-asp-net-core/releases/tag/v1.0
Mình chỉ tạo 1 ứng dụng ASP.NET Core đơn giản, sau đó thêm Dockerfile để tạo image và đưa lên Docker hub.

docker pull anbinhtrong/hostingmvc:latest
# syntax=docker/dockerfile:1

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env

WORKDIR /app


#Copy csproj and restore as distinct layers

COPY *.csproj ./

RUN dotnet restore


#Copy everything else and build

COPY . ./

RUN dotnet publish -c Release -o out


#Build runtime image

FROM mcr.microsoft.com/dotnet/aspnet:6.0

WORKDIR /app

COPY --from=build-env /app/out .

ENTRYPOINT ["dotnet", "HostingMvc.dll"]

Cấu hình Pod và Service

Trong Docker compose, chúng ta sẽ build Docker images dựa trên Dockerfile.

Ngược lại, Kubernetes sẽ được build trước khi cấu hình.

VD: 

image: anbinhtrong/hostingmvc

Trước tiên, chúng ta vẽ sơ đồ ASP.NET Core với port output 80. 

Trường hợp bạn sử dụng Angular sẽ là port 3000.

Service NodePort sẽ nói chuyện với Pod thông qua Port 3050. Để output ra ngoài, thì dữ liệu sẽ ra Port 31515.
Bạn cần lưu ý các Port để cấu hình cho chính xác

Label và Selector

Label là các cặp giá trị key:value được gán vào một đối tượng trong Kubernetes như Pod, được sử dụng để chúng ta có thể định danh một đối tượng Kubernetes một cách nhanh chóng. Còn Selector thì được dùng để filter một tập hợp các đối tượng Kubernetes thoả mãn các điều kiện nào đó

Cú pháp:

metadata:
  labels:
    <key1>: <value1>
    <key2>: <value2>

Trong đó key1:value1, key2:value2 là các cặp giá trị mà chúng ta muốn gán cho đối tượng Kubernetes. VD:

labels:
  component: web

Object Type và API Version

Giả sử bạn có file Pod.yml như sau:

apiVersion: v1
kind: Pod                                            # 1
metadata:
  name: client                                       # 2
spec:                                                # 3
  containers:
    - image: client                                  # 4
      name: client                                   # 5
      ports:
        - containerPort: 80                          # 6

Khi chúng ta liệt kê resource, một trong những điều quan trọng đầu tiên mà chúng ta cần chỉ định cho tài nguyên là apiVersion.. Định dạng của apiVersion là api_group / version.

• Kind: Đánh dấu xem tài nguyên Kubernetes mà ta sẽ tạo với manifest file này. Bao gồm các giá trị: Pod, Service, StatefulSet, ReplicateController 
• Name: tên của resource, ta cũng gọi nó là frontend luôn cho tiện. 
• Spec: Object mà sẽ định nghĩa trạng thái cho resource. Thứ quan trọng nhất ở đây là danh sách các container trong pod. Image: image dùng để bắt đầu trong pod. 
• Name: Tên của container trong pod. 
• Container Port: Cổng mà container đó gắn với. 

Dưới đây là cách đây API version mà mình tìm được, thấy khá hay:

Kind	apiversion
ComponentStatus	v1
ComponentStatus	v1
Endpoints	v1
Event	v1
LimitRange	v1
Namespace	v1
Node	v1
PersistentVolumeClaim	v1
PersistentVolume	v1
Pod	v1
PodTemplate	v1
ReplicationController	v1
ResourceQuota	v1
Secret	v1
ServiceAccount	v1
Service	v1
ControllerRevision	apps/v1
StatefulSet	apps/v1
CronJob	batch/v1beta1
DaemonSet	extensions/v1beta1
Deployment	extensions/v1beta1
HorizontalPodAutoscaler	autoscaling/v1
Ingress	extensions/v1beta1
Job	batch/v1
NetworkPolicy	extensions/v1beta1
CertificateSigningRequest	certificates.k8s.io/v1beta1
ClusterRole	rbac.authorization.k8s.io/v1
ClusterRoleBinding	rbac.authorization.k8s.io/v1
Role	rbac.authorization.k8s.io/v1
RoleBinding	rbac.authorization.k8s.io/v1
ReplicaSet	extensions/v1beta1
PodSecurityPolicy	extensions/v1beta1
PodDisruptionBudget	policy/v1beta1

What does each apiVersion mean?

alpha
API versions with ‘alpha’ in their name are early candidates for new functionality coming into Kubernetes. This is not stable for use. These may contain bugs.

beta
‘beta’ in the API version name means that testing has progressed past alpha level and that the feature will eventually be included in Kubernetes. Although the way it works might change, and the way objects are defined may change completely, the feature itself is highly likely to make it into Kubernetes in some form.

stable
They are safe to use. These do not contain ‘alpha’ or ‘beta’ in their name.

v1
v1 version was the first stable version release of the Kubernetes API. It contains many core objects in Kubernetes.

apps/v1
apps is the most common API group in Kubernetes, with many core objects. It includes various functions like running applications on Kubernetes, like Deployments, RollingUpdates, and ReplicaSets.

autoscaling/v1
This API version autoscaling/v1 allows pods to be autoscaled based on different resource usage metrics. Kubernetes autoscaling helps optimize resource usage and costs by automatically scaling a cluster up and down. Autoscaling is totally dependent on demand.

This stable version includes support for only CPU scaling, but future alpha and beta versions will allow you to scale based on memory usage and custom metrics.

batch/v1
The batch API group contains objects related to batch processing and job-like tasks. This apiVersion is the first stable release of these API objects.

batch/v1beta1
A beta version release with new functionality for batch objects in Kubernetes, including CronJobs that like you can set a specific time and the job will execute at that time or periodicity.

certificates.k8s.io/v1beta1
This API version plays an important role for validate network certificates for secure communication in your cluster.

extensions/v1beta1
This version of the API includes many new and commonly used features of Kubernetes. Deployments, DaemonSets, ReplicaSets, and Ingresses all received significant changes in this release. Using extensions/v1beta1 is becoming deprecated—try to use the specific API group where possible, depending on your Kubernetes cluster version.

policy/v1beta1
Basically, this apiVersion is used to add the new rules around pod security and the ability to set a pod disruption budget.

rbac.authorization.k8s.io/v1
This apiVersion is used for access control. It plays an important role to secure our cluster. It includes more functionality for Kubernetes role-based access control.

Sử dụng Minikube để deploy trên Localhost

kubectl apply quản lý các ứng dụng thông qua các tệp định nghĩa tài nguyên Kubernetes. 

Các tệp định nghĩa tài nguyên trong Kubernetes được gọi là các manifest file và có thể được viết bằng yaml hoặc json. Nó tạo và cập nhật các tài nguyên trong một cluster thông qua việc chạy kubectl apply.

kubectl apply –f <filename>

apply: Thay đổi thiết lập của 1 cluster
-f: chỉ ra apply config bằng 1 file
<filename>: đường dẫn tới file config

Quay trở lại ứng dụng ASP.NET Core, chúng ta sẽ cấu hình 2 file cho pod và service

Định nghĩa file pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: client-pod
  labels:
    component: web
spec:
  containers:
    - image: anbinhtrong/hostingmvc
      name: client
      imagePullPolicy: Always
      ports:
        - containerPort: 80

Định nghĩa file service.yaml

apiVersion: v1
kind: Service
metadata:
    name: client-node-port
spec:
    type: NodePort
    ports:
        - port: 3050
          targetPort: 80
          nodePort: 31515
    selector:
        component: web

Chúng ta sẽ dùng câu lệnh kubectl để apply theo thứ tự từ pod.yaml tới service.yaml. Di chuyển tới thư mục chứa pod.yml và service.yml, thực hiện lệnh:

kubectl apply –f pod.yml
kubectl apply –f service.yml

Kết quả

$ kubectl get services
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
client-node-port   NodePort    10.100.84.108   <none>        3050:31515/TCP   11s
kubernetes         ClusterIP   10.96.0.1       <none>        443/TCP          9m36s

Ý nghĩa của từng cột trong kết quả của lệnh kubectl get services

Cột	Ý nghĩa
NAME	Tên của Service
TYPE	Loại của Service
CLUSTER-IP	Địa chỉ IP nội bộ của Service
EXTERNAL-IP	Địa chỉ IP công cộng của Service (nếu có)
PORT(S)	Cổng và giao thức của Service
AGE	Thời gian Service đã tồn tại

Giải thích

• NAME: Tên của Service là một tên duy nhất để xác định Service.
• TYPE: Loại của Service xác định cách Service sẽ triển khai các Pod của nó. Có hai loại Service chính:
• ClusterIP: Service chỉ có thể được truy cập từ bên trong cụm Kubernetes.
• NodePort: Service có thể được truy cập từ bên ngoài cụm Kubernetes thông qua cổng NodePort.
• LoadBalancer: Service được triển khai trên một bộ cân bằng tải và có thể được truy cập từ bên ngoài cụm Kubernetes thông qua địa chỉ IP công cộng.
• CLUSTER-IP: Địa chỉ IP nội bộ của Service là địa chỉ IP mà các Pod trong cụm Kubernetes có thể sử dụng để truy cập Service.
• EXTERNAL-IP: Địa chỉ IP công cộng của Service là địa chỉ IP mà các ứng dụng bên ngoài cụm Kubernetes có thể sử dụng để truy cập Service.
• PORT(S): Cổng và giao thức của Service xác định cổng mà các Pod trong cụm Kubernetes và các ứng dụng bên ngoài cụm Kubernetes có thể sử dụng để truy cập Service.
• AGE: Thời gian Service đã tồn tại là thời gian kể từ khi Service được tạo.

Trong kết quả của lệnh kubectl get services, Service client-node-port là một Service loại NodePort có địa chỉ IP nội bộ là 10.100.84.108 và cổng 3050. Service này có thể được truy cập từ bên ngoài cụm Kubernetes thông qua cổng NodePort 31515.

Kiểm tra kết quả

Trước tiên chúng ta cần tìm địa chỉ ip của minikube, sau đó kết hợp với Port 31515 để truy cập vào trang web

$ minikube ip
192.168.49.2
$ curl http://192.168.49.2:31515
<!DOCTYPE html>
<html lang="en">
<head>
...

Xóa tài nguyên trong Kubernetes

Cú pháp

kubectl delete ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

Ví dụ

# Delete a pod using the type and name specified in pod.json.
kubectl delete -f ./pod.json

# Delete a pod based on the type and name in the JSON passed into stdin.
cat pod.json | kubectl delete -f -

# Delete pods and services with same names "baz" and "foo"
kubectl delete pod,service baz foo

# Delete pods and services with label name=myLabel.
kubectl delete pods,services -l name=myLabel

# Delete a pod with UID 1234-56-7890-234234-456456.
kubectl delete pod 1234-56-7890-234234-456456

# Delete all pods
kubectl delete pods --all

Trường hợp bạn sử dụng minikube, xóa tất cả:

minikube delete --all

Tham khảo

https://medium.com/bb-tutorials-and-thoughts/how-to-run-net-core-app-on-minikube-5bf70f4e7506
https://www.yogihosting.com/deploy-aspnet-core-app-kubernetes/
https://viblo.asia/p/tim-hieu-ve-kubernetes-Ljy5VWy9Kra

Chúc các bạn thành công!