Các loại tài nguyên Kind trong tệp YAML của Kubernetes

Trong các tệp YAML của Kubernetes, nội dung thường được phân chia theo các loại tài nguyên khác nhau (thường được ngăn cách bằng ký hiệu ---)

Các loại tài nguyên phổ biến

  1. Endpoints

Endpoints cho phép kết nối các dịch vụ bên ngoài vào hệ thống Kubernetes (có thể hiểu là tham chiếu tài nguyên bên ngoài, ví dụ như kết nối một cơ sở dữ liệu MySQL bên ngoài vào Kubernetes)

  1. Service

Triển khai một địa chỉ IP ảo nội bộ, cho phép các thành phần khác kết nối. (Có thể hiểu đơn giản là ánh xạ cổng trong K8S, ví dụ cổng 3444 bên ngoài ánh xạ đến cổng 80 trong ứng dụng pod)

  1. Secrets

Dùng để lưu trữ và quản lý các dữ liệu nhạy cảm như mật khẩu, token, khóa bí mật và thông tin quan trọng khác. (Có thể hiểu tương tự như khóa SSH)

  1. Deployment

Triển khai một Pod, bên trong chỉ có thể kết nối với service, không thể kết nối trực tiếp với nhau. (Có thể hiểu đơn giản là công cụ triển khai ứng dụng pod, ngay cả khi ứng dụng bị lỗi vẫn có thể tự động khởi động lại Pod, nhưng chỉ có thể kết nối với dịch vụ service)

Dưới đây là phần giải thích chi tiết từng loại tài nguyên:

I. Endpoints

Hãy xem xét một yêu cầu cụ thể: Tôi có một cơ sở dữ liệu MySQL bên ngoài, không sử dụng triển khai trên Kubernetes. Nhưng hiện tại ứng dụng của tôi muốn sử dụng nó. Vậy làm thế nào để sử dụng nó?畢竟 hầu hết các pod trong k8s chỉ có thể kết nối thông qua service. Lúc này Endpoints sẽ phát huy tác dụng, nó có thể kết nối các dịch vụ bên ngoài vào hệ thống k8s, ví dụ:

apiVersion: v1
kind: Endpoints
metadata:
  name: external-db-reference
subsets:
  - addresses:
      - ip: 192.168.15.155
    ports:
      - port: 3306
        protocol: TCP
        name: database-port

---
apiVersion: v1
kind: Service
metadata:
  name: external-db-reference
spec:
  ports:
    - port: 3306
      targetPort: 3306
      protocol: TCP
      name: database-port

(1) Trước tiên chúng ta thấy rằng chúng ta đã định nghĩa Endpoints có tên external-db-reference, đồng thời cấu hình IP đại diện và cổng dịch vụ cho external-db-reference. (2) Sau đó nhìn sang phần tiếp theo, được phân cách bởi --- là loại Service khác, định nghĩa một Service có tên external-db-reference, đồng thời cấu hình ánh xạ cổng nội bộ đến cổng của Pod với port: 3306 và cổng được phơi bày bên ngoài targetPort: 3306

Tóm lại: Thông qua việc cấu hình Endpoints và Service, Endpoints kết nối cổng của k8s đến cổng MySQL bên ngoài, trong khi Service ánh xạ cổng nội bộ trong k8s đến cổng k8s, qua đó hoàn thành việc truy cập dịch vụ bên ngoài từ ứng dụng pod.

II. Service

Hãy xem xét một yêu cầu: Chúng ta đã khởi động một ứng dụng pod trong K8S và bên trong đang chạy cổng 8848 cho giao diện người dùng. Vậy làm thế nào để truy cập cổng 8848 của ứng dụng pod này từ bên ngoài? Lúc này cần định nghĩa loại Service, để ánh xạ cổng 8848 của ứng dụng pod đến cổng đặc biệt trong K8S, ứng dụng bên ngoài chỉ cần truy cập cổng đặc biệt của K8S là có thể truy cập giao diện người dùng. Service triển khai một IP ảo nội bộ, cho phép các deployment khác kết nối.

apiVersion: v1
kind: Service
metadata:
  name: web-application-service
spec:
  type: NodePort
  ports:
  - port: 8848
    nodePort: 38022
  selector:
    app: web-application

Trước tiên chúng ta thấy rằng đã định nghĩa loại Service có tên web-application-service, nhiệm vụ của nó là ánh xạ cổng port: 8848 đến cổng nodePort: 38022 được phơi bày bên ngoài, và ứng dụng được quản lý tương ứng là web-application Nói cách khác, ánh xạ cổng 8848 trong ứng dụng pod có tên web-application đến cổng 38022 được phơi bày bên ngoài, chỉ cần dịch vụ bên ngoài truy cập IP máy chủ:38022, có thể truy cập cổng 8848 của ứng dụng web-application trong k8s

Ví dụ Service hai

