Service trong Kubernetes là gì? Hướng dẫn phân loại và cấu hình từ A-Z

Trong thế giới Kubernetes, các Pods có một đặc tính là "vô thường". Chúng được sinh ra, chết đi và được thay thế liên tục. Mỗi lần như vậy, địa chỉ IP của Pod sẽ thay đổi. Điều này đặt ra một bài toán hóc búa: Làm sao để A có thể gọi tới B nếu địa chỉ IP của B thay đổi liên tục? Câu trả lời chính là Service trong Kubernetes. Cùng Viettel IDC tìm hiểu nhé.

Service trong Kubernetes là gì?

Trong Kubernetes, Service là một thực thể quan trọng đại diện cho một nhóm các Pods đang chạy một ứng dụng hoặc một thành phần chức năng cụ thể. Service nắm giữ các chính sách truy cập mạng và chịu trách nhiệm thực thi các chính sách này đối với mọi yêu cầu gửi đến.

Hiểu một cách đơn giản, nếu Pods là những "công nhân" trực tiếp xử lý công việc, thì Service trong Kubernetes chính là "người quản lý" điều phối luồng giao thông, đảm bảo yêu cầu từ khách hàng luôn đến được đúng người, đúng chỗ.

Sự ra đời của Service trong Kubernetes xuất phát từ chính đặc tính cơ bản nhất của Pod: vòng đời ngắn và không ổn định. Trong Kubernetes, Pods có thể bị thay thế bất cứ lúc nào (do mở rộng quy mô, lỗi phần cứng, hoặc cập nhật phần mềm). Mặc dù Kubernetes đảm bảo tính sẵn sàng của ứng dụng thông qua các bản sao, nhưng nó không đảm bảo sự tồn tại vĩnh viễn của một Pod cá nhân cụ thể.

Điều này dẫn đến một thách thức lớn về kết nối mạng:

- Mỗi khi một Pod được tái tạo, nó sẽ nhận một địa chỉ IP mới hoàn toàn.

- Nếu một ứng dụng cố gắng kết nối trực tiếp đến địa chỉ IP của một Pod khác, kết nối sẽ bị ngắt ngay khi Pod đó bị thay thế.

- Các Pods cần giao tiếp với nhau không thể dựa vào địa chỉ IP đơn lẻ của các Pod bên dưới.

Để giải quyết vấn đề trên, Service trong Kubernetes đóng vai trò là cầu nối trung gian:

- ClusterIP: Khi một Service được khởi tạo, nó sẽ được gán một địa chỉ IP ảo, gọi là ClusterIP. Địa chỉ này là cố định và sẽ tồn tại xuyên suốt cho đến khi Service bị xóa bỏ một cách chủ động.

- Cơ chế chuyển tiếp: Thay vì kết nối trực tiếp đến Pod, các thành phần ứng dụng sẽ kết nối đến địa chỉ của Service. Service trong Kubernetes sau đó sẽ hoạt động như một bộ điều hướng, chuyển tiếp yêu cầu đó đến một Pod phù hợp, đang hoạt động khỏe mạnh (healthy) trong nhóm mà nó quản lý.

Nhờ cơ chế này, Service trong Kubernetes hoạt động như một điểm cuối đáng tin cậy, giúp tách biệt sự phụ thuộc giữa các thành phần giao tiếp.

Ngoài việc sử dụng Service trong Kubernetes, đối với các ứng dụng được xây dựng đặc thù cho nền tảng này (Kubernetes native applications), có một phương án thay thế là thực hiện yêu cầu trực tiếp thông qua Kubernetes API Server. API Server có khả năng tự động hiển thị và duy trì các điểm cuối cho các Pods đang chạy. Tuy nhiên, cách tiếp cận này thường phức tạp hơn và chỉ dành cho các trường hợp sử dụng nâng cao, trong khi Service vẫn là giải pháp tiêu chuẩn và hiệu quả nhất cho hầu hết các mô hình ứng dụng hiện nay.

