‫Nếu bạn không đến trực tiếp từ bài giảng cuối cùng
‫về bài giảng này, hãy quay lại bài giảng trước để đảm bảo rằng bạn
‫đang chạy Triển khai thích hợp để bạn sẽ có nhật ký mà chúng
‫ta sẽ thấy ở đây sau một giây.
‫Do đó, chúng tôi có Apache Deployment đang chạy trong nền
‫và nó có hai nhóm vì chúng tôi đã chia tỷ lệ
‫các bản sao thành hai. Chúng ta có thể thực
‫hiện kubectl get pods và xem kết quả.
‫Tất nhiên, tên nhóm của bạn sẽ hơi khác so
‫với của tôi vì chúng sẽ có số và ký tự ngẫu nhiên
‫ở cuối ở đó. Bất cứ khi nào tôi đang
‫nhập nó, chỉ cần nhận ra hai khối cuối cùng bạn sẽ nhập
‫một cái gì đó khác nhau dựa trên những gì Triển khai của bạn đang hiển thị.
‫Có một số lệnh, giống như với Swarm
‫và với chính Docker. Trong trường hợp này, chúng là các lệnh
‫khác nhau để hiểu những gì đang xảy ra trong một vùng chứa và những
‫gì người điều phối đang làm với các vùng chứa.
‫Cái đầu tiên là nhật ký.
‫Cái thứ hai là mô tả.
‫Về mặt kỹ thuật, chúng tôi không có lệnh kiểm tra trong Kubernetes,
‫nhưng mô tả còn nhiều hơn thế nữa.
‫Đầu tiên, hãy thử một lệnh nhật ký.
‫Đầu ra của bạn có thể hơi khác so với của tôi.
‫Bạn sẽ nhận thấy rằng dòng đầu tiên sau khi chúng tôi nhập vào
‫triển khai nhật ký / my-apache.
‫Nó cho biết đã tìm thấy hai nhóm và sử dụng một tên
‫nhóm, nó đã đặt một tên cụ thể ở đó.
‫Đó là vì lệnh nhật ký mặc định sẽ không
‫kéo tất cả các nhóm khác nhau và
‫kết hợp chúng lại với nhau như bạn
‫làm với lệnh Docker hoặc Swarm. Theo mặc định, nó sẽ chỉ kéo một trong những thứ đó.
‫Lke các lệnh nhật ký khác mà bạn đã sử
‫dụng trong khóa học này, có rất nhiều tùy chọn bao
‫gồm --follow, --tail.
‫Đó là những điều phổ biến đối với các lệnh ghi nhật ký trong bất
‫kỳ hệ thống Linux nào.
‫Nếu chúng ta đã thực hiện lệnh tương tự với - chỉ cần làm theo,
‫sau đó nó sẽ đợi bất kỳ điều gì mới hiển thị trong nhật ký
‫của nhóm đó. Sau đó --tail,
‫1 chỉ có nghĩa là chỉ trả về dòng cuối cùng.
‫Bằng cách đó, bạn không nhận được một lượng lớn các bản ghi.
‫Bạn có thể kiểm soát C ra khỏi đó.
‫Điều gì sẽ xảy ra nếu bạn muốn xem các bản ghi được kết
‫hợp cho nhiều nhóm?
‫Bạn chắc chắn có thể làm được điều đó. Đó không chỉ là lệnh
‫nhật ký mặc định. Trong trường hợp này, chúng ta
‫sẽ phải sử dụng một thứ gọi là Bộ chọn trong Kubernetes, đây là một kỹ thuật
‫lấy nhiều nhóm dựa trên một nhãn mà tất cả
‫chúng đều dùng chung.
‫Điều thú vị ở đây là khi
‫bạn sử dụng lệnh kubectl run, nó sẽ tự động thêm
‫nhãn tên của Triển khai vào tất cả các nhóm này.
‫Vì vậy, chúng ta có thể sử dụng cùng một tên Triển khai Apache của
‫tôi để chọn tất cả các nhóm có nhãn đó.
‫Lưu ý rằng đây chỉ là một đối sánh đơn
‫giản của một nhãn ở đây. Vì vậy, nếu bạn có
‫các Triển khai hoặc nhóm khác tình cờ có nhãn này, chúng
‫cũng sẽ bị cuốn vào điều này. Vì vậy, bạn phải cẩn thận với việc ghi
‫nhãn và đặt tên của mình.
‫Chúng tôi đang sử dụng a
‫-l ở đây để chỉ định nhãn và chúng tôi đang chỉ
‫định nhãn mà lệnh chạy đã áp dụng, đó
‫là Apache của tôi.
‫Cũng giống như bản thân Swarm và Docker, các lệnh nhật ký này có
‫thể rất tiện dụng để khắc phục sự cố nhanh chóng nhưng không phải là
‫sự thay thế cho hệ thống nhật ký đầy đủ.
‫Trong Kubernetes, theo mặc định, nó chỉ có thể kéo tối
‫đa năm nhóm cùng một lúc khi nó
‫sử dụng loại bộ chọn để kéo trong nhật ký.
‫Bạn luôn có thể tăng số đó, nhưng thực tế là hệ thống
‫đang đánh thuế việc lấy các tệp nhật ký này từ tất
‫cả các nút khác nhau.
‫Trong quá trình sản xuất, bạn sẽ muốn có một hệ thống ghi nhật ký của bên thứ
‫ba sẽ thu thập tất cả các nhật ký này và lưu trữ chúng
‫theo thời gian để truy xuất nhanh hơn.
‫Điều đó đúng với bất kỳ hệ thống điều phối vùng chứa
‫nào, cho dù đó là Docker, Swarm hay Kubernetes.
‫Lệnh tiếp theo ở đây sẽ là mô tả lệnh.
‫Trong trường hợp này, lệnh mô tả là nơi chúng
‫ta muốn chỉ định chính nhóm.
‫Chúng tôi muốn có một nhóm rất cụ thể, nhưng sau đó chúng tôi
‫cần biết tên của những nhóm đó trước.
‫Vì vậy, hãy lấy pod trước.
‫Sau đó, chúng ta có thể sao chép và dán một trong những tên đó vào
‫một lệnh mô tả.
‫Nhập nhóm trước.
‫Tôi sẽ lấy lại cái vỏ đó.
‫Tôi không nhất thiết phải chỉ định một nhóm đó.
‫Tôi có thể nói nhóm và nó sẽ hiển thị tất cả các nhóm, điều
‫này có thể hơi nguy hiểm nếu bạn có nhiều vỏ.
‫Bạn chắc chắn có thể mô tả các tài nguyên khác và nhận lại
‫nhiều loại kết quả khác nhau dựa trên đối tượng.
‫Điều tôi muốn nhấn mạnh ở đây là
‫điều này sẽ tương tự như lệnh kiểm tra trong
‫Swarm hoặc trong chính Docker. Tuy nhiên, nó cho hiển thị đẹp hơn một chút
‫trên màn hình hơn là trong JSON.
‫Khi cuộn xuống kết quả, bạn sẽ nhận thấy rằng nó không
‫chỉ là một mô tả về đối tượng khác nhau mà còn
‫kéo lên những thứ như sự kiện
‫ở phía dưới, đây là một cách tuyệt vời để có được trạng
‫thái nhanh chóng về thực tế hiện tại của đối tượng đó.
‫Vì vậy, trong trường hợp bạn gặp sự cố, có thể với một nhóm
‫đang kéo hình ảnh, bạn sẽ thấy sự kiện đó ở đây,
‫nơi nó sẽ thông báo không thể kéo hình ảnh.
‫Đó là một điều thường gặp khi bạn vô tình gõ nhầm tên hình
‫ảnh hoặc một cái gì đó tương tự.
‫Điều này có thể khá hữu ích cho một kỹ thuật khắc phục sự cố nhanh
‫chóng mà không cần phải bật một số sự kiện hoặc
‫nhật ký gỡ lỗi.
‫Được rồi. Đối với phần
‫cuối cùng này, tôi sẽ chỉ cho bạn cách Kubernetes có khả năng phục
‫hồi tương tự như Swarm, trong đó nếu bạn xóa một trong các mức
‫trừu tượng thấp hơn, trong trường hợp này nếu bạn xóa một
‫nhóm, mức trừu tượng cao hơn, Triển khai và ReplicaSet,
‫sẽ đảm bảo rằng nhóm đó được tạo lại.
‫Điều đó tương tự như cách một vùng chứa hoặc nhiệm vụ trong
‫Swarm, nếu bạn xóa nó, sẽ được dịch vụ tạo lại.
‫Chúng tôi sẽ thực hiện việc này trong hai cửa sổ khác nhau.
‫Trong cửa sổ đầu tiên, chúng ta sẽ sử dụng get với a -w.
‫Điều đó sẽ cung cấp cho chúng ta trải nghiệm tương
‫tự như lệnh đồng hồ. Nếu bạn đã từng thấy tôi
‫sử dụng lệnh watch trong khóa học này để xem bất kỳ lệnh Linux
‫nào, về cơ bản có nghĩa là chạy thứ đó trong nền
‫và bạn có thể làm điều đó trong Linux.
‫Tuy nhiên, lệnh watch đó không phải lúc nào cũng có sẵn trên
‫tất cả các hệ điều hành. Ở đây, chúng ta
‫có thể thực hiện kubectl get pods nhưng thêm
‫-w để nó nằm ở
‫đó và làm mới cứ sau vài giây.
‫Bây giờ, chúng ta có thể đi đến một
‫thiết bị đầu cuối khác. Chúng tôi sẽ xóa một trong những nhóm đó.
‫Ngày thứ nhất. chúng ta sẽ cần sao
‫chép tên và sử
‫dụng kubectl pod / tên của pod.
‫Bạn sẽ nhận thấy rằng nó đang xóa nó.
‫Sau đó, chúng tôi sẽ cập nhật nhật ký đang chạy này
‫về những thứ đang thay đổi.
‫Tôi cũng thích điều này tốt hơn một chút so với
‫lệnh watch vì lệnh watch làm mới màn hình, nơi điều này hiển thị sự lặp
‫lại liên tục của các thay
‫đổi, khá gọn gàng. Ở dưới cùng,
‫nếu chúng tôi thực hiện thêm một kubectl lấy nhóm, bạn sẽ thấy rằng chúng
‫tôi đang quay trở lại hai.
‫Một lần nữa, đây là khía cạnh tự phục hồi của
‫một dàn nhạc. Đó là một trong những mục tiêu chính của việc có một.
‫Cuối cùng, tôi muốn chỉ ra một điều gì đó ở
‫đây mà trước đây bạn có thể đã được bảo vệ khỏi làm những điều gây
‫hại nhất định trong Docker a Swarm, nơi nếu bạn cố gắng thay đổi thứ gì đó hoặc
‫xóa thứ gì đó mà bạn không nên làm, nó
‫có thể cảnh báo bạn trước thời gian.
‫Kubernetes có xu hướng rơi vào phía bên kia, nơi nó ít kiên quyết hơn
‫một chút về cách bạn sử dụng nó.
‫Điều đó có nghĩa là đôi khi bạn có thể
‫làm những điều mà bạn không nên làm, chẳng hạn như ví dụ
‫của tôi trước đó về việc sửa đổi ReplicaSet thay vì sửa đổi
‫Triển khai bên trên nó.
‫Điều tương tự cũng có thể đúng với việc thay đổi một nhóm khi bạn thực sự không nên
‫làm điều đó. Bạn nên thay đổi đối tượng phía trên nó.
‫Điều đó chỉ nhấn mạnh rằng bạn cần phải hiểu chi tiết cụ
‫thể về những gì bạn đang làm
‫để không vô tình xóa, thay đổi hoặc sửa đổi điều sai theo
‫thứ tự sai.
‫Hãy nhớ thực hiện kubectl xóa triển khai my-apache
‫để xóa khỏi bài giảng này.