Nhảy tới nội dung

Một bài viết được gắn thẻ "kubernetes"

Xem tất cả Thẻ

· Một phút để đọc
ManhPT

Lens là một phần mềm nguồn mở cung cấp giao diện thân thiện để làm việc với nhiều kubernetes cluster

Khi khối lượng công việc được chuyển lên môi trường container (cụ thể là docker) ngày một nhiều, việc quản lý một số lượng lớn container và kết nối giữa chúng trở lên khó khăn hơn.

Khi quy mô và độ phức tạp của môi trường container tăng lên vượt quá khả năng quản lý bởi sức người, các nền tảng quản lý cấp phát container như Kubernetes ngày càng trở nên quan trọng.

Tuy nhiên, các nền tảng như vậy cũng đi liền với những thách thức đòi hỏi các thông số, khả năng giám sát và mức độ thân thiện với người dùng để diễn tả mức độ phức tạp của chúng.

Sử dụng Lens

Lens - tự xưng Kubernetes IDE - là một công cụ khá hữu ích, hấp dẫn và open source cung cấp khả năng quản lý các kubernetes cluster. Lens có thể kết nối đến các kubernetes cluster sử dụng kubeconfig file, sau đó hiển thị các thông tin về cluster và objects bên trong.

Lens cũng có thể kết nối hoặc cài đặt Prometheus stack để cung cấp các thông số về cluster, bao gồm thông tin và tình trạng các node.

Màn hình cluster overview

Tương tự Kubernetes dashboard hoặc Openshift, Lens cung cấp các cập nhật realtime về tình trạng của cluster và thu thập thông số giám sát với Prometheus.

Cài đặt Lens

Việc cài đặt khá đơn giản và hỗ trợ 3 nền tảng chính: Windows, MacOS, Linux. Có nhiều cách đề cài đặt và đơn giản nhất là tải về và cài đặt từ https://github.com/lensapp/lens/releases/latest. Ngoài ra, cũng có thể cài đặt bằng dòng lệnh với:

Windows (Chocolatey)

choco install -y lens

Ubuntu/Linux (Snap)

  1. Tải Lens package dành cho Snap.
  2. Sau khi tải về, thực hiện lệnh cài đặt snap như sau:
sudo snap install Lens-{version}.amd64.snap --dangerous --classic

Sau đó có thể bắt đầu sử dụng lens bằng cách gõ "lens" vào terminal.

MacOS

brew install --cask lens

Lens giúp nhìn ngắm Kubernetes rõ ràng hơn

Kubernetes rất phức tạp và nó có lý do để phải phức tạp. Lens không chỉ giúp giảm bớt rào cản đối với những người mới bắt đầu mà còn giúp những người đã có kinh nghiệm với kubernetes dễ thở hơn.

Ngoài cung cấp các thông số cơ bản về cluster, các node, lens còn có thể cung cấp thông tin chi tiết về các objects bên trong. Việc cài đặt hay hiển thị thông số giám sát từ Prometheus stack trở nên cực kỳ dễ dài chỉ với vài lần click chuột.

Ấn tượng hơn nữa, Lens có thể quản lý nhiều cluster cùng lúc và cho phép chuyển đổi giữa các cluster cực dễ dàng chỉ bằng cách nhấn nút. Bài viết có tham khảo và dịch lại từ: https://opensource.com/article/20/6/kubernetes-lens.

· Một phút để đọc
ManhPT

Hướng dẫn cài đặt và cấu hình cert-manager cho website sử dụng ingress-nginx với letsencrypt. Bạn có thể tham khảo tài liệu chính thống về cert-manager tại đây: https://cert-manager.io/docs/.

Kể từ ngày 24/07/2018, Google release Chrome 68 có tính năng đánh dấu các trang web không dùng HTTPS là “Không an toàn” nhằm xây dựng trình duyệt an toàn hơn. Việc này đã diễn ra trong vòng 1 năm. Hiện tại, Microsoft Edge (Chromium) vẫn đang duy trì điều này. Điều này khiến việc triển khai HTTPS cho website của bạn trở thành một yêu cầu bắt buộc.