apiVersion: v1
kind: Service
metadata: 
    name: production-database
    namespace: staging
spec:
    ports:
    - port: 3306

Lúc này production-database.staging sẽ là IP ảo của cơ sở dữ liệu, các thành phần khác có thể cấu hình trường này để kết nối đến cơ sở dữ liệu. Ví dụ

"java","-Dspring.datasource.url=jdbc:mysql://production-database.staging:3306/configuration", "-jar", "application.jar"

III. Secrets

Loại này khá thú vị, chủ yếu được sử dụng dưới dạng khóa bí mật. (Có lẽ là không muốn lưu trữ rõ ràng thông tin tài khoản mật khẩu, nhưng phần lớn mã hóa đều là mã hóa Base64. Vì vậy, tôi nghĩ nó giống như phòng ngừa người tốt chứ không phòng người xấu)

Secret có ba loại: (1) Opaque: Định dạng Secret mã hóa base64, dùng để lưu trữ mật khẩu, khóa bí mật; nhưng dữ liệu cũng có thể được giải mã bằng base64 --decode để lấy dữ liệu gốc, nên tính bảo mật rất yếu. (2) Service Account: Dùng để truy cập API của Kubernetes, được Kubernetes tạo tự động và tự động gắn vào thư mục /run/secrets/kubernetes.io/serviceaccount của Pod. (3) kubernetes.io/dockerconfigjson: Dùng để lưu trữ thông tin xác thực registry docker riêng tư.

IV. Deployment

Hãy xem xét yêu cầu sau: Chúng tôi muốn triển khai một ứng dụng trên k8s, nếu ứng dụng bị lỗi thì vẫn có thể khởi động lại. Nếu chỉ tạo một loại pod thì chưa đủ, vì khi ứng dụng pod bị lỗi, nó sẽ không khởi động lại. Nếu tạo một loại Deployment, có thể tạo và quản lý ứng dụng pod, khi gặp sự cố sẽ được khởi động lại.

Ví dụ:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-controller
spec:
  replicas: 2
  selector:
    matchLabels:
      app: managed-application
  template:
    metadata:
      labels:
        app: managed-application
    spec:
      imagePullSecrets:
      - name: registry-auth-secret
      containers:
      - name: main-container
        image: container.registry.example:5555/applications/sample-app:2.0
        ports:
          - containerPort: 8080
        imagePullPolicy: Always
        resources:
          limits:
            cpu: "2"
            memory: "800Mi"
          requests:
            cpu: "1"
            memory: "400Mi"

Nội dung trên khá nhiều, hãy giải thích từng phần:

(1) Trước tiên, chúng ta định nghĩa Deployment có tên application-controller, và nhãn của ứng dụng mà Deployment quản lý là managed-application, số lượng bản sao là 2. (2) Sau đó trong định nghĩa dữ liệu, định nghĩa một mẫu nghiệp vụ template. Có thể thấy rằng trong mẫu nghiệp vụ định nghĩa một ứng dụng pod có tên managed-application. (3) Đồng thời mẫu nghiệp vụ còn định nghĩa tên container cho ứng dụng managed-application, cũng có tên là main-container, và hình ảnh container được kéo về từ registry.container.example:5555/applications/sample-app:2.0. Lúc này sẽ có người hỏi, nếu địa chỉ kéo hình ảnh không công khai và cần mật khẩu thì phải làm sao? Còn nhớ loại Secrets kubernetes.io/dockerconfigjson đã đề cập ở trên không? Thứ này chính là dùng để lấy hình ảnh với xác thực khóa bí mật, chỉ cần cấu hình một khóa bí mật có tên registry-auth-secret đã tạo trước trong imagePullSecrets là có thể kéo hình ảnh (4) Là cấu hình một số cổng cho pod là 8080, phương thức kéo hình ảnh imagePullPolicy là Always luôn kéo mới (5) Cấu hình này là thiết lập yêu cầu CPU và bộ nhớ bình thường cho pod, cũng như giới hạn tối đa CPU và bộ nhớ. Tất nhiên bạn không thiết lập cũng không sao. Trong cấu hình này, tôi đặt yêu cầu CPU bình thường cho pod là 1 (một lõi) và bộ nhớ là 400M, giới hạn tối đa CPU là 2 lõi và bộ nhớ là 800M

Ghi chú:

  1. Các tham số chi tiết cho imagePullPolicy?
  • Always: Luôn kéo mới
  • IfNotPresent: Giá trị mặc định, nếu có hình ảnh cục bộ thì sử dụng hình ảnh cục bộ, không kéo mới
  • Never: Chỉ sử dụng hình ảnh cục bộ, không bao giờ kéo mới

Thẻ: Kubernetes yaml containers DevOps Microservices

Đăng vào ngày 28 tháng 5 lúc 03:40

Thẻ Phổ Biến

©2026 Thành phố Cuồng loạn