Cấu trúc của Service trong Kubernetes

Về mặt kỹ thuật, một Service trong Kubernetes hoạt động như một thực thể trừu tượng, liên kết một nhóm các Pods lại với nhau thông qua một tên gọi định danh và một địa chỉ IP cố định. Cơ chế này chính là chìa khóa giúp các Pods có thể tự khám phá và định tuyến yêu cầu lẫn nhau một cách chính xác trong môi trường phân tán.

Để ghép nối chính xác các ứng dụng, Service trong Kubernetes sử dụng cặp cơ chế Labels và Selectors để lọc và định vị đúng đối tượng. Một cấu hình tiêu chuẩn của Service trong Kubernetes thường bao gồm các thành phần chính sau:

- Label Selector: Đây là thành phần quan trọng nhất, đóng vai trò như một bộ lọc để xác định danh sách các Pods đích mà Service sẽ điều hướng lưu lượng truy cập tới.

- ClusterIP: Một địa chỉ IP ảo nội bộ được cấp phát cho Service, đóng vai trò là điểm tiếp nhận kết nối ổn định.

- Port Number: Số cổng mà Service sẽ lắng nghe các yêu cầu gửi đến.

- TargetPort: Tùy chọn ánh xạ cổng, xác định cổng cụ thể trên Container mà lưu lượng sẽ được chuyển tiếp vào (Ví dụ: Service nghe ở cổng 80 nhưng chuyển vào cổng 8080 của Container).

Sơ đồ minh họa cấu trúc của Service

Hướng dẫn tạo Service trong Kubernetes

Cách tiêu chuẩn và chuyên nghiệp nhất để cấu hình một Service trong Kubernetes là sử dụng YAML Manifest. File này hoạt động như bản thiết kế, định nghĩa cách Service vận hành và kết nối với các Pods.

Cấu trúc file YAML cơ bản

apiVersion: v1

kind: Service

metadata:

  name: my-service  

spec:

  selector:

    app: nginx      

  ports:

    - protocol: TCP

      port: 80      

      targetPort: 8080 

Để làm chủ Service trong Kubernetes, bạn cần hiểu rõ 3 thành phần cốt lõi trong Manifest:

- metadata:name: Đây là tên logic của Service. Quan trọng hơn, nó sẽ trở thành tên miền DNS nội bộ của Service. Các ứng dụng khác trong Cluster có thể gọi tới Service này đơn giản bằng cái tên my-service.

- spec:selector: Đây là "bộ lọc" xác định thành viên. Service sẽ tìm kiếm và định tuyến lưu lượng truy cập tới tất cả các Pods đang mang nhãn (label) khớp với khai báo này (ở ví dụ trên là app: nginx).-

- spec:ports: Định nghĩa cổng giao tiếp.

Lệnh khởi tạo: Để triển khai đối tượng Service này vào Cluster, bạn sử dụng lệnh kubectl quen thuộc: kubectl apply -f /path/to/service-manifest.yaml

Các loại Service trong Kubernetes

1. ClusterIP

ClusterIP là loại Service trong Kubernetes mặc định. Nó cấp phát một địa chỉ IP nội bộ (Cluster-Internal IP) cho Service. Chỉ các đối tượng nằm bên trong Cluster mới có thể truy cập được Service này.

Ví dụ Manifest:

apiVersion: v1

kind: Service

metadata:

  name: my-clusterip-service

spec:

  type: ClusterIP

  clusterIP: 10.10.5.10 (Tùy chọn) Có thể set IP cụ thể trong dải IP của Cluster

  ports:

    - name: http

      protocol: TCP

      port: 80

      targetPort: 8080

2. NodePort 

NodePort là phiên bản mở rộng của ClusterIP. Nó cho phép truy cập Service từ bên ngoài Cluster bằng cách mở một cổng cụ thể trên tất cả các Node (máy chủ). Khi bạn truy cập vào IP_của_bất_kỳ_Node_nào:NodePort, lưu lượng sẽ được chuyển tới ClusterIP và sau đó tới Pod.