Trong bài viết này, mình sẽ hướng dẫn cấu hình cert-manager cho nginx-ingress để tự động hóa hoàn toàn việc issue và renew chứng chỉ https cho website của bạn hoàn toàn miễn phí. Tất nhiên bài viết này chỉ áp dụng cho hệ thống sử dụng kubernetes. Trong thời điểm viết bài thì mình sử dụng K3S. Bạn có thể tham khảo cách cài đặt K3S tại đây.

Chuẩn bị

Cài đặt cert-manager

Để cài đặt cert-manager thì bạn chỉ cần làm đúng theo những hướng dẫn từ tài liệu chính hãng tại đây: https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm Tạo namespace cert-manager:

kubectl create namespace cert-manager

Tạo một helm release mới:

# Helm v3+
helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v1.0.3 \
--set installCRDs=true

# Helm v2
helm install \
--name cert-manager \
--namespace cert-manager \
--version v1.0.3 \
jetstack/cert-manager \
--set installCRDs=true

Cấu hình cert-manager ClusterIssuer

Bạn có 2 sự lựa chọn, self signed hoặc letsencrypt. Vui lòng đọc kỹ hướng dẫn trước khi sử dụng 😁.

Self signed

Sử dụng self signed certificate nếu website của bạn sử dụng kết hợp với CloudFlare SSL/TLS và sử dụng encryption mode là Full.

Tạo một template file selfsigned.issuer.yaml với nội dung như sau:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: selfsigned
namespace: cert-manager
spec:
selfSigned: {}

Tạo Issuer từ template trên:

kubectl --namespace cert-manager apply -f selfsigned.issuer.yaml

Let's Encrypt

Sử dụng Letsencrypt nếu website của bạn public trực tiếp ra internet hoặc sử dụng kết hợp CloudFlare SSL/TLS với encryption mode là Full (strict).

Tạo một template file letsencrypt-prod.issuer.yaml với nội dung như sau:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
namespace: cert-manager
spec:
acme:
# The ACME server URL
server: https://acme-v02.api.letsencrypt.org/directory
# Email address used for ACME registration
email: [email protected]
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-prod
# Enable the HTTP-01 challenge provider
solvers:
- http01:
ingress:
class: nginx

Chú ý cập nhật thông tin:

  • [email protected] - thay bằng email của bạn, Let's Encrypt sẽ liên hệ với bạn qua email này

Tạo Issuer từ template trên:

kubectl --namespace cert-manager apply -f letsencrypt-prod.issuer.yaml

Cấu hình ingress

Do chúng ta sử dụng kind: ClusterIssuer nên ingress ở các namespace khác cert-manager vẫn có thể sử dụng được.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
kubernetes.io/ingress.class: nginx
cert-manager.io/cluster-issuer: selfsigned
spec:
tls:
- secretName: test-ingress-tls
hosts:
- yourdomain.com
rules:
- host: yourdomain.com
http:
paths:
- path:
backend:
serviceName: your-service-name
servicePort: 80

Chú ý cập nhật các thông tin:

  • yourdomain.com - thay bằng domain thật của bạn
  • your-service-name - thay bằng service name của bạn

Quan trọng nhất là cert-manager.io/cluster-issuer: selfsigned, cert-manager sẽ dựa trên các annotations này cùng với thông tin của mỗi Ingress để thực hiện việc issue và renew certificate.

  • cert-manager.io/cluster-issuer là annotation yêu cầu sử dụng ClusterIssuer
  • selfsigned là tên của ClusterIssuer được chỉ định

· Một phút để đọc
ManhPT

K3S là một phiên bản nhỏ và nhẹ của Kubernetes mà bạn có thể sử dụng trên rất nhiều môi trường thiết bị khác nhau. Bài viết này không nhằm mục đích giới thiệu K3S nên các bạn có thể tìm hiểu thêm về K3S tại đây https://k3s.io/ hoặc https://github.com/rancher/k3s/blob/master/README.md trước khi đọc tiếp.

Để có thể cài đặt và sử dụng K3S thì các bạn cũng nên tham khảo yêu cầu hệ thống của K3S trước tại: https://rancher.com/docs/k3s/latest/en/installation/installation-requirements/. Nếu bạn đã chuẩn bị đầy đủ môi trường theo đúng yêu cầu của K3S thì bắt đầu thôi.

