[ad_1]
API Kubernetes là lộ trình của bạn để kiểm tra và quản lý các hoạt động của cụm của bạn. Bạn có thể sử dụng API bằng Kubectl CLI, các công cụ như curl
hoặc các thư viện tích hợp chính thức cho các ngôn ngữ lập trình phổ biến.
API cũng có sẵn cho các ứng dụng trong cụm của bạn. Kubernetes Pods tự động được cấp quyền truy cập vào API và có thể xác thực bằng tài khoản dịch vụ được cung cấp. Bạn thực hiện các tương tác bằng cách sử dụng các biến môi trường được chèn và tệp chứng chỉ để tạo kết nối từ ứng dụng khách mà bạn chọn.
Tại sao phải truy cập API Kubernetes trong Pods?
Có một số trường hợp sử dụng để truy cập API trong Pod. Kỹ thuật này cho phép các ứng dụng tự động kiểm tra môi trường của chúng, áp dụng các thay đổi của Kubernetes và thu thập các chỉ số mặt phẳng điều khiển để cung cấp thông tin chi tiết về hiệu suất.
Một số tổ chức phát triển công cụ của riêng họ xung quanh Kubernetes. Họ có thể triển khai một ứng dụng trong cụm đặc biệt sử dụng API để hiển thị chức năng bổ sung. Hoạt động từ bên trong cụm có thể an toàn hơn thực hiện lệnh gọi API từ tập lệnh bên ngoài vì bạn không cần phải mở môi trường của mình hoặc chia sẻ tài khoản dịch vụ và mã thông báo xác thực.
Sử dụng Thư viện ứng dụng API
Phương pháp dễ nhất và được đề xuất để truy cập API Kubernetes từ Pod là sử dụng thư viện máy khách. Các tùy chọn được hỗ trợ đầy đủ có sẵn cho C, .NET, Go, Haskell, Java, JavaScript, Perl, Python và Ruby. Có các giải pháp tương đương do cộng đồng duy trì cho hầu hết các ngôn ngữ lập trình phổ biến khác.
Các thư viện máy khách có hỗ trợ tích hợp để khám phá môi trường cụm mà chúng đang chạy. Mỗi triển khai cung cấp một hàm mà bạn có thể gọi sẽ định cấu hình thư viện để kết nối với máy chủ API chính xác.
Dưới đây là một ví dụ về cách liệt kê các Pod trong cụm của bạn trong một ứng dụng Python:
from kubernetes import client, config config.load_incluster_config() api = client.CoreV1Api() # Perform necessary API interactions # pods = api.list_pod_for_all_namespaces()
Cách tiếp cận này dễ làm việc và không yêu cầu cấu hình thủ công. Đôi khi bạn sẽ không thể sử dụng thư viện khách hàng. Trong những trường hợp đó, bạn vẫn có thể truy cập thủ công API bằng tài khoản dịch vụ mà Kubernetes cung cấp.
Thực hiện tương tác API thủ công
Để gọi API, bạn cần biết hai điều: tên máy chủ trong cụm mà nó được hiển thị và mã thông báo tài khoản dịch vụ sẽ xác thực Pod của bạn.
Tên máy chủ API luôn là kubernetes.default.svc
. Nhà cung cấp DNS Kubernetes sẽ giải quyết tên này cho máy chủ API của mặt phẳng điều khiển. Ngoài ra, bạn có thể sử dụng $KUBERNETES_SERVICE_HOST
biến môi trường để khám phá địa chỉ IP của máy chủ API:
$ echo $KUBERNETES_SERVICE_HOST 10.96.0.1
API chỉ khả dụng qua HTTPS. Bạn có thể tìm thấy tệp tổ chức phát hành chứng chỉ cho cụm của mình tại /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
trong Pod của bạn. Kubernetes gửi nó vào hệ thống tệp mỗi khi một vùng chứa mới được tạo.
Bạn sẽ cần xác thực để đạt được bất kỳ điều gì hữu ích với API. Kubernetes tạo một tài khoản dịch vụ mới cho mỗi Pod và cung cấp mã thông báo của nó tại /var/run/secrets/kubernetes.io/serviceaccount/token
. Điều này phải được bao gồm với mỗi yêu cầu HTTP như một mã thông báo mang trong Authorization
đầu trang.
Kết hợp mọi thứ lại với nhau, đây là một ví dụ về việc tạo một yêu cầu API Kubernetes trong Pod cơ bản bằng cách sử dụng curl
:
$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api { "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "192.168.49.2:8443" } ]
Máy chủ Kubernetes đã phản hồi với các phiên bản API có sẵn. Điều này xác nhận rằng một kết nối thành công đã được thực hiện bằng cách sử dụng kubernetes.default.svc
tên máy chủ và tài khoản dịch vụ được cung cấp.
Xử lý RBAC
Mặc dù một yêu cầu API đã được thực hiện thành công, hầu hết các yêu cầu khác sẽ bị giới hạn nếu RBAC được bật cho cụm của bạn. Các tài khoản dịch vụ mới được tạo không tự động nhận các vai trò, vì vậy Pod của bạn sẽ không thể yêu cầu các điểm cuối API được bảo vệ.
Bạn có thể giải quyết vấn đề này bằng cách tạo các đối tượng Vai trò của riêng mình và liên kết chúng với tài khoản dịch vụ được cung cấp cho Nhóm của bạn. Đầu tiên, hãy tạo một Vai trò mới:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]
Áp dụng nó cho cụm của bạn với Kubectl:
$ kubectl apply -f role.yaml
Tiếp theo ràng buộc vai trò với tài khoản dịch vụ:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: default name: demo-role-binding subjects: - kind: ServiceAccount name: default apiGroup: "" roleRef: kind: Role name: demo-role apiGroup: ""
Các default
tài khoản dịch vụ được chọn làm chủ thể của ràng buộc vai trò. Các nhóm luôn được cung cấp cùng với tài khoản dịch vụ này, trong phạm vi không gian tên mà chúng được tạo. Trong ví dụ này, default
không gian tên được sử dụng, nhưng điều này sẽ được thay đổi trên các đối tượng Vai trò và RoleBinding nếu Pod của bạn tồn tại trong một không gian tên khác.
Thêm RoleBinding vào cụm của bạn:
$ kubectl apply -f role-binding.yaml
Bây giờ các Pod của bạn sẽ được phép lấy và liệt kê các đối tượng Pod khác trong default
không gian tên. Bạn có thể xác minh điều này bằng cách thực hiện một yêu cầu API tới điểm cuối của Nhóm không gian tên:
$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/default/pods { "kind": "PodList", "apiVersion": "v1" ... }
Các nhóm có thể xác định vùng tên riêng của chúng bằng cách đọc /var/run/secrets/kubernetes.io/serviceaccount/namespace
tập tin:
$ cat /var/run/secrets/kubernetes.io/serviceaccount/namespace default
Điều này cung cấp một phương pháp thuận tiện để nội suy không gian tên đang hoạt động thành các URL điểm cuối:
$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)/pods { "kind": "PodList", "apiVersion": "v1" ... }
Chọn một tài khoản dịch vụ khác
Kubernetes tự động cung cấp các Pods với default
tài khoản dịch vụ bên trong không gian tên của họ. Thay vào đó, bạn có thể tùy chọn đưa vào một tài khoản dịch vụ khác bằng cách đặt spec.serviceAccountName
trường trên Nhóm của bạn:
apiVersion: v1 kind: Pod metadata: name: demo spec: serviceAccountName: demo-sa
Trong ví dụ này, Pod sẽ xác thực là demo-sa
mã thông báo. Bạn có thể tạo tài khoản dịch vụ này theo cách thủ công và ràng buộc nó với các vai trò bạn yêu cầu.
$ kubernetes create serviceaccount demo-sa
Tài khoản dịch vụ phải tồn tại trong cùng một không gian tên với Pod.
Chọn không sử dụng dịch vụ gắn kết tài khoản
Việc đưa vào tài khoản dịch vụ tự động không phải lúc nào cũng mong muốn. Nó có thể là một mối nguy hiểm về bảo mật vì một thỏa hiệp Pod thành công cung cấp quyền truy cập ngay lập tức vào API của cụm Kubernetes của bạn. Bạn có thể vô hiệu hóa việc gắn kết mã thông báo tài khoản dịch vụ với spec.automountServiceAccountToken
Trường tệp kê khai nhóm:
apiVersion: v1 kind: Pod metadata: name: demo spec: automountServiceAccountToken: false
Kubernetes sẽ không đưa /var/run/secrets/kubernetes.io/serviceaccount/token
tập tin. Điều này sẽ ngăn Pod xác thực với Kubernetes API trừ khi bạn cung cấp thông tin xác thực theo cách thủ công bằng một phương pháp khác. Trường này cũng được hỗ trợ trên các đối tượng tài khoản dịch vụ, khiến chúng không đủ điều kiện để được tự động gắn vào bất kỳ Pod nào.
Nếu bạn sử dụng tính năng gắn kết tài khoản dịch vụ, hãy đặt các chính sách RBAC thích hợp để hạn chế mã thông báo trong các trường hợp sử dụng dự kiến của bạn. Việc tránh truy cập có đặc quyền cao sẽ làm giảm nguy cơ thiệt hại nếu kẻ tấn công giành được quyền truy cập vào Pod của bạn.
Bản tóm tắt
Việc truy cập máy chủ Kubernetes API từ bên trong cụm của bạn cho phép các ứng dụng đang chạy kiểm tra và sửa đổi khối lượng công việc lân cận. Bạn có thể thêm chức năng bổ sung mà không cần mở cụm của mình để truy cập API bên ngoài.
Các thư viện khách hàng chính thức giúp dễ dàng thiết lập và chạy, nếu chúng phù hợp với trường hợp sử dụng của bạn. Trong các tình huống khác, bạn sẽ cần đưa ra các yêu cầu theo cách thủ công https://kubernetes.default.svc
, cung cấp tệp của tổ chức phát hành chứng chỉ và mã thông báo tài khoản dịch vụ mà Kubernetes đưa vào vùng chứa Pod của bạn. Bất kể phương pháp bạn sử dụng là gì, tài khoản dịch vụ phải được định cấu hình chính xác với các ràng buộc vai trò RBAC để Pod có quyền thực hiện các hành động dự định của nó.
[ad_2]