Logs in a Managed Kubernetes cluster

In Managed Kubernetes clusters, you can retrieve:

cluster logs;
container logs;
pod and service logs (audit logs).

Cluster logs

Cluster logs display events that occur in the cluster. For example, cluster creation, node group changes, or certificate and version updates. If a request was performed automatically, for example, a scheduled certificate update occurred, this action will also appear in the logs. You can:

view cluster logs in the event log;
export audit logs in the Audit Logs service.

Logs in the Audit Logs service are more detailed than those in the event log. A full list of events in the Audit Logs service can be found in the MKS service subsection of the Audit events guide.

View cluster logs in the event log

In the control panel, on the top menu, click Products and select Managed Kubernetes.
Open the cluster page → Event Log tab.

Check the status of cluster events in the event row → Status column.

IN_PROGRESS	Event is in progress
IN_QUEUE	Event is queued. The event is expected to complete with the `IN_PROGRESS` status
CANCELED	Event is canceled
ERROR	An error occurred. If the cause of the error is insufficient project quotas, increase the quotas. If the cause is not specified, create a ticket.
DONE	Event completed successfully

Export audit logs in the Audit Logs service

Use the instructions in the Exporting audit logs.

Container logs

Container logs contain events that occur with containers. For example, container creation and deletion. Log files are stored in the /var/log/pods/ or /var/log/containers directory. 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 your Managed Kubernetes cluster, you can configure container logs to be received via Filebeat.

Configure container logs to be received via Filebeat

Filebeat is configured to work with Docker by default. In Servercore, containerd is used instead of Docker as the container runtime (CRI).

To configure the mechanism for receiving 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/"

Pod and service logs (audit logs)

Audit logs display events occurring within the cluster, for example, in pods or services. These events may be initiated by users, applications, or the Control Plane. The list of events included in the logs and their parameters depend on the policy. Learn more about the policy in the Audit policy section of the Auditing article in the Kubernetes documentation.

Audit logs can be sent to log storage and analysis systems, such as:

external data storage, e.g., Elasticsearch or Stackdriver;
or SIEM systems, e.g., MaxPatrol SIEM or KUMA.

To receive audit logs from a Managed Kubernetes cluster into a log storage and analysis system, configure the integration.

Configure integration with a log storage and analysis system

Audit logs are available for clusters with Kubernetes version 1.28 and higher. For Managed Kubernetes clusters on cloud servers, you can upgrade the cluster version. Audit logs are unavailable during the version upgrade.

Check the log storage and analysis system.
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

Make sure that your log storage and analysis system is accessible via HTTPS and that TLS connection termination is configured for it.

2. Enable audit logs in an existing cluster

In the control panel, on the top menu, click Products and select Managed Kubernetes.
Open the cluster page → Settings tab.
In the Logging block, turn on the Audit logs toggle.

3. Connect to the cluster

Follow the Connect to a cluster guide for your operating system.

4. Configure the export of audit logs to the log storage and analysis system

Audit logs will start being sent to the log storage and analysis system once a 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> — the DNS or IP address of the log storage and analysis system;
- <port> — the port to connect to the log storage and analysis system;
- optionally: <username> — the username for the log storage and analysis system;
- optionally: <password> — the password for the log storage and analysis system;
- optionally: <ca_certificate> — the certificate from a private certificate authority (CA). If using a Let's Encrypt certificate for the connection, you do not need to fill in this parameter.
Apply the manifest and create the Secret object in the kube-system namespace:
```
kubectl apply -f <file_name> --namespace=kube-system
```
Specify <file_name> — the name of the yaml file with the manifest for creating the new Secret object. For example, secret.yaml.

Check that the Secret object has been created:

kubectl get secret mks-audit-logs --output=yaml --namespace=kube-system