Cài đặt K3S với tất cả cấu hình mặc định:

curl -sfL https://get.k3s.io | sh -

Sau khi chạy script cài đặt trên thì:

  • K3S sẽ được cấu hình để tự động restart sau khi node bị reboot hoặc process bị lỗi hay bị kill.
  • Vài công cụ hỗ trợ cũng sẽ được cài đặt đó là: kubectl, crictl, ctr, k3s-killall.sh, and k3s-uninstall.sh.
  • Một file chứa kubeconfig sẽ được ghi vào /etc/rancher/k3s/k3s.yamlkubectl sẽ tự đụng sử dụng file này.

Chú ý:

Cài đặt K3S với custom config

Không sử dụng Traefik Ingress

curl -sfL https://get.k3s.io | sh -s - --disable traefik

Không sử dụng cả Traefik Ingress và Local-Path Storage

curl -sfL https://get.k3s.io | sh -s - --disable traefik,local-storage

Custom range cho NodePort Service

curl -sfL https://get.k3s.io | sh -s - --kube-apiserver-arg service-node-port-range=2000-32767

Cập nhật TLS cho phép remote kubectl thông qua public IP

curl -sfL https://get.k3s.io | sh -s - --tls-san=123.123.123.123
  • 123.123.123.123 - thay bằng public IP của cluster load balancer

Cập nhật hoặc thay đổi cấu hình K3S

Kubernetes nói chung và K3S nói riêng phát triển tương đối nhanh với cộng đồng lớn. Để cập nhật phiên bản mới hay thay đổi cấu hình cluster thì bạn chỉ cần chạy lại câu lệnh cài đặt với cấu hình mong muốn. Script cài đặt sẽ chạy lại các bước giống như lúc cài đặt.

Việc cập nhật phiên bản mới không nên diễn ra thường xuyên mà nên có kế hoạch trước và cũng nên đợi phiên bản mới chứng minh được tính ổn định rồi bạn mới upgrade cũng không muộn.

Thêm node cho cluster

Để thêm 1 node mới thì câu lệnh cũng rất đơn giản:

curl -sfL https://get.k3s.io | K3S_URL=https://<myserver>:6443 K3S_TOKEN=<mynodetoken> sh -
  • <myserver> - thay bằng IP của master node (nên sử dụng IP LAN)
  • <mynodetoken> - thay bằng token của master node được ghi tại /var/lib/rancher/k3s/server/node-token

Xóa cài đặt K3S

Nếu bạn cài đặt k3s sử dụng script thì script để xóa k3s cũng sẽ được cài đặt tự động. Để xóa k3s khỏi một server node:

/usr/local/bin/k3s-uninstall.sh

Để xóa k3s khỏi một agent node:

/usr/local/bin/k3s-agent-uninstall.sh

· Một phút để đọc
ManhPT

Khi Cloud Native tiếp tục đà phát triển mạnh mẽ trong cộng đồng, ngày càng nhiều tổ chức áp dụng những công nghệ và kỹ thuật, ứng dụng đi kèm của nó. Hãy điểm qua những gì được mong đợi sẽ diễn ra trong năm 2020.

Kubernetes đã không còn là một công nghệ mới và tên của nó đang lùi dần vào sau hậu trường. Sự tập trung sẽ được dành cho việc xây dựng các phương thức trừu tượng (abstractions) - để giảm độ phức tạp, công cụ và nền tảng bởi các cộng đồng đang không ngừng phát triển.

Dưới đây là 7 xu hướng đáng quan tâm trong năm 2020:

1. GitOps trở thành tiêu chuẩn cho Cloud Native

Một trong những xu hướng được mong chờ nhất trong năm 2019 là sự ra đời của GitOps. Là một phần mở rộng tự nhiên cho Cơ sở hạ tầng dưới dạng Mã (Infrastructure-as-Code) và Phân phối liên tục (Continuous Delivery). GitOps tập trung vào việc sử dụng Git làm cơ sở duy nhất (single source of truth) cho hệ thống. Thay đổi về cơ sở hạ tầng và ứng dụng được thực hiện bằng cách khai báo thông qua git repository (sau đây gọi tắt là git repo hoặc repo), với quy trình tự động đảm bảo trạng thái hiện tại của hệ thống phản ánh lại trạng thái trong repo. Thuật ngữ GitOps được đưa ra bởi Weave Works, bạn có thể đọc thêm qua blog của họ tại đây.

