Sách “Kubernetes cho DevOps”

Sách “Kubernetes cho DevOps” Xin chào cư dân Khabro! Kubernetes là một trong những yếu tố chính của hệ sinh thái đám mây hiện đại. Công nghệ này cung cấp độ tin cậy, khả năng mở rộng và khả năng phục hồi cho ảo hóa container. John Arundel và Justin Domingus nói về hệ sinh thái Kubernetes và giới thiệu các giải pháp đã được chứng minh cho các vấn đề hàng ngày. Từng bước, bạn sẽ xây dựng ứng dụng gốc trên nền tảng đám mây của riêng mình và tạo cơ sở hạ tầng để hỗ trợ ứng dụng đó, thiết lập môi trường phát triển và quy trình triển khai liên tục sẽ trợ giúp bạn khi bạn làm việc trên các ứng dụng tiếp theo.

• Bắt đầu với bộ chứa và Kubernetes từ những điều cơ bản: không cần có kinh nghiệm đặc biệt để tìm hiểu chủ đề này. • Chạy các cụm của riêng bạn hoặc chọn dịch vụ Kubernetes được quản lý từ Amazon, Google, v.v. • Sử dụng Kubernetes để quản lý vòng đời vùng chứa và mức tiêu thụ tài nguyên. • Tối ưu hóa các cụm dựa trên chi phí, hiệu suất, khả năng phục hồi, sức mạnh và khả năng mở rộng. • Tìm hiểu các công cụ tốt nhất để phát triển, thử nghiệm và triển khai ứng dụng của bạn. • Tận dụng các thông lệ hiện tại của ngành để đảm bảo an ninh và kiểm soát. • Triển khai các nguyên tắc DevOps trong toàn công ty của bạn để các nhóm phát triển có thể hành động linh hoạt, nhanh chóng và hiệu quả hơn.

Cuốn sách dành cho ai?

Cuốn sách này phù hợp nhất với nhân viên của bộ phận quản trị chịu trách nhiệm về máy chủ, ứng dụng và dịch vụ cũng như các nhà phát triển tham gia xây dựng dịch vụ đám mây mới hoặc di chuyển các ứng dụng hiện có sang Kubernetes và đám mây. Đừng lo lắng, bạn không cần biết cách làm việc với Kubernetes hoặc vùng chứa - chúng tôi sẽ dạy bạn mọi thứ.

Người dùng Kubernetes có kinh nghiệm cũng sẽ tìm thấy nhiều giá trị với phạm vi bao quát chuyên sâu về các chủ đề như RBAC, triển khai liên tục, quản lý dữ liệu nhạy cảm và khả năng quan sát. Chúng tôi hy vọng rằng những trang sách chắc chắn sẽ chứa đựng điều gì đó thú vị đối với bạn, bất kể kỹ năng và kinh nghiệm của bạn như thế nào.

Cuốn sách trả lời những câu hỏi gì?

Trong khi lập kế hoạch và viết cuốn sách, chúng tôi đã thảo luận về công nghệ đám mây và Kubernetes với hàng trăm người, nói chuyện với các nhà lãnh đạo và chuyên gia trong ngành cũng như những người mới hoàn thành. Dưới đây là những câu hỏi chọn lọc mà họ muốn được giải đáp trong ấn phẩm này.

  • “Tôi quan tâm đến lý do tại sao bạn nên dành thời gian cho công nghệ này. Nó sẽ giúp tôi và nhóm của tôi giải quyết vấn đề gì?”
  • “Kubernetes có vẻ thú vị nhưng có rào cản gia nhập khá cao. Việc chuẩn bị một ví dụ đơn giản không khó, nhưng việc quản lý và gỡ lỗi sâu hơn thì khó khăn. Chúng tôi muốn nhận được lời khuyên đáng tin cậy về cách mọi người quản lý cụm Kubernetes trong thế giới thực và những vấn đề chúng tôi có thể gặp phải.”
  • “Lời khuyên chủ quan sẽ hữu ích. Hệ sinh thái Kubernetes mang đến cho các nhóm mới quá nhiều lựa chọn. Khi có nhiều cách để làm cùng một việc, làm sao bạn biết cách nào là tốt nhất? Làm thế nào để thực hiện một sự lựa chọn?

Và có lẽ câu hỏi quan trọng nhất:

  • “Làm cách nào tôi có thể sử dụng Kubernetes mà không làm gián đoạn công ty của mình?”

Trích đoạn. Đối tượng cấu hình và bí mật

