Logs in a Managed Kubernetes cluster
Managed Kubernetes clusters can receive logs — cluster logs, container logs, and audit logs.
The cluster logs display events that happen to the cluster. For example, creating a cluster, changing node groups, updating certificates and versions. If a request was executed automatically, for example, a scheduled certificate update occurred, this action will also be included in the logs. You can view the cluster logs in the Event Log in the Control Panel.
Container logs include events that happen to containers. For example, the creation and deletion of a container. Container log files are stored in /var/log/pods/
or /var/log/containers
. You can view the logs
of an individual container using kubectl logs <container_name>
, where <container_name>
is the container name. If there are many containers in a Managed Kubernetes cluster, you can configure to receive container logs via Filebeat.
Audit logs display events that occur in the cluster. For example, in pods or services. These events can be triggered by users, applications, or Control Plane. The list of events that are logged and the parameters of these events depend on the audit policy. The policy that applies to Managed Kubernetes audit logs can be found in the Selectel documentation on the GitHub site.
Audit logs can be stored in a log storage and analysis system. For example, in external data stores (for example, Elasticsearch or Stackdriver) or in a SIEM system (for example, MaxPatrol SIEM or KUMA). To receive audit logs from the Managed Kubernetes cluster in a log storage and analysis system, configure the integration.
View cluster logs
-
In the dashboard, on the top menu, click Products and select Managed Kubernetes.
-
Open the cluster page → Event Log tab.
-
View the status of cluster events in the Event row → Status column.
Configure container logs to be received via Filebeat
Filebeat is configured to work with Docker by default. In Selectel, instead of Docker as the container execution environment ( CRI) is used as the container execution environment ( CRI ) containerd.
To configure the mechanism for retrieving log metadata via Filebeat, use the configuration file:
filebeat.inputs:
- type: container
fields_under_root: true
paths:
- "/var/log/containers/*.log"
processors:
- add_kubernetes_metadata:
host: ${NODE_NAME}
in_cluster: true
default_matchers.enabled: false
matchers:
- logs_path:
logs_path: "/var/log/containers/"
Set up integration with log storage and analysis system
Audit logs are available in clusters with Kubernetes version 1.28 and higher. In Managed Kubenretes clusters on cloud servers, you can upgrade the cluster version. Audit logs are not available during a version upgrade.
- Check the system for storing and analyzing logs.
- Enable audit logs — when creating a cluster or in an existing cluster.
- Connect to the cluster.
- Configure the export of audit logs to the log storage and analysis system.
1. Check the log storage and analysis system
Ensure that the log storage and analysis system is accessible via HTTPS and has TLS connection termination configured.
2. Enable audit logs in an existing cluster
- In the dashboard, on the top menu, click Products and select Managed Kubernetes.
- Open the cluster page → Settings tab.
- In the Logging block, enable the Audit Logs toggle switch.
3. Connect to the cluster
Use the Connect to Cluster instructions for the desired operating system.
4. Configure export of audit logs to the log storage and analysis system
Audit logs will begin to be transferred to the log storage and analysis system after the Secret object is created.
-
Create a yaml file with a manifest for the Secret object:
apiVersion: v1
kind: Secret
metadata:
name: mks-audit-logs
data:
host: <host>
port: <port>
username: <username>
password: <password>
ca.crt: <ca_certificate>Specify:
<host>
— DNS or IP address of the log storage and analysis system;<port>
— port to connect to the log storage and analysis system;- optional:
<username>
— user name of the log storage and analysis system; - optional:
<
password>
— user password of the log storage and analysis system; - optional:
<ca_certificate>
— certificate from a private certificate authority (CA). If a Let's Encrypt certificate is used for the connection, this parameter does not need to be filled in.
-
Apply the manifest and create a Secret object in the
kube-system
namespace:kubectl apply -f <secret.yaml> --namespace=kube-system
Specify
<secret.yaml>
is the name of the yaml file with the manifest to create a new Secret object. -
Check that the Secret object has been created:
kubectl get secret mks-audit-logs --output=yaml --namespace=kube-system