GitOps Engine là sản phẩm được tạo ra từ sự hợp tác giữa WeaWorks Flux và Intuit’s Argo, cho thấy tiềm năng tuyệt vời của công cụ tiêu chuẩn để thực hiện GitOps. Mong đợi có nhiều công cụ hơn sẽ tham gia hợp tác trong năm nay để có thể tham gia vào các dự án triệt để hơn.

GitOps đang ở giai đoạn đầu tiên được đón nhận bởi cộng đồng, nhưng được dự đoán sẽ trở thành một tiêu chuẩn cho tất cả các công ty có tham vọng hướng đến Cloud Native vào năm 2020.

2. Hybird Cloud là tương lai

Dù bạn có là fan của nó hay không, thì Hybrid hoặc Multi Cloud dường như sẽ là tương lai của các giải pháp Cloud Native. Trong tương lai, rõ ràng là không còn bất kỳ tổ chức lớn nào chạy hoàn toàn trên một cloud, cho dù cloud đó là on-premise, public hay private.

Vì nhiều lý do: bảo mật dữ liệu, phục hồi dữ liệu sau thảm họa (DR), quy mô xử lý, bảo mật dữ liệu cá nhân… giải pháp hybrid hoặc multi cloud sẽ được tin dùng hơn. Kết quả là, trong năm vừa qua, cả ba nhà cung cấp điện toán cloud lớn đã tung ra một sản phẩm để hỗ trợ hybrid cloud lai (AWS Outposts, Google’s Anthose, and Azure Arc).

Một trong những điểm hấp dẫn chính của Kubernetes đối với nhiều tổ chức là cách nó tự giới thiệu bản thân như một công cụ để thiết lập hybrid cloud. Mặc dù điều này đúng ở một mức độ nào đó, nhưng hỗ trợ nhiều cloud sẽ dẫn đến rất nhiều sự phức tạp. Có một số công cụ nhằm giúp đơn giản hóa việc này, Kubefed - còn gọi là Federation v2, Crossplane hoặc thông qua một lưới dịch vụ (service mesh) như Istio.

Trong năm tới, hy vọng cộng đồng và các công cụ sẽ tiếp tục phát triển, đồng thời các công ty đang tìm cách thực hiện các thiết lập hybrid cloud sẽ đánh giá lại kỳ vọng của họ khi họ nhận ra việc này tốn khá nhiều chi phí.

3. Kubernetes phải coi 2020 là năm của Developer

Một trong những lời chỉ trích lớn nhất về Kubernetes là nó không thân thiện với Developer. Đối với các nhóm quản trị (operations) và nền tảng (platforms), Kubernetes là một người hỗ trợ tuyệt vời. Nhưng thường thì các developer lại cảm thấy bị tụt hậu. Nó tạo thêm sự phức tạp trong vòng đời phần mềm của họ, họ phải học các công nghệ mới mà không có thêm nhiều lợi ích (có thể nhìn thấy). Có một môi trường phát triển giống như sản xuất vẫn còn rất khó khăn trong thế giới của các ứng dụng hướng đến Cloud Native, microservice và phân tán.

Ambassador, Draft, và Garden đang nỗ lực rất nhiều để giải quyết vấn đề này. Hy vọng năm 2020 sẽ là năm mà Kubernetes trở nên thân thiện hơn với các developer. Nhiều đội sẽ rời bỏ K8S nếu vấn đề này không được giải quyết.

4. SRE sẽ đi từ buzzword đến phổ biến

Kể từ khi Google phát hành ‘Site Reliability Engineering’ (Kỹ thuật ổn định hệ thống) lần đầu tiên và liệt kê chi tiết về cách thức vận hành các hệ thống sản xuất, thuật ngữ và vai trò đã tiếp tục phát triển nhanh chóng. Đến năm 2019, SRE vẫn đang rất phổ biến dựa trên các khảo sát gần đây.

