Let us review the sink architecture in PKS. This consists of a log sink for monitoring the cluster and namespace logs and a metric sink for monitoring the cluster metrics. The log sink and metric sink therefore serve different purposes although the data may appear in common json format. These resources have to be enabled using the observability manager.
The log architecture forwards them to a common log destination. The forwarding of logs is done with the help of Fluent-bit where a daemon running as a pod on a single node aggregates the events. In addition to logs thus collected, the event collector collects Kubernetes API events and a sink collector handles CRD events pertaining to fluent-bit configmaps. The event collector and sink collector are hosted independently. All aggregated events are then forwarded to the common log destination.
The metrics architecture is also similar with kubelets producing metrics but differs in two different aspects. Instead of the fluent bit forwarding the aggregated events to a common log destination, a plugin is required to forward them to the common metrics destination. The second difference is that there is no sink collector for metrics. Even the CRD events are handled by the metrics controller and only the telegraf is responsible for forwarding metrics.
The sink architecture in PKS is merely for automation. It does not prevent the direct access of logs and configuration for the clusters. If the cluster logs were to be downloaded, the following steps would be necessary.
We gather the credential and IP address information for the. BOSH Director, SSH into the Ops Manager VM, and use the BOSH CLI v2+ to log in to the BOSH Director from the Ops Manager VM. We mention the name of the deployment and list all of the virtual machines. We choose a virtual machine and download the logs from it by specifying the “logs” command line argument.
The sink architecture is also useful for monitoring. The logs and events are combined in a shared format which provides operators with a robust set of monitoring and filtering options. All the entries of the sink data are timestamped, contain the host ID, and are annotated with the namespaces, pod ID and container name. The logs are distinguished by the App-Name field.
The Kubernetes API event entries are distinguished by “k8s.event” in the App-Name field. Strings like “ Error:ErrImagePull”, “Back-off restarting failed container”, and “Started container” help query the events for determining the cause of failure or the time of success.
A sink resource enables PKS users to configure destinations for logs transported following the Syslog Protocol defined in RFC 5424. This resource is dependent on the IaaS infrastructure. The sink resource needs to be enabled because it is not on by default. As with service brokers, sinks are created for cluster and namespace scopes. They don’t use namespace, bucket, resource hierarchy. The “create-sink” command is used to
The log architecture forwards them to a common log destination. The forwarding of logs is done with the help of Fluent-bit where a daemon running as a pod on a single node aggregates the events. In addition to logs thus collected, the event collector collects Kubernetes API events and a sink collector handles CRD events pertaining to fluent-bit configmaps. The event collector and sink collector are hosted independently. All aggregated events are then forwarded to the common log destination.
The metrics architecture is also similar with kubelets producing metrics but differs in two different aspects. Instead of the fluent bit forwarding the aggregated events to a common log destination, a plugin is required to forward them to the common metrics destination. The second difference is that there is no sink collector for metrics. Even the CRD events are handled by the metrics controller and only the telegraf is responsible for forwarding metrics.
The sink architecture in PKS is merely for automation. It does not prevent the direct access of logs and configuration for the clusters. If the cluster logs were to be downloaded, the following steps would be necessary.
We gather the credential and IP address information for the. BOSH Director, SSH into the Ops Manager VM, and use the BOSH CLI v2+ to log in to the BOSH Director from the Ops Manager VM. We mention the name of the deployment and list all of the virtual machines. We choose a virtual machine and download the logs from it by specifying the “logs” command line argument.
The sink architecture is also useful for monitoring. The logs and events are combined in a shared format which provides operators with a robust set of monitoring and filtering options. All the entries of the sink data are timestamped, contain the host ID, and are annotated with the namespaces, pod ID and container name. The logs are distinguished by the App-Name field.
The Kubernetes API event entries are distinguished by “k8s.event” in the App-Name field. Strings like “ Error:ErrImagePull”, “Back-off restarting failed container”, and “Started container” help query the events for determining the cause of failure or the time of success.
A sink resource enables PKS users to configure destinations for logs transported following the Syslog Protocol defined in RFC 5424. This resource is dependent on the IaaS infrastructure. The sink resource needs to be enabled because it is not on by default. As with service brokers, sinks are created for cluster and namespace scopes. They don’t use namespace, bucket, resource hierarchy. The “create-sink” command is used to
No comments:
Post a Comment