Khả năng tách logic của ứng dụng Kubernetes khỏi cấu hình của nó (nghĩa là khỏi bất kỳ giá trị hoặc cài đặt nào có thể thay đổi theo thời gian) là rất hữu ích. Các giá trị cấu hình thường bao gồm cài đặt dành riêng cho môi trường, địa chỉ DNS dịch vụ của bên thứ ba và thông tin xác thực.

Tất nhiên, tất cả những điều này có thể được đưa trực tiếp vào mã, nhưng cách tiếp cận này không đủ linh hoạt. Ví dụ: việc thay đổi giá trị cấu hình sau đó sẽ yêu cầu bạn xây dựng và triển khai lại mã của mình. Một giải pháp tốt hơn nhiều là tách cấu hình khỏi mã và đọc nó từ một tệp hoặc các biến môi trường.

Kubernetes cung cấp một số cách khác nhau để quản lý cấu hình. Trước tiên, bạn có thể chuyển các giá trị cho ứng dụng thông qua các biến môi trường được chỉ định trong đặc tả trình bao bọc nhóm (xem “Biến môi trường” trên trang 192). Thứ hai, dữ liệu cấu hình có thể được lưu trữ trực tiếp trong Kubernetes bằng cách sử dụng các đối tượng ConfigMap và Secret.

Trong chương này, chúng ta khám phá các đối tượng này một cách chi tiết và xem xét một số phương pháp thực tế để quản lý cấu hình và dữ liệu nhạy cảm bằng ứng dụng demo.

Cập nhật shell pod khi cấu hình thay đổi

Hãy tưởng tượng bạn có một triển khai trong cụm của mình và bạn muốn thay đổi một số giá trị trong ConfigMap của nó. Nếu sử dụng biểu đồ Helm (xem “Helm: Trình quản lý gói cho Kubernetes” trên trang 102), bạn có thể tự động phát hiện thay đổi cấu hình và tải lại shell pod của mình chỉ bằng một thủ thuật đơn giản. Thêm chú thích sau vào đặc tả triển khai của bạn:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

Mẫu triển khai hiện chứa tổng kiểm tra các tham số cấu hình: nếu tham số được thay đổi, tổng sẽ được cập nhật. Nếu bạn chạy nâng cấp helm, Helm sẽ phát hiện rằng thông số triển khai đã thay đổi và sẽ khởi động lại tất cả các shell pod.

Dữ liệu nhạy cảm trong Kubernetes

Chúng ta đã biết rằng đối tượng ConfigMap cung cấp một cơ chế linh hoạt để lưu trữ và truy cập dữ liệu cấu hình trong một cụm. Tuy nhiên, hầu hết các ứng dụng đều có những thông tin mang tính nhạy cảm và nhạy cảm, chẳng hạn như mật khẩu hoặc khóa API. Nó cũng có thể được lưu trữ trong ConfigMap, nhưng giải pháp này không lý tưởng.

Thay vào đó, Kubernetes cung cấp một loại đối tượng đặc biệt được thiết kế để lưu trữ dữ liệu nhạy cảm: Bí mật. Tiếp theo, hãy xem ví dụ về cách sử dụng đối tượng này trong ứng dụng demo của chúng tôi.