Hầu hết các công ty đang triển khai SRE trong tổ chức của họ, nhưng một số lượng lớn trong số họ không áp dụng đúng quy trình và thay vào đó chỉ đơn giản là đổi thương hiệu cho các nhóm vận hành. Cuộc khảo sát tương tự từ Catchpoint, được liên kết ở trên, chỉ ra rằng SLO (Service Level Objectives - Mục tiêu cấp độ dịch vụ) thường không được xác định và vẫn còn quá nhiều vấn đề trong tổ chức - hai số liệu chính của SRE.

Với thực tiễn đang tiếp tục trưởng thành và phổ biến hơn, các quy trình sẽ trở nên nghiêm ngặt hơn. Bao gồm đánh giá sản xuất kỹ lưỡng cho tất cả các dịch vụ và SLO/SLI/SLA được xác định rõ, và để SRE thích hợp trở thành một yêu cầu khắt khe đối với bất kỳ công ty nào duy trì hệ thống sản xuất.

5. ’Remote first’ sẽ cung cấp cho các công ty nhiều lợi thế hơn

Làm việc từ xa không chỉ là mong muốn của người lao động, mà nó còn buộc tạo ra các thực tiễn tốt nhất về mặt giao tiếp và chủ động. (Dưới 32% những người tham gia khảo sát developer hàng năm của Stack Overflow vào năm 2019 cho biết cơ hội làm việc từ xa là quan trọng nhất đối với họ khi việc lựa chọn công việc.)

Các công cụ và thực tiễn được yêu cầu để hỗ trợ công việc từ xa có lợi bất kể tổ chức đó có nhân viên làm việc từ xa hay không.

Điều này có liên quan gì với Cloud Native? Cloud Native không chỉ là về công nghệ. Từ góc độ của Luật Conway, nếu chúng ta muốn xây dựng các hệ thống phân tán quy mô lớn với các giao diện khai báo rõ ràng, chúng ta nên xem xét để thực hiện những điều tương tự với cấu trúc tổ chức của mình.

Với việc thúc đẩy công việc từ xa tiếp tục, các công ty cung cấp phương pháp làm việc từ xa có hy vọng sẽ có lợi thế đáng kể so với các đối thủ cạnh tranh.

6. MLOps mở ra những cơ hội mới

Mặc dù không nhất thiết phải triển khai theo hướng Cloud Native, nhưng việc giới thiệu MLOps vào năm 2019 là một sự phát triển thú vị. MLOps là quá trình vận hành và quản lý vòng đời của machine learning trong sản xuất, đặc biệt là áp dụng các công cụ và thực tiễn của DevOps cho lĩnh vực khoa học dữ liệu.

Có thể coi đây là cầu nối giữa machine learning và Cloud Native, vì nó cho phép các nhóm khoa học dữ liệu và ML tận dụng các thực tiễn và công nghệ của Cloud Native. Cơ hội ở đây là rất lớn, và mong đợi lĩnh vực này sẽ thực sự bùng nổ trong năm tới.

7. Tranh luận về đạo đức sẽ ngày càng lớn hơn và cấp bách hơn

Trong vài năm qua, những lo ngại về đạo đức và công nghệ đã trở thành tâm điểm, từ việc các công ty sử dụng dữ liệu cho đến vấn đề tiêu thụ năng lượng của các trung tâm dữ liệu.

Đây đều là những nội dung quan trọng. Từ góc độ Cloud Native, sẽ có nhiều cuộc thảo luận hơn vào năm 2020 về việc làm thế nào để giúp giảm lượng khí thải carbon và nhiều nội dung khác nữa.

Phần kết luận

Trong khi bản thân công nghệ Cloud Native ngày càng trở nên chủ đạo, không gian chỉ phát triển nhanh hơn. Việc áp dụng các công nghệ chính như Kubernetes tiếp tục mở rộng, dẫn đến nhu cầu trừu tượng hóa và công cụ bổ sung.

Đây là một vài trong số các nội dung đáng chú ý trong năm nay, nhưng các lĩnh vực chưa được khám phá chắc chắn sẽ phát sinh vào năm 2020 mới là điều hấp dẫn hơn. Nguồn: https://blog.container-solutions.com/