Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Instal CloudWatch agen dengan add-on Amazon CloudWatch Observability EKS atau bagan Helm
Anda dapat menggunakan add-on Amazon CloudWatch Observability EKS atau bagan Helm CloudWatch Observability Amazon untuk menginstal CloudWatch Agen dan agen Fluent-bit pada cluster Amazon EKS. Anda juga dapat menggunakan bagan Helm untuk menginstal CloudWatch Agen dan agen Fluent-bit pada klaster Kubernetes yang tidak di-host di Amazon EKS.
Menggunakan salah satu metode pada kluster Amazon EKS memungkinkan Wawasan Kontainer dengan peningkatan observabilitas untuk Amazon EKS dan Sinyal CloudWatch Aplikasi secara default. Kedua fitur tersebut membantu Anda mengumpulkan metrik infrastruktur, telemetri kinerja aplikasi, dan log kontainer dari cluster.
Dengan Wawasan Kontainer yang memiliki kemampuan observabilitas yang ditingkatkan untuk Amazon EKS, metrik-metrik Wawasan Kontainer akan dikenakan biaya per observasi, bukan dibebankan per metrik yang disimpan atau log yang diserap. Untuk Sinyal Aplikasi, penagihan didasarkan pada permintaan masuk ke aplikasi Anda, permintaan keluar dari aplikasi Anda, dan setiap tujuan tingkat layanan yang dikonfigurasi (SLO). Setiap permintaan masuk yang diterima menghasilkan satu sinyal aplikasi, dan setiap permintaan keluar yang dibuat menghasilkan satu sinyal aplikasi. Setiap SLO menciptakan dua sinyal aplikasi per periode pengukuran. Untuk informasi selengkapnya tentang CloudWatch harga, lihat CloudWatch Harga Amazon
Kedua metode mengaktifkan Container Insights pada node pekerja Linux dan Windows di cluster Amazon EKS. Untuk mengaktifkan Wawasan Kontainer di Windows, Anda harus menggunakan add-on Amazon EKS versi 1.5.0 atau yang lebih baru atau bagan Helm. Saat ini, Sinyal Aplikasi tidak didukung pada Windows di kluster Amazon EKS.
Add-on Amazon CloudWatch Observability EKS didukung pada kluster Amazon EKS yang berjalan dengan Kubernetes versi 1.23 atau yang lebih baru.
Saat Anda menginstal add-on atau bagan Helm, Anda juga harus memberikan izin IAM untuk memungkinkan CloudWatch agen mengirim metrik, log, dan jejak ke. CloudWatch Ada dua cara untuk melakukan hal ini:
Lampirkan sebuah kebijakan ke peran IAM simpul pekerja Anda. Opsi ini memberikan izin ke node pekerja untuk mengirim telemetri. CloudWatch
Gunakan peran IAM untuk akun layanan untuk pod agen, dan lampirkan kebijakan pada peran ini. Ini hanya berfungsi untuk klaster Amazon EKS. Opsi ini hanya memberikan CloudWatch akses ke pod agen yang sesuai.
Topik
Opsi 1: Instal menggunakan EKS Pod Identity
Jika Anda menggunakan versi 3.1.0 atau versi lebih baru dari add-on, Anda dapat menggunakan EKS Pod Identity untuk memberikan izin yang diperlukan untuk add-on. EKS Pod Identity adalah opsi yang direkomendasikan dan memberikan manfaat seperti hak istimewa paling sedikit, rotasi kredensi, dan auditabilitas. Selain itu, menggunakan EKS Pod Identity memungkinkan Anda untuk menginstal add-on EKS sebagai bagian dari pembuatan cluster itu sendiri.
Untuk menggunakan metode ini, pertama ikuti langkah-langkah asosiasi EKS Pod Identity untuk membuat peran IAM dan mengatur agen EKS Pod Identity.
Kemudian instal add-on Amazon CloudWatch Observability EKS. Untuk menginstal add-on, Anda dapat menggunakan, konsol Amazon EKS AWS CLI, AWS CloudFormation, atau Terraform.
Opsi 2: Instal dengan izin IAM pada node pekerja
Untuk menggunakan metode ini, pertama-tama lampirkan kebijakan CloudWatchAgentServerPolicyIAM ke node pekerja Anda dengan memasukkan perintah berikut. Dalam perintah ini, ganti my-worker-node-role
dengan peran IAM yang digunakan oleh node pekerja Kubernetes Anda.
aws iam attach-role-policy \ --role-name
my-worker-node-role
\ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
Kemudian instal add-on Amazon CloudWatch Observability EKS. Untuk menginstal add-on, Anda dapat menggunakan, konsol AWS CLI, AWS CloudFormation, atau Terraform.
Opsi 3: Instal menggunakan peran akun layanan IAM (hanya berlaku untuk menggunakan add-on)
Metode ini hanya berlaku jika Anda menggunakan add-on Amazon CloudWatch Observability EKS. Sebelum menggunakan metode ini, verifikasi prasyarat berikut:
-
Anda memiliki sebuah klaster Amazon EKS fungsional dengan simpul yang terlampir di salah satu Wilayah AWS yang mendukung Wawasan Kontainer. Untuk melihat daftar Wilayah yang didukung, silakan lihat Wawasan Kontainer.
-
Anda telah
kubectl
melakukan instalasi dan mengkonfigurasi untuk klaster. Untuk informasi selengkapnya, silakan lihat Menginstalkubectl
dalam Panduan Pengguna Amazon EKS. -
Anda telah
eksctl
melakukan instalasi. Untuk informasi selengkapnya, silakan lihat Menginstal atau memperbaruieksctl
di Panduan Pengguna Amazon EKS.
Pertimbangan untuk Amazon EKS Hybrid Nodes
Metrik tingkat simpul tidak tersedia untuk node hibrida karena Wawasan Kontainer bergantung pada ketersediaan Layanan Metadata EC2 Instance (IMDS) untuk metrik tingkat simpul. Metrik tingkat clusterPod, beban kerja, dan container tersedia untuk node hybrid.
Setelah Anda menginstal add-on dengan mengikuti langkah-langkah di bagian sebelumnya, Anda harus memperbarui manifes add-on sehingga agen dapat berjalan dengan sukses pada node hybrid. Edit amazoncloudwatchagents
sumber daya di cluster untuk menambahkan variabel RUN_WITH_IRSA
lingkungan agar sesuai dengan yang berikut ini.
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
apiVersion: v1 items: - apiVersion: cloudwatch.aws.amazon.com/v1alpha1 kind: AmazonCloudWatchAgent metadata: ... name: cloudwatch-agent namespace: amazon-cloudwatch ... spec: ... env: - name: RUN_WITH_IRSA # <-- Add this value: "True" # <-- Add this - name: K8S_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ...
(Opsional) Konfigurasi tambahan
Menyisih dari mengumpulkan log kontainer
Secara default, add-on menggunakan Fluent Bit untuk mengumpulkan log kontainer dari semua pod dan kemudian mengirimkan log ke CloudWatch Log. Untuk informasi tentang log mana yang dikumpulkan, silakan lihat Menyiapkan Fluent Bit.
catatan
Baik add-on maupun bagan Helm tidak mengelola sumber daya Fluentd atau Fluent Bit yang ada dalam sebuah cluster. Anda dapat menghapus resource Fluentd atau Fluent Bit yang ada sebelum menginstal bagan add-on atau Helm. Atau, untuk menjaga pengaturan yang ada dan menghindari add-on atau bagan Helm dari juga menginstal Fluent Bit, Anda dapat menonaktifkannya dengan mengikuti instruksi di bagian ini.
Untuk memilih keluar dari kumpulan log kontainer jika Anda menggunakan add-on Amazon CloudWatch Observability EKS, teruskan opsi berikut saat Anda membuat atau memperbarui add-on:
--configuration-values '{ "containerLogs": { "enabled": false } }'
Untuk memilih keluar dari koleksi log kontainer jika Anda menggunakan bagan Helm, berikan opsi berikut saat Anda membuat atau memperbarui add-on:
--set containerLogs.enabled=false
Gunakan konfigurasi Fluent Bit kustom
Dimulai dengan versi 1.7.0 dari add-on Amazon CloudWatch Observability EKS, Anda dapat memodifikasi konfigurasi Fluent Bit saat membuat atau memperbarui bagan add-on atau Helm. Anda menyediakan konfigurasi Fluent Bit kustom di bagian tingkat containerLogs
root dari konfigurasi lanjutan add-on atau nilai yang diganti di bagan Helm. Dalam bagian ini, Anda menyediakan konfigurasi Fluent Bit kustom di config
bagian (untuk Linux) atau configWindows
bagian (untuk Windows). Selanjutnya config
dipecah menjadi sub-bagian berikut:
service
— Bagian ini mewakiliSERVICE
konfigurasi untuk menentukan perilaku global mesin Fluent Bit.customParsers
— Bagian ini mewakili setiap globalPARSER
s yang ingin Anda sertakan yang mampu mengambil entri log tidak terstruktur dan memberi mereka struktur untuk memudahkan pemrosesan dan penyaringan lebih lanjut.extraFiles
- Bagian ini dapat digunakan untuk menyediakanconf
file Fluent Bit tambahan untuk disertakan. Secara default, 3conf
file berikut disertakan:.application-log.conf
—conf
File untuk mengirim log aplikasi dari cluster Anda ke grup log/aws/containerinsights/
di CloudWatch Log.my-cluster-name
/applicationdataplane-log.conf
—conf
File untuk mengirim log yang sesuai dengan komponen data plane cluster Anda termasuk log CRI, log kubelet, log kube-proxy, dan log Amazon VPC CNI ke grup log di Logs./aws/containerinsights/
CloudWatchmy-cluster-name
/dataplanehost-log.conf
— Aconf
untuk mengirim log dari/var/log/dmesg
,/var/log/messages
, dan/var/log/secure
di Linux, dan Sistemwinlogs
di Windows, ke grup log/aws/containerinsights/
di CloudWatch.my-cluster-name
/host
catatan
Berikan konfigurasi lengkap untuk masing-masing bagian individual ini bahkan jika Anda memodifikasi hanya satu bidang dalam sub-bagian. Kami menyarankan Anda menggunakan konfigurasi default yang disediakan di bawah ini sebagai baseline dan kemudian memodifikasinya sehingga Anda tidak menonaktifkan fungsionalitas yang diaktifkan secara default. Anda dapat menggunakan konfigurasi YAMB berikut saat memodifikasi konfigurasi lanjutan untuk add-on Amazon EKS atau saat Anda memberikan penggantian nilai untuk bagan Helm.
Untuk menemukan config
bagian klaster Anda, lihat aws-observability/helm-charts/charts/amazon-cloudwatch-observability/values.yaml
ke untuk menemukan config
bagian (untuk Linux) dan configWindows
bagian (untuk Windows) di dalam fluentBit
bagian di bawahcontainerLogs
.
Sebagai contoh, konfigurasi Bit Lancar default untuk versi 1.7.0 dapat ditemukan di sini.
Kami menyarankan Anda menyediakan config
sebagai YAMAL saat Anda menyediakannya menggunakan konfigurasi lanjutan add-on Amazon EKS atau saat Anda menyediakannya sebagai penggantian nilai untuk instalasi Helm Anda. Pastikan bahwa YAMAL sesuai dengan struktur berikut.
containerLogs: fluentBit: config: service: | ... customParsers: | ... extraFiles: application-log.conf: | ... dataplane-log.conf: | ... host-log.conf: | ...
Contoh berikut config
mengubah pengaturan global untuk interval flush menjadi 45 detik. Meskipun satu-satunya modifikasi adalah Flush
bidang, Anda tetap harus memberikan SERVICE
definisi lengkap untuk sub-bagian layanan. Karena contoh ini tidak menentukan penggantian untuk sub-bagian lain, default digunakan untuk mereka.
containerLogs: fluentBit: config: service: | [SERVICE] Flush 45 Grace 30 Log_Level error Daemon off Parsers_File parsers.conf storage.path /var/fluent-bit/state/flb-storage/ storage.sync normal storage.checksum off storage.backlog.mem_limit 5M
Contoh konfigurasi berikut mencakup conf
file bit Fluent tambahan. Dalam contoh ini, kami menambahkan kustom my-service.conf
di bawah extraFiles
dan itu akan disertakan di samping tiga defaultextraFiles
.
containerLogs: fluentBit: config: extraFiles: my-service.conf: | [INPUT] Name tail Tag myservice.* Path /var/log/containers/*myservice*.log DB /var/fluent-bit/state/flb_myservice.db Mem_Buf_Limit 5MB Skip_Long_Lines On Ignore_Older 1d Refresh_Interval 10 [OUTPUT] Name cloudwatch_logs Match myservice.* region ${AWS_REGION} log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice log_stream_prefix ${HOST_NAME}- auto_create_group true
Contoh berikutnya menghapus conf
file yang ada seluruhnya dariextraFiles
. Ini mengecualikan application-log.conf
seluruhnya dengan mengesampingkannya dengan string kosong. Cukup menghilangkan application-log.conf
dari extraFiles
akan menyiratkan untuk menggunakan default, yang bukan apa yang kami coba capai dalam contoh ini. Hal yang sama berlaku untuk menghapus conf
file kustom apa pun yang mungkin telah Anda tambahkan sebelumnyaextraFiles
.
containerLogs: fluentBit: config: extraFiles: application-log.conf: ""
Kelola toleransi Kubernetes untuk beban kerja pod yang diinstal
Dimulai dengan versi 1.7.0 dari add-on Amazon CloudWatch Observability EKS, add-on dan bagan Helm secara default menetapkan toleransi Kubernetes untuk mentolerir semua taint pada beban kerja pod yang diinstal oleh add-on atau bagan Helm. Ini memastikan bahwa daemonset seperti CloudWatch agen dan Fluent Bit dapat menjadwalkan pod pada semua node di cluster Anda secara default. Untuk informasi selengkapnya tentang toleransi dan noda, lihat Taints and Tolerations dalam dokumentasi
Toleransi default yang ditetapkan oleh add-on atau bagan Helm adalah sebagai berikut:
tolerations: - operator: Exists
Anda dapat mengganti toleransi default dengan menyetel tolerations
bidang di tingkat root saat menggunakan konfigurasi lanjutan add-on atau saat Anda menginstal atau memutakhirkan bagan Helm dengan penggantian nilai. Contohnya akan terlihat seperti berikut:
tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"
Untuk menghilangkan toleransi sepenuhnya, Anda dapat menggunakan konfigurasi yang terlihat seperti berikut:
tolerations: []
Setiap perubahan toleransi berlaku untuk semua beban kerja pod yang diinstal oleh add-on atau bagan Helm.
Menyisih dari koleksi metrik komputasi yang dipercepat
Secara default, Container Insights dengan observabilitas yang ditingkatkan mengumpulkan metrik untuk pemantauan Accelerated Compute, termasuk metrik GPU NVIDIA, metrik AWS Neuron untuk AWS Trainium dan Inferentia, dan metrik AWS Elastic Fabric Adapter (EFA). AWS
Metrik GPU NVIDIA dari beban kerja Amazon EKS dikumpulkan secara default dimulai dengan versi v1.3.0-eksbuild.1
add-on EKS atau bagan Helm dan versi agen. 1.300034.0
CloudWatch Untuk daftar metrik yang dikumpulkan dan prasyarat, lihat. Metrik GPU NVIDIA
AWS Metrik neuron untuk akselerator AWS Trainium dan AWS Inferentia dikumpulkan secara default dimulai dengan versi v1.5.0-eksbuild.1
add-on EKS atau bagan Helm, dan versi agen. 1.300036.0
CloudWatch Untuk daftar metrik yang dikumpulkan dan prasyarat, lihat. AWS Metrik neuron untuk AWS Trainium dan Inferensia AWS
AWS Metrik Elastic Fabric Adapter (EFA) dari node Linux di kluster Amazon EKS dikumpulkan secara default dimulai dengan versi v1.5.2-eksbuild.1
add-on EKS atau bagan Helm dan versi agen. 1.300037.0
CloudWatch Untuk daftar metrik yang dikumpulkan dan prasyarat, lihat. AWS Metrik Elastic Fabric Adapter (EFA)
Anda dapat memilih untuk tidak mengumpulkan metrik ini dengan menyetel accelerated_compute_metrics
bidang dalam file konfigurasi CloudWatch agen. false
Bidang ini ada di kubernetes
bagian metrics_collected
bagian dalam file CloudWatch konfigurasi. Berikut ini adalah contoh konfigurasi opt-out. Untuk informasi selengkapnya tentang cara menggunakan konfigurasi CloudWatch agen kustom, lihat bagian berikut. Gunakan konfigurasi CloudWatch agen khusus
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true, "accelerated_compute_metrics": false } } } }
Gunakan konfigurasi CloudWatch agen khusus
Untuk mengumpulkan metrik, log, atau jejak lain menggunakan CloudWatch agen, Anda dapat menentukan konfigurasi khusus sambil juga mengaktifkan Wawasan Kontainer dan Sinyal CloudWatch Aplikasi. Untuk melakukannya, sematkan file konfigurasi CloudWatch agen di dalam kunci konfigurasi di bawah kunci agen dari konfigurasi lanjutan yang dapat Anda gunakan saat membuat atau memperbarui add-on EKS atau bagan Helm. Berikut ini merupakan konfigurasi agen default ketika Anda tidak memberikan konfigurasi tambahan apa pun.
penting
Konfigurasi kustom apa pun yang Anda berikan menggunakan pengaturan konfigurasi tambahan akan menggantikan konfigurasi default yang digunakan oleh agen. Berhati-hatilah untuk tidak menonaktifkan fungsionalitas yang diaktifkan secara default secara tidak sengaja, seperti Wawasan Kontainer dengan peningkatan observabilitas dan Sinyal Aplikasi. CloudWatch Dalam skenario bahwa Anda diminta untuk menyediakan konfigurasi agen kustom, kami sarankan menggunakan konfigurasi default berikut sebagai dasar dan kemudian memodifikasinya sesuai dengan itu.
Untuk menggunakan add-on EKS CloudWatch observabilitas Amazon
--configuration-values '{ "agent": { "config": { "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } } }'
-
Untuk menggunakan bagan Helm
--set agent.config='{ "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } }'
Contoh berikut menunjukkan konfigurasi agen default untuk CloudWatch agen di Windows. CloudWatch Agen di Windows tidak mendukung konfigurasi khusus.
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true }, } } }
Kelola sertifikat TLS webhook penerimaan
Add-on Amazon CloudWatch Observability EKS dan bagan Helm memanfaatkan webhook masukInstrumentation
kustom (CR), dan secara opsional permintaan pod AmazonCloudWatchAgent
Kubernetes di klaster jika Application Signals diaktifkan. CloudWatch Di Kubernetes, webhook memerlukan sertifikat TLS yang dikonfigurasi oleh server API untuk dipercaya untuk memastikan komunikasi yang aman.
Secara default, add-on Amazon CloudWatch Observability EKS dan bagan Helm secara otomatis menghasilkan CA yang ditandatangani sendiri dan sertifikat TLS yang ditandatangani oleh CA ini untuk mengamankan komunikasi antara server API dan server webhook. Sertifikat yang dibuat secara otomatis ini memiliki kedaluwarsa default 10 tahun dan tidak diperpanjang secara otomatis setelah kedaluwarsa. Selain itu, bundel CA dan sertifikat dibuat ulang setiap kali add-on atau bagan Helm ditingkatkan atau diinstal ulang, sehingga mengatur ulang kedaluwarsa. Jika ingin mengubah kedaluwarsa default sertifikat yang dibuat secara otomatis, Anda dapat menggunakan konfigurasi tambahan berikut saat membuat atau memperbarui add-on. Ganti expiry-in-days
dengan durasi kedaluwarsa yang Anda inginkan dalam beberapa hari.
Gunakan ini untuk add-on Amazon CloudWatch Observability EKS
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays":
expiry-in-days
} } }'Gunakan ini untuk bagan Helm
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
Untuk solusi otoritas sertifikat yang lebih aman dan kaya fitur, add-on ini memiliki dukungan opt-in untuk cert-manager
Kami menyarankan Anda meninjau praktik terbaik untuk pengelolaan sertifikat TLS di klaster Anda dan menyarankan Anda untuk ikut serta dalam pengelola sertifikat untuk lingkungan produksi. Perhatikan bahwa jika Anda memilih untuk mengaktifkan cert-manager untuk mengelola sertifikat TLS webhook penerimaan, Anda harus melakukan pra-instal cert-manager di klaster Amazon EKS sebelum menginstal add-on Amazon Observability EKS atau bagan Helm. CloudWatch Untuk informasi selengkapnya tentang opsi penginstalan yang tersedia, lihat dokumentasi pengelola sertifikat
Jika Anda menggunakan add-on Amazon CloudWatch Observability EKS
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
Jika Anda menggunakan bagan Helm
--set admissionWebhooks.certManager.enabled=true
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
Konfigurasi lanjutan yang dibahas di bagian ini secara default akan menggunakan SelfSigned
Kumpulkan volume Amazon EBS IDs
Jika ingin mengumpulkan volume Amazon EBS IDs di log kinerja, Anda harus menambahkan kebijakan lain ke peran IAM yang dilampirkan ke node pekerja atau ke akun layanan. Tambahkan hal berikut sebagai kebijakan selaras. Untuk informasi selengkapnya, silakan lihat Menambahkan dan Menghapus Izin Identitas IAM.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeVolumes" ], "Resource": "*", "Effect": "Allow" } ] }
Kumpulkan metrik Java Management Extensions (JMX)
CloudWatch Agen mendukung koleksi metrik Java Management Extensions (JMX) di Amazon EKS. Ini memungkinkan Anda mengumpulkan metrik tambahan dari aplikasi Java yang berjalan di kluster Amazon EKS yang memungkinkan wawasan tentang kinerja, penggunaan memori, lalu lintas, dan metrik penting lainnya. Untuk informasi selengkapnya, lihat Kumpulkan metrik Java Management Extensions (JMX).
Aktifkan metrik Kueue
Dimulai dengan versi v2.4.0-eksbuild.1
add-on CloudWatch Observability EKS, Container Insights untuk Amazon EKS mendukung pengumpulan metrik Kueue dari kluster Amazon EKS. Untuk informasi selengkapnya tentang metrik ini, lihat Metrik Kueue .
Jika Anda menggunakan add-on Amazon SageMaker AI Hyperpod Task Governance EKS, Anda dapat melewati langkah-langkah di bagian Prasyarat dan cukup ikuti langkah-langkahnya. Aktifkan flag konfigurasi
Prasyarat
Sebelum Anda menginstal Kueue di kluster Amazon EKS Anda, buat pembaruan berikut di file manifes:
Aktifkan metrik sumber daya antrian cluster opsional untuk Kueue. Untuk melakukan ini, ubah in-line
controller_manager_config.yaml
di.kueue-system
ConfigMap Dimetrics
bagian tersebut, tambahkan atau hapus komentar pada barisenableClusterQueueResources: true
.apiVersion: v1 data: controller_manager_config.yaml: | apiVersion: config.kueue.x-k8s.io/v1beta1 kind: Configuration health: healthProbeBindAddress: :8081 metrics: bindAddress: :8080 enableClusterQueueResources: true
<-- ADD/UNCOMMENT THIS LINE
Secara default, semua
k8s
layanan tersedia di seluruh cluster. Kueue membuat layanankueue-controller-manager-metrics-service
untuk mengekspos metrik. Untuk mencegah duplikat pengamatan metrik, modifikasi layanan ini untuk mengizinkan akses hanya ke layanan metrik dari node yang sama. Untuk melakukan ini, tambahkan barisinternalTrafficPolicy: Local
kekueue-controller-manager-metrics-service
definisi.apiVersion: v1 kind: Service metadata: labels: ... name: kueue-controller-manager-metrics-service namespace: kueue-system spec: ports: - name: https port: 8443 protocol: TCP targetPort: https internalTrafficPolicy: Local
<-- ADD THIS LINE
selector: control-plane: controller-managerTerakhir,
kueue-controller-manager
pod membuatkube-rbac-proxy
wadah. Wadah ini saat ini memiliki tingkat verbositas logging yang tinggi, yang menyebabkan token pembawa cluster dicatat oleh wadah itu ketika pengikis metrik mengakses.kueue-controller-manager-metrics-service
Kami menyarankan Anda mengurangi verbositas logging ini. Nilai default dalam manifes yang didistribusikan oleh Kueue adalah 10, kami sarankan untuk mengubahnya menjadi 0.apiVersion: apps/v1 kind: Deployment metadata: labels: ... name: kueue-controller-manager namespace: kueue-system spec: ... template: ... spec: containers: ... - args: - --secure-listen-address=0.0.0.0:8443 - --upstream=http://127.0.0.1:8080/ - --logtostderr=true - --v=0
<-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0 name: kube-rbac-proxy ...
Aktifkan flag konfigurasi
Untuk mengaktifkan metrik Kueue, Anda harus mengaktifkan kueue_container_insights
konfigurasi tambahan add-on. Anda dapat melakukan ini baik dengan menggunakan AWS CLI untuk mengatur add-on EKS Observability, atau dengan menggunakan konsol Amazon EKS.
Setelah Anda berhasil menginstal add-on EKS Observability dengan salah satu metode berikut, Anda dapat melihat metrik klaster Amazon EKS di bawah tab Dasbor HyperPod konsol.
Menambahkan file konfigurasi OpenTelemetry kolektor
CloudWatch Agen mendukung file konfigurasi OpenTelemetry kolektor tambahan di samping file konfigurasinya sendiri. Fitur ini memungkinkan Anda untuk menggunakan fitur CloudWatch agen seperti Sinyal CloudWatch Aplikasi atau Wawasan Kontainer melalui konfigurasi CloudWatch agen dan membawa konfigurasi OpenTelemetry kolektor yang ada dengan satu agen.
Untuk mencegah konflik gabungan dengan saluran pipa yang dibuat secara otomatis oleh CloudWatch agen, kami sarankan Anda menambahkan akhiran khusus ke setiap komponen dan saluran pipa dalam konfigurasi kolektor Anda. OpenTelemetry Ini akan mencegah bentrokan dan menggabungkan konflik.
Jika Anda menggunakan add-on Amazon CloudWatch Observability EKS
--configuration-values file://values.yaml
atau
--configuration-values ' agent: otelConfig: receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
Jika Anda menggunakan bagan Helm
--set agent.otelConfig=' receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
Mengonfigurasi Sinyal Aplikasi untuk klaster Amazon EKS Anda
Sinyal Aplikasi diaktifkan secara default saat menginstal add-on CloudWatch Observability EKS atau bagan Helm. Anda dapat menyesuaikan pengaturan spesifik lebih lanjut menggunakan konfigurasi lanjutan untuk add-on Amazon EKS atau dengan mengganti nilai dengan bagan Helm.
Sinyal Aplikasi Monitor otomatis
Versi 4.0.0 dari add-on Amazon EKS CloudWatch Observability dan bagan Helm memperkenalkan fungsionalitas baru. Anda sekarang dapat secara otomatis mengaktifkan Sinyal Aplikasi untuk semua atau beban kerja layanan tertentu di kluster EKS Anda melalui konfigurasi monitor Otomatis. autoMonitor
Pengaturan berikut dapat ditentukan dalam applicationSignals
bagian di bawah manager
bagian konfigurasi lanjutan.
monitorAllServices— Bendera boolean untuk mengaktifkan (true) atau menonaktifkan pemantauan (false) semua beban kerja layanan oleh monitor Otomatis. Default ke false. Mengaktifkan flag ini akan memastikan bahwa semua beban kerja Kubernetes (Deployment DaemonSets, dan StatefulSets) di klaster yang dipetakan ke Layanan Kubernetes akan berada dalam lingkup untuk mengaktifkan Sinyal Aplikasi secara otomatis ketika mereka muncul untuk pertama kalinya (atau ketika dimulai ulang untuk beban kerja yang ada). Sistem mengecualikan beban kerja di
amazon-cloudwatch
ruang namakube-system
dan secara default.bahasa — Daftar string yang menentukan kumpulan bahasa yang akan coba digunakan oleh Sinyal Aplikasi untuk menginstruksikan layanan Anda secara otomatis, saat
monitorAllServices
diaktifkan. Default untuk semua bahasa yang didukung.RestartPods - Bendera boolean mengontrol apakah beban kerja dimulai ulang setelah perubahan konfigurasi. Default ke false. Mengaktifkan flag ini untuk
true
mengontrol apakah beban kerja Kubernetes dalam lingkup monitor otomatis restart secara otomatis saat menyimpan perubahan konfigurasi. Pengaturan apa pun pada beban kerja Kubernetes Anda yang memengaruhi restart pod sepertiupdateStrategy
akan dipertimbangkan. Pertimbangkan bahwa memulai ulang dapat menyebabkan downtime layanan.CustomSelector — Pengaturan untuk memilih namespace Kubernetes tertentu atau beban kerja untuk monitor Otomatis.
java - Tentukan beban kerja untuk instrumen secara otomatis dengan Java
python - Tentukan beban kerja untuk instrumen secara otomatis dengan Python
nodejs - Tentukan beban kerja untuk instrumen secara otomatis dengan Node.js
dotnet - Tentukan beban kerja untuk instrumen secara otomatis dengan.NET
Untuk setiap bahasa di atas, bidang berikut dapat dikonfigurasi.
namespaces — Daftar string yang menentukan ruang nama yang akan dipilih. Default ke daftar kosong, yaitu []
deployments — Daftar string yang menentukan penerapan yang akan dipilih. Tentukan dalam
namespace/deployment
format. Default ke daftar kosong, yaitu []daemonsets — Daftar string yang menentukan daemonset yang akan dipilih. Tentukan dalam
namespace/daemonset
format. Default ke daftar kosong, yaitu []statefulsets - Daftar string yang menentukan statefulsets yang akan dipilih. Tentukan dalam
namespace/statefulset
format. Default ke daftar kosong, yaitu []
exclude — Pengaturan untuk mengecualikan ruang nama atau beban kerja Kubernetes tertentu dari monitor Otomatis. Mengecualikan beban kerja diutamakan ketika beban kerja yang sama juga berada dalam lingkup atau.
monitorAllServices
customSelector
java - Tentukan beban kerja untuk dikecualikan agar tidak diinstrumentasi secara otomatis dengan Java
python - Tentukan beban kerja yang akan dikecualikan agar tidak diinstrumentasi secara otomatis dengan Python
nodejs - Tentukan beban kerja untuk mengecualikan agar tidak diinstrumentasi secara otomatis dengan Node.js
dotnet - Tentukan beban kerja yang akan dikecualikan agar tidak diinstrumentasi secara otomatis dengan.NET
Untuk setiap bahasa di atas, bidang berikut dapat dikonfigurasi.
namespaces — Daftar string yang menentukan ruang nama yang akan dikecualikan. Default ke daftar kosong, yaitu []
deployments — Daftar string yang menentukan penerapan yang akan dikecualikan. Tentukan dalam
namespace/deployment
format. Default ke daftar kosong, yaitu []daemonsets — Daftar string yang menentukan daemonset yang akan dikecualikan. Tentukan dalam
namespace/daemonset
format. Default ke daftar kosong, yaitu []statefulsets - Daftar string yang menentukan statefulsets yang akan dikecualikan. Tentukan dalam
namespace/statefulset
format. Default ke daftar kosong, yaitu []
Berikut ini adalah contoh konfigurasi yang secara otomatis mengaktifkan Sinyal Aplikasi untuk semua beban kerja layanan yang ada dan yang baru di cluster.
manager: applicationSignals: autoMonitor: monitorAllServices: true restartPods: true
Berikut ini adalah contoh konfigurasi yang secara otomatis mengaktifkan Sinyal Aplikasi untuk setiap beban kerja layanan baru yang dimunculkan dan untuk setiap beban kerja layanan yang ada yang secara eksplisit dimulai ulang pada cluster.
manager: applicationSignals: autoMonitor: monitorAllServices: true
Berikut ini adalah contoh konfigurasi yang secara otomatis mengaktifkan Application Signals dengan Java untuk semua pod yang ada dan baru yang sesuai dengan beban kerja di pet-warehouse
namespace.
manager: applicationSignals: autoMonitor: restartPods: true customSelector: java: namespaces: ["pet-warehouse"]
Berikut ini adalah contoh konfigurasi yang secara otomatis mengaktifkan Sinyal Aplikasi dengan Python untuk semua beban kerja layanan yang ada dan baru di cluster tidak termasuk penerapan. pet-clinic
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["python"] restartPods: true exclude: python: deployments: ["pet-warehouse/pet-clinic"]
Berikut ini adalah contoh konfigurasi yang secara otomatis mengaktifkan Sinyal Aplikasi dengan Java untuk semua beban kerja layanan di cluster kecuali yang ada di python-apps
namespace dan selanjutnya memungkinkan Sinyal Aplikasi dengan Python khusus untuk penyebaran di sample-python-app
namespace. python-apps
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["java"] restartPods: true customSelector: python: deployments: ["python-apps/sample-python-app"] exclude: java: namespaces: ["python-apps"]
Memecahkan masalah add-on Amazon CloudWatch Observability EKS atau bagan Helm
Gunakan informasi berikut untuk membantu memecahkan masalah dengan add-on Amazon CloudWatch Observability EKS atau bagan Helm
Topik
Memperbarui dan menghapus add-on Amazon CloudWatch Observability EKS atau bagan Helm
Untuk petunjuk tentang memperbarui atau menghapus add-on Amazon CloudWatch Observability EKS, lihat Mengelola add-on Amazon EKS. Gunakan amazon-cloudwatch-observability
sebagai nama add-on.
Untuk menghapus bagan Helm dalam sebuah cluster, masukkan perintah berikut.
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
Verifikasi versi CloudWatch agen yang digunakan oleh add-on Amazon CloudWatch Observability EKS atau bagan Helm
Add-on Amazon CloudWatch Observability EKS dan bagan Helm menginstal jenis sumber daya khusus AmazonCloudWatchAgent
yang mengontrol perilaku daemonset CloudWatch agen di cluster, termasuk versi agen yang digunakan. CloudWatch Anda bisa mendapatkan daftar semua sumber daya AmazonCloudWatchAgent
kustom yang diinstal pada klaster Anda dengan memasukkan perintah berikut:
kubectl get amazoncloudwatchagent -A
Dalam output perintah ini, Anda harus dapat memeriksa versi CloudWatch agen. Atau, Anda juga dapat mendeskripsikan sumber daya amazoncloudwatchagent
atau salah satu pod cloudwatch-agent-*
yang berjalan di klaster Anda untuk memeriksa citra yang digunakan.
Menangani a ConfigurationConflict saat mengelola add-on atau bagan Helm
Saat Anda menginstal atau memperbarui add-on Amazon CloudWatch Observability EKS atau bagan Helm, jika Anda melihat kegagalan yang disebabkan oleh sumber daya yang ada, kemungkinan besar karena Anda sudah memiliki CloudWatch agen dan komponen terkait seperti ServiceAccount, ClusterRole dan yang ClusterRoleBinding diinstal pada cluster.
Kesalahan yang ditampilkan oleh add-on akan mencakupConflicts found when trying to apply. Will not continue due to resolve conflicts mode
,
Kesalahan yang ditampilkan oleh bagan Helm akan mirip Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.
dengan.
Ketika add-on atau bagan Helm mencoba menginstal CloudWatch agen dan komponen terkaitnya, jika mendeteksi perubahan apa pun dalam konten, secara default gagal instalasi atau pembaruan untuk menghindari penimpaan status sumber daya di cluster.
Jika Anda mencoba melakukan onboard ke add-on Amazon CloudWatch Observability EKS dan Anda melihat kegagalan ini, sebaiknya hapus penyiapan CloudWatch agen yang sudah ada yang sebelumnya Anda instal di cluster dan kemudian menginstal add-on EKS atau bagan Helm. Pastikan untuk mencadangkan penyesuaian apa pun yang mungkin telah Anda buat ke penyiapan CloudWatch agen asli seperti konfigurasi agen khusus, dan berikan ini ke bagan add-on atau Helm saat Anda menginstal atau memperbaruinya berikutnya. Jika sebelumnya Anda telah menginstal CloudWatch agen untuk orientasi ke Container Insights, lihat Menghapus CloudWatch agen dan Fluent Bit untuk Wawasan Kontainer untuk informasi selengkapnya.
Atau, add-on mendukung opsi konfigurasi resolusi konflik yang memiliki kemampuan untuk menentukan OVERWRITE
. Anda dapat menggunakan opsi ini untuk melanjutkan dengan melakukan instalasi atau memperbarui add-on dengan menimpa konflik di klaster. Jika Anda menggunakan konsol Amazon EKS, Anda akan menemukan Metode penyelesaian konflik saat Anda memilih Pengaturan konfigurasi opsional ketika Anda membuat atau memperbarui add-on. Jika Anda menggunakan AWS CLI, Anda dapat memberikan perintah Anda --resolve-conflicts OVERWRITE
untuk membuat atau memperbarui add-on.