Để bắt đầu, hãy xem bảng kê khai Kubernetes cho đối tượng Bí mật (xem hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

Trong ví dụ này, khóa riêng magicWord là xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Từ xyzzy nhìn chung rất hữu ích trong thế giới máy tính. Tương tự như ConfigMap, bạn có thể lưu trữ nhiều khóa và giá trị trong một đối tượng Bí mật. Ở đây, để đơn giản, chúng tôi chỉ sử dụng một cặp khóa-giá trị.

Sử dụng các đối tượng bí mật làm biến môi trường

Giống như ConfigMap, đối tượng Bí mật có thể được cung cấp trong vùng chứa dưới dạng biến môi trường hoặc dưới dạng tệp trên đĩa của nó. Trong ví dụ sau, chúng tôi sẽ gán biến môi trường cho giá trị từ Bí mật:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

Chạy lệnh sau trong kho demo để áp dụng các tệp kê khai:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created

Như trước đây, hãy chuyển tiếp cổng cục bộ tới nơi triển khai để xem kết quả trong trình duyệt của bạn:

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

Khi mở một địa chỉ localhost:9999/ bạn sẽ thấy như sau:

The magic word is "xyzzy"

Viết các đối tượng bí mật vào tập tin

Trong ví dụ này, chúng tôi sẽ đính kèm đối tượng Bí mật vào vùng chứa dưới dạng tệp. Mã nằm trong thư mục hello-secret-file của kho demo.

Để kết nối Bí mật dưới dạng tệp, chúng tôi sẽ sử dụng cách triển khai sau:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-file
          ports:
              - containerPort: 8888
          volumeMounts:
              - name: demo-secret-volume
                mountPath: "/secrets/"
                readOnly: true
   volumes:
      - name: demo-secret-volume
        secret:
           secretName: demo-secret

Như trong tiểu mục “Tạo tập tin cấu hình từ các đối tượng ConfigMap” trên trang. 240, chúng tôi tạo một ổ đĩa (trong trường hợp này là demo-secret-volume) và gắn nó vào vùng chứa trong phần VolumeMounts của thông số kỹ thuật. Trường mountPath là /secrets, vì vậy Kubernetes sẽ tạo một tệp trong thư mục này cho mỗi cặp khóa/giá trị được xác định trong đối tượng Secret.

Trong ví dụ của chúng tôi, chúng tôi chỉ xác định một cặp khóa-giá trị được gọi là magicWord, do đó, tệp kê khai sẽ tạo một tệp /secrets/magicWord chỉ đọc duy nhất có dữ liệu nhạy cảm trong vùng chứa.

Nếu bạn áp dụng bảng kê khai này theo cách tương tự như ví dụ trước, bạn sẽ nhận được kết quả tương tự:

The magic word is "xyzzy"

Đọc đồ vật bí mật

Trong phần trước, chúng ta đã sử dụng lệnh kubectl mô tả để hiển thị nội dung của Bản đồ cấu hình. Điều tương tự có thể được thực hiện với Secret?

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             <none>
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

Xin lưu ý rằng dữ liệu không được hiển thị. Các đối tượng bí mật trong Kubernetes thuộc loại Opaque, có nghĩa là nội dung của chúng không được hiển thị trong đầu ra mô tả kubectl, mục nhật ký hoặc thiết bị đầu cuối, khiến không thể vô tình tiết lộ thông tin nhạy cảm.

Để xem phiên bản YAML được mã hóa của dữ liệu nhạy cảm, hãy sử dụng lệnh kubectl get:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

base64

eHl6enk= là gì, hoàn toàn khác với giá trị ban đầu của chúng ta? Đây thực sự là một đối tượng Bí mật, được biểu thị bằng mã hóa base64. Base64 là một sơ đồ mã hóa dữ liệu nhị phân tùy ý dưới dạng một chuỗi ký tự.

Vì thông tin nhạy cảm có thể ở dạng nhị phân và không xuất ra (như trường hợp khóa mã hóa TLS), các đối tượng Bí mật luôn được lưu trữ ở định dạng base64.

Văn bản beHl6enk= là phiên bản được mã hóa base64 của từ bí mật xyzzy của chúng tôi. Bạn có thể xác minh điều này bằng cách chạy lệnh base64 —decode trong terminal:

echo "eHl6enk=" | base64 --decode
xyzzy

Vì vậy, mặc dù Kubernetes bảo vệ bạn khỏi việc vô tình xuất ra dữ liệu nhạy cảm trong thiết bị đầu cuối hoặc tệp nhật ký, nhưng nếu bạn có quyền đọc đối tượng Bí mật trong một không gian tên cụ thể, thì dữ liệu đó có thể được mã hóa base64 và sau đó được giải mã.

Nếu bạn cần mã hóa base64 một số văn bản (ví dụ: để đặt nó trong Bí mật), hãy sử dụng lệnh base64 không có đối số:

echo xyzzy | base64
eHl6enkK

Truy cập các đối tượng bí mật

Ai có thể đọc và chỉnh sửa các đối tượng Bí mật? Điều này được xác định bởi RBAC, một cơ chế kiểm soát truy cập (chúng ta sẽ thảo luận chi tiết về nó trong tiểu mục “Giới thiệu về Kiểm soát truy cập dựa trên vai trò” trên trang 258). Nếu bạn đang chạy một cụm không có RBAC hoặc chưa được bật thì tất cả các đối tượng Bí mật của bạn đều có sẵn cho bất kỳ người dùng và vùng chứa nào (chúng tôi sẽ giải thích sau rằng bạn không nên có bất kỳ cụm sản xuất nào mà không có RBAC).

Mã hóa dữ liệu thụ động

Còn những người có quyền truy cập vào cơ sở dữ liệu etcd nơi Kubernetes lưu trữ tất cả thông tin của nó thì sao? Họ có thể đọc dữ liệu nhạy cảm mà không được phép đọc các đối tượng Bí mật thông qua API không?

Kể từ phiên bản 1.7, Kubernetes hỗ trợ mã hóa dữ liệu thụ động. Điều này có nghĩa là thông tin nhạy cảm bên trong etcd được lưu trữ dưới dạng mã hóa trên đĩa và ngay cả những người có quyền truy cập trực tiếp vào cơ sở dữ liệu cũng không thể đọc được. Để giải mã nó, bạn cần một khóa mà chỉ máy chủ API Kubernetes mới có. Trong cụm được cấu hình đúng, mã hóa thụ động phải được bật.

Bạn có thể kiểm tra xem mã hóa thụ động có hoạt động trong cụm của mình theo cách này hay không:

kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
        --experimental-encryption-provider-config=...

Nếu bạn không thấy cờ thử nghiệm-mã hóa-nhà cung cấp-config thì mã hóa thụ động chưa được bật. Khi sử dụng Google Kubernetes Engine hoặc các dịch vụ quản lý Kubernetes khác, dữ liệu của bạn được mã hóa bằng cơ chế khác nên sẽ không xuất hiện cờ. Kiểm tra với nhà cung cấp Kubernetes của bạn để xem nội dung etcd có được mã hóa hay không.

Lưu trữ dữ liệu bí mật

Có một số tài nguyên Kubernetes không bao giờ nên bị xóa khỏi cụm, chẳng hạn như các đối tượng Bí mật có độ nhạy cảm cao. Bạn có thể bảo vệ tài nguyên khỏi bị xóa bằng chú thích do trình quản lý Helm cung cấp:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

Chiến lược quản lý đối tượng bí mật

Trong ví dụ ở phần trước, dữ liệu nhạy cảm được bảo vệ khỏi truy cập trái phép ngay sau khi được lưu trữ trong cụm. Nhưng trong tệp kê khai, chúng được lưu trữ dưới dạng văn bản thuần túy.

Bạn không bao giờ nên đặt thông tin bí mật vào các tệp nằm trong phiên bản kiểm soát. Làm cách nào bạn có thể quản lý và lưu trữ thông tin này một cách an toàn trước khi áp dụng nó vào cụm Kubernetes của mình?

Bạn có thể chọn bất kỳ công cụ hoặc chiến lược nào để xử lý dữ liệu nhạy cảm trong ứng dụng của mình, nhưng bạn vẫn cần phải trả lời ít nhất các câu hỏi sau.

  • Dữ liệu nhạy cảm nên được lưu trữ ở đâu để có thể truy cập dễ dàng?
  • Làm cách nào để các ứng dụng đang hoạt động của bạn có thể truy cập được dữ liệu nhạy cảm?
  • Điều gì sẽ xảy ra với ứng dụng của bạn khi bạn thay thế hoặc chỉnh sửa dữ liệu nhạy cảm?

Về tác giả

John Arundel là nhà tư vấn có 30 năm kinh nghiệm trong ngành máy tính. Anh ấy đã viết một số cuốn sách và làm việc với nhiều công ty từ các quốc gia khác nhau, tư vấn cho họ về cơ sở hạ tầng dựa trên nền tảng đám mây và Kubernetes. Khi rảnh rỗi, anh thích lướt sóng, bắn súng lục giỏi và chơi piano như một người nghiệp dư. Sống trong một ngôi nhà cổ tích ở Cornwall, Anh.

Justin Domingus — kỹ sư quản trị hệ thống làm việc trong môi trường DevOps với Kubernetes và công nghệ đám mây. Anh ấy thích dành thời gian ở ngoài trời, uống cà phê, đi cua và ngồi trước máy tính. Sống ở Seattle, Washington, với một con mèo tuyệt vời và một người vợ và người bạn thân còn tuyệt vời hơn nữa, Adrienne.

» Thông tin chi tiết về cuốn sách có thể tìm thấy tại trang web của nhà xuất bản
» Mục lục
» Đoạn trích

Đối với Khabrozhiteley giảm giá 25% khi sử dụng phiếu giảm giá - Kubernetes

Sau khi thanh toán phiên bản giấy của cuốn sách, một cuốn sách điện tử sẽ được gửi qua e-mail.

Nguồn: www.habr.com

Thêm một lời nhận xét