Lưu ý:

- Dải cổng mặc định: 30000 - 32767.

- Thành phần kube-proxy trên mỗi Node chịu trách nhiệm lắng nghe và chuyển tiếp gói tin (NAT).

- Thường dùng để cấu hình Load Balancer thủ công hoặc cho môi trường Dev/Test.

Ví dụ Manifest:

apiVersion: v1

kind: Service

metadata:

  name: my-nodeport-service

spec:

  type: NodePort

  selector:

    app: nginx

  ports:

    - name: http

      protocol: TCP

      port: 80

      targetPort: 8080

      nodePort: 30000 (Tùy chọn) Cố định cổng mở ra ngoài

3. LoadBalancer

LoadBalancer là loại Service trong Kubernetes phổ biến nhất khi vận hành trên các nền tảng Cloud (như Viettel IDC, AWS, GCP). Nó xây dựng dựa trên nền tảng của NodePort nhưng bổ sung khả năng tích hợp với bộ cân bằng tải (Load Balancer) của nhà cung cấp Cloud.

Cơ chế của LoadBalancer là tự động yêu cầu nhà cung cấp Cloud cấp phát một Public IP. Lưu lượng từ Internet sẽ đi vào External Load Balancer -> NodePort -> ClusterIP -> Pod. Nó giúp phân phối tải hiệu quả, có địa chỉ IP công cộng ổn định cho người dùng cuối.

Ví dụ Manifest:

apiVersion: v1

kind: Service

metadata:

  name: my-loadbalancer-service

spec:

  type: LoadBalancer

  clusterIP: 10.0.160.135

  loadBalancerIP: 168.196.90.10 (Yêu cầu Cloud Provider cấp IP cụ thể này (nếu hỗ trợ))

  selector:

    app: nginx

  ports:

    - name: http

      protocol: TCP

      port: 80

      targetPort: 8080

4. ExternalName 

Loại Service ExternalName này khá đặc biệt vì nó không dùng Selectors và không định nghĩa bất kỳ cổng hay IP nào. Thay vào đó, nó ánh xạ Service tới một tên miền DNS bên ngoài (thông qua bản ghi CNAME).

Ứng dụng:

- Kết nối Pod tới một Database nằm ngoài Kubernetes Cluster (ví dụ: my.database.domain.com).

- Cho phép Pod ở Namespace này gọi Service ở Namespace khác như một dịch vụ cục bộ.

Ví dụ Manifest:

apiVersion: v1

kind: Service

metadata:

  name: my-externalname-service

spec:

  type: ExternalName

  externalName: my.database.domain.com (Tên miền đích muốn trỏ tới)

Kết luận

Service trong Kubernetes không chỉ đơn thuần là một công cụ định danh, mà chính là xương sống duy trì sự sống còn cho mạng lưới giao tiếp bên trong Cluster. Nó giải quyết triệt để bài toán vô thường của Pods, đóng vai trò như một bộ điều hướng thông minh, đảm bảo mọi yêu cầu kết nối từ nội bộ hay Internet đều đến đúng đích, bất kể sự thay đổi liên tục của các Pods phía sau.

Tuy nhiên, từ lý thuyết đến thực tế vận hành là một khoảng cách lớn. Để đơn giản hóa quy trình này và tập trung tối đa nguồn lực vào phát triển ứng dụng lõi, doanh nghiệp có thể lựa chọn giải pháp Viettel Open Kubernetes Service (vOKS). Được xây dựng trên nền tảng Cloud mạnh mẽ của Viettel IDC, vOKS cung cấp khả năng tích hợp sẵn Load Balancer chuẩn quốc tế, giúp hệ thống của bạn tự động hóa việc phân phối tải và đảm bảo tính sẵn sàng cao chỉ sau vài cú click chuột.

Khám phá ngay hạ tầng Kubernetes mạnh mẽ và ổn định tại: https://viettelidc.com.vn/viettel-kubernetes-service