mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-25 06:08:29 +00:00
Catherine Luse
GitHub
@@ -34,54 +34,80 @@ weight: 3
|
||||
|
||||
### Kubernetes Version
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
For more information on GKE Kubernetes versions, refer to [these docs.](https://cloud.google.com/kubernetes-engine/versioning)
|
||||
|
||||
### Container Address Range
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The IP address range for pods in the cluster. Must be a valid CIDR range, e.g. 10.42.0.0/16. If not specified, a random range is automatically chosen from 10.0.0.0/8 and will exclude ranges already allocated to VMs, other clusters, or routes. Automatically chosen ranges may conflict with reserved IP addresses, dynamic routes, or routes within VPCs peering with the cluster.
|
||||
|
||||
### Network
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The Compute Engine Network that the cluster connects to. Routes and firewalls will be created using this network. If using [Shared VPCs](https://cloud.google.com/vpc/docs/shared-vpc), the VPC networks that are shared to your project will appear here. will be available to select in this field. For more information, refer to [this page](https://cloud.google.com/vpc/docs/vpc#vpc_networks_and_subnets).
|
||||
|
||||
### Node Subnet / Subnet
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The Compute Engine subnetwork that the cluster connects to. This subnetwork must belong to the network specified in the **Network** field. Select an existing subnetwork, or select "Auto Create Subnetwork" to have one automatically created. If not using an existing network, **Subnetwork Name** is required to generate one. If using [Shared VPCs](https://cloud.google.com/vpc/docs/shared-vpc), the VPC subnets that are shared to your project will appear here. If using a Shared VPC network, you cannot select "Auto Create Subnetwork". For more information, refer to [this page.](https://cloud.google.com/vpc/docs/vpc#vpc_networks_and_subnets)
|
||||
|
||||
### Subnetwork Name
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Automatically create a subnetwork with the provided name. Required if "Auto Create Subnetwork" is selected for **Node Subnet** or **Subnet**. For more information on subnetworks, refer to [this page.](https://cloud.google.com/vpc/docs/vpc#vpc_networks_and_subnets)
|
||||
|
||||
### Ip Aliases
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Enable [alias IPs](https://cloud.google.com/vpc/docs/alias-ip). This enables VPC-native traffic routing. Required if using [Shared VPCs](https://cloud.google.com/vpc/docs/shared-vpc).
|
||||
|
||||
### Network Policy
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
Enable network policy enforcement on the cluster. A network policy defines the level of communication that can occur between pods and services in the cluster. For more information, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy)
|
||||
|
||||
### Node Ipv4 CIDR Block
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The IP address range of the instance IPs in this cluster. Can be set if "Auto Create Subnetwork" is selected for **Node Subnet** or **Subnet**. Must be a valid CIDR range, e.g. 10.96.0.0/14. For more information on how to determine the IP address range, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips#cluster_sizing)
|
||||
|
||||
### Cluster Secondary Range Name
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The name of an existing secondary range for Pod IP addresses. If selected, **Cluster Pod Address Range** will automatically be populated. Required if using a Shared VPC network.
|
||||
|
||||
### Cluster Pod Address Range
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The IP address range assigned to pods in the cluster. Must be a valid CIDR range, e.g. 10.96.0.0/11. If not provided, will be created automatically. Must be provided if using a Shared VPC network. For more information on how to determine the IP address range for your pods, refer to [this section.](https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips#cluster_sizing_secondary_range_pods)
|
||||
|
||||
### Services Secondary Range Name
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The name of an existing secondary range for service IP addresses. If selected, **Service Address Range** will be automatically populated. Required if using a Shared VPC network.
|
||||
|
||||
### Service Address Range
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The address range assigned to the services in the cluster. Must be a valid CIDR range, e.g. 10.94.0.0/18. If not provided, will be created automatically. Must be provided if using a Shared VPC network. For more information on how to determine the IP address range for your services, refer to [this section.](https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips#cluster_sizing_secondary_range_svcs)
|
||||
|
||||
### Private Cluster
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/gke/private-clusters/).
|
||||
|
||||
Assign nodes only internal IP addresses. Private cluster nodes cannot access the public internet unless additional networking steps are taken in GCP.
|
||||
@@ -90,14 +116,20 @@ Assign nodes only internal IP addresses. Private cluster nodes cannot access the
|
||||
|
||||
> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/gke/#private-clusters).
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Locks down external access to the control plane endpoint. Only available if **Private Cluster** is also selected. If selected, and if Rancher does not have direct access to the Virtual Private Cloud network the cluster is running in, Rancher will provide a registration command to run on the cluster to enable Rancher to connect to it.
|
||||
|
||||
### Master IPV4 CIDR Block
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The IP range for the control plane VPC.
|
||||
|
||||
### Master Authorized Network
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
Enable control plane authorized networks to block untrusted non-GCP source IPs from accessing the Kubernetes master through HTTPS. If selected, additional authorized networks may be added. If the cluster is created with a public endpoint, this option is useful for locking down access to the public endpoint to only certain networks, such as the network where your Rancher service is running. If the cluster only has a private endpoint, this setting is required.
|
||||
|
||||
# Additional Options
|
||||
@@ -108,31 +140,45 @@ Additional Kubernetes cluster components. For more information, refer to [this p
|
||||
|
||||
#### Horizontal Pod Autoscaling
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
The Horizontal Pod Autoscaler changes the shape of your Kubernetes workload by automatically increasing or decreasing the number of Pods in response to the workload's CPU or memory consumption, or in response to custom metrics reported from within Kubernetes or external metrics from sources outside of your cluster. For more information, see [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/horizontalpodautoscaler)
|
||||
|
||||
#### HTTP (L7) Load Balancing
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
HTTP (L7) Load Balancing distributes HTTP and HTTPS traffic to backends hosted on GKE. For more information, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer)
|
||||
|
||||
#### Network Policy Config (master only)
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
Configuration for NetworkPolicy. This only tracks whether the addon is enabled or not on the master, it does not track whether network policy is enabled for the nodes.
|
||||
|
||||
### Cluster Features (Alpha Features)
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Turns on all Kubernetes alpha API groups and features for the cluster. When enabled, the cluster cannot be upgraded and will be deleted automatically after 30 days. Alpha clusters are not recommended for production use as they are not covered by the GKE SLA. For more information, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/alpha-clusters)
|
||||
|
||||
### Logging Service
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
The logging service the cluster uses to write logs. Use either [Cloud Logging](https://cloud.google.com/logging) or no logging service in which case no logs are exported from the cluster.
|
||||
|
||||
### Monitoring Service
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
The monitoring service the cluster uses to write metrics. Use either [Cloud Monitoring](https://cloud.google.com/monitoring) or monitoring service in which case no metrics are exported from the cluster.
|
||||
|
||||
|
||||
### Maintenance Window
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
Set the start time for a 4 hour maintenance window. The time is specified in the UTC time zone using the HH:MM format. For more information, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/maintenance-windows-and-exclusions)
|
||||
|
||||
# Node Pools
|
||||
@@ -141,10 +187,14 @@ In this section, enter details describing the configuration of each node in the
|
||||
|
||||
### Kubernetes Version
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
The Kubernetes version for each node in the node pool. For more information on GKE Kubernetes versions, refer to [these docs.](https://cloud.google.com/kubernetes-engine/versioning)
|
||||
|
||||
### Image Type
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
The node operating system image. For more information for the node image options that GKE offers for each OS, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/node-images#available_node_images)
|
||||
|
||||
> Note: the default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [logging feature as of v2.5]({{<baseurl>}}/rancher/v2.5/en/logging) is compatible with the Container-Optimized OS image.
|
||||
@@ -153,26 +203,38 @@ The node operating system image. For more information for the node image options
|
||||
|
||||
### Machine Type
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
The virtualized hardware resources available to node instances. For more information on Google Cloud machine types, refer to [this page.](https://cloud.google.com/compute/docs/machine-types#machine_types)
|
||||
|
||||
### Root Disk Type
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Standard persistent disks are backed by standard hard disk drives (HDD), while SSD persistent disks are backed by solid state drives (SSD). For more information, refer to [this section.](https://cloud.google.com/compute/docs/disks)
|
||||
|
||||
### Local SSD Disks
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Configure each node's local SSD disk storage in GB. Local SSDs are physically attached to the server that hosts your VM instance. Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks. The data that you store on a local SSD persists only until the instance is stopped or deleted. For more information, see [this section.](https://cloud.google.com/compute/docs/disks#localssds)
|
||||
|
||||
### Preemptible nodes (beta)
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Preemptible nodes, also called preemptible VMs, are Compute Engine VM instances that last a maximum of 24 hours in general, and provide no availability guarantees. For more information, see [this page.](https://cloud.google.com/kubernetes-engine/docs/how-to/preemptible-vms)
|
||||
|
||||
### Taints
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
When you apply a taint to a node, only Pods that tolerate the taint are allowed to run on the node. In a GKE cluster, you can apply a taint to a node pool, which applies the taint to all nodes in the pool.
|
||||
|
||||
### Node Labels
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
You can apply labels to the node pool, which applies the labels to all nodes in the pool.
|
||||
|
||||
|
||||
@@ -182,30 +244,44 @@ In this section, enter details describing the node pool.
|
||||
|
||||
### Name
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Enter a name for the node pool.
|
||||
|
||||
### Initial Node Count
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
Integer for the starting number of nodes in the node pool.
|
||||
|
||||
### Max Pod Per Node
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
GKE has a hard limit of 110 Pods per node. For more information on the Kubernetes limits, see [this section.](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#dimension_limits)
|
||||
|
||||
### Autoscaling
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
Node pool autoscaling dynamically creates or deletes nodes based on the demands of your workload. For more information, see [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler)
|
||||
|
||||
### Auto Repair
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
GKE's node auto-repair feature helps you keep the nodes in your cluster in a healthy, running state. When enabled, GKE makes periodic checks on the health state of each node in your cluster. If a node fails consecutive health checks over an extended time period, GKE initiates a repair process for that node. For more information, see the section on [auto-repairing nodes.](https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair)
|
||||
|
||||
### Auto Upgrade
|
||||
|
||||
_Mutable: yes_
|
||||
|
||||
When enabled, the auto-upgrade feature keeps the nodes in your cluster up-to-date with the cluster control plane (master) version when your control plane is [updated on your behalf.](https://cloud.google.com/kubernetes-engine/upgrades#automatic_cp_upgrades) For more information about auto-upgrading nodes, see [this page.](https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades)
|
||||
|
||||
### Access Scopes
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
Access scopes are the legacy method of specifying permissions for your nodes.
|
||||
|
||||
- **Allow default access:** The default access for new clusters is the [Compute Engine default service account.](https://cloud.google.com/compute/docs/access/service-accounts?hl=en_US#default_service_account)
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
title: Installing Rancher on Azure Kubernetes Service
|
||||
shortTitle: AKS
|
||||
weight: 4
|
||||
---
|
||||
|
||||
This page covers how to install Rancher on Microsoft's Azure Kubernetes Servcice (AKS).
|
||||
|
||||
The guide uses command line tools to provision an AKS cluster with an ingress. If you prefer to provision your cluster using the Azure portal, refer to the [official documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal).
|
||||
|
||||
If you already have an AKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart)
|
||||
|
||||
# Prerequisites
|
||||
|
||||
>**Note**
|
||||
>Deploying to Microsoft Azure will incur charges.
|
||||
|
||||
- [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section]({{<baseurl>}}/rancher/v2.5/en/installation/requirements/#rke-and-hosted-kubernetes)
|
||||
|
||||
# 1. Prepare your Workstation
|
||||
|
||||
Install the following command line tools on your workstation:
|
||||
|
||||
- The Azure CLI, **az:** For help, refer to these [installation steps.](https://docs.microsoft.com/en-us/cli/azure/)
|
||||
- **kubectl:** For help, refer to these [installation steps.](https://kubernetes.io/docs/tasks/tools/#kubectl)
|
||||
- **helm:** For help, refer to these [installation steps.](https://helm.sh/docs/intro/install/)
|
||||
|
||||
# 2. Create a Resource Group
|
||||
|
||||
After installing the CLI, you will need to log in with your Azure account.
|
||||
|
||||
```
|
||||
az login
|
||||
```
|
||||
|
||||
Create a [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal) to hold all relevant resources for your cluster. Use a location that applies to your use case.
|
||||
|
||||
```
|
||||
az group create --name rancher-rg --location eastus
|
||||
```
|
||||
|
||||
# 3. Create the AKS Cluster
|
||||
|
||||
To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options.
|
||||
|
||||
```
|
||||
az aks create \
|
||||
--resource-group rancher-rg
|
||||
--name rancher-server \
|
||||
--kubernetes-version 1.18.14 \
|
||||
--node-count 3 \
|
||||
--node-vm-size Standard_D2_v3
|
||||
```
|
||||
|
||||
The cluster will take some time to be deployed.
|
||||
|
||||
# 4. Get Access Credentials
|
||||
|
||||
After the cluster is deployed, get the access credentials.
|
||||
|
||||
```
|
||||
az aks get-credentials --resource-group rancher-rg --name rancher-server
|
||||
```
|
||||
|
||||
This command merges your cluster's credentials into the existing kubeconfig and allows `kubectl` to interact with the cluster.
|
||||
|
||||
# 5. Install an Ingress
|
||||
|
||||
The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription.
|
||||
|
||||
The following command installs an `nginx-ingress-controller` with a Kubernetes load balancer service.
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 3.12.0 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
# 6. Get Load Balancer IP
|
||||
|
||||
To get the address of the load balancer, run:
|
||||
|
||||
```
|
||||
kubectl get service ingress-nginx-controller --namespace=ingress-nginx
|
||||
```
|
||||
|
||||
The result should look similar to the following:
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
|
||||
AGE
|
||||
ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229/TCP,443:31050/TCP
|
||||
67s
|
||||
```
|
||||
|
||||
Save the `EXTERNAL-IP`.
|
||||
|
||||
# 7. Set up DNS
|
||||
|
||||
External traffic to the Rancher server will need to be directed at the load balancer you created.
|
||||
|
||||
Set up a DNS to point at the `EXTERNAL-IP` that you saved. This DNS will be used as the Rancher server URL.
|
||||
|
||||
There are many valid ways to set up the DNS. For help, refer to the [Azure DNS documentation](https://docs.microsoft.com/en-us/azure/dns/)
|
||||
|
||||
# 8. Install the Rancher Helm Chart
|
||||
|
||||
Next, install the Rancher Helm chart by following the instructions on [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
|
||||
|
||||
Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
@@ -10,37 +10,26 @@ aliases:
|
||||
- /rancher/v2.5/en/cluster-admin/tools/logging
|
||||
---
|
||||
|
||||
- [Changes in Rancher v2.5](#changes-in-rancher-v2-5)
|
||||
- [Enabling Logging for Rancher Managed Clusters](#enabling-logging-for-rancher-managed-clusters)
|
||||
The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
|
||||
|
||||
For an overview of the changes in v2.5, see [this section.](/{{<baseurl>}}/rancher/v2.5/en/logging/architecture/#changes-in-rancher-v2-5) For information about migrating from Logging V1, see [this page.](./migrating)
|
||||
|
||||
- [Enabling Logging](#enabling-logging)
|
||||
- [Uninstall Logging](#uninstall-logging)
|
||||
- [Windows Support](#windows-support)
|
||||
- [Architecture](#architecture)
|
||||
- [Role-based Access Control](#role-based-access-control)
|
||||
- [Configuring the Logging Application](#configuring-the-logging-application)
|
||||
- [Examples](#examples)
|
||||
- [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory)
|
||||
- [Working with Taints and Tolerations](#working-with-taints-and-tolerations)
|
||||
- [Logging v2 with SELinux](#logging-v2-with-selinux)
|
||||
- [Additional Logging Sources](#additional-logging-sources)
|
||||
- [Configuring the Logging Custom Resources](#configuring-the-logging-custom-resources)
|
||||
- [Flows and ClusterFlows](#flows-and-clusterflows)
|
||||
- [Outputs and ClusterOutputs](#outputs-and-clusteroutputs)
|
||||
- [Configuring the Logging Helm Chart](#configuring-the-logging-helm-chart)
|
||||
- [Windows Support](#windows-support)
|
||||
- [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory)
|
||||
- [Working with Taints and Tolerations](#working-with-taints-and-tolerations)
|
||||
- [Logging V2 with SELinux](#logging-v2-with-selinux)
|
||||
- [Additional Logging Sources](#additional-logging-sources)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
|
||||
# Changes in Rancher v2.5
|
||||
|
||||
The following changes were introduced to logging in Rancher v2.5:
|
||||
|
||||
- The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
|
||||
- [Fluent Bit](https://fluentbit.io/) is now used to aggregate the logs, and [Fluentd](https://www.fluentd.org/) is used for filtering the messages and routing them to the outputs. Previously, only Fluentd was used.
|
||||
- Logging can be configured with a Kubernetes manifest, because logging now uses a Kubernetes operator with Custom Resource Definitions.
|
||||
- We now support filtering logs.
|
||||
- We now support writing logs to multiple outputs.
|
||||
- We now always collect Control Plane and etcd logs.
|
||||
|
||||
The following figure from the [Banzai documentation](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture) shows the new logging architecture:
|
||||
|
||||
<figcaption>How the Banzai Cloud Logging Operator Works with Fluentd and Fluent Bit</figcaption>
|
||||
|
||||
|
||||
|
||||
# Enabling Logging for Rancher Managed Clusters
|
||||
# Enabling Logging
|
||||
|
||||
You can enable the logging for a Rancher managed cluster by going to the Apps page and installing the logging app.
|
||||
|
||||
@@ -61,403 +50,69 @@ You can enable the logging for a Rancher managed cluster by going to the Apps pa
|
||||
|
||||
**Result** `rancher-logging` is uninstalled.
|
||||
|
||||
# Windows Support
|
||||
# Architecture
|
||||
|
||||
For more information about how the logging application works, see [this section.](./architecture)
|
||||
|
||||
|
||||
|
||||
# Role-based Access Control
|
||||
|
||||
Rancher logging has two roles, `logging-admin` and `logging-view`. For more information on how and when to use these roles, see [this page.](./rbac)
|
||||
|
||||
# Configuring Logging Custom Resources
|
||||
|
||||
To manage `Flows,` `ClusterFlows`, `Outputs`, and `ClusterOutputs`, go to the **Cluster Explorer** in the Rancher UI. In the upper left corner, click **Cluster Explorer > Logging**.
|
||||
|
||||
### Flows and ClusterFlows
|
||||
|
||||
For help with configuring `Flows` and `ClusterFlows`, see [this page.](./custom-resource-config/flows)
|
||||
|
||||
### Outputs and ClusterOutputs
|
||||
|
||||
For help with configuring `Outputs` and `ClusterOutputs`, see [this page.](./custom-resource-config/outputs)
|
||||
|
||||
# Configuring the Logging Helm Chart
|
||||
|
||||
For a list of options that can be configured when the logging application is installed or upgraded, see [this page.](./helm-chart-options)
|
||||
|
||||
### Windows Support
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
As of Rancher v2.5.8, logging support for Windows clusters has been added and logs can be collected from Windows nodes.
|
||||
|
||||
### Enabling and Disabling Windows Node Logging
|
||||
|
||||
You can enable or disable Windows node logging by setting `global.cattle.windows.enabled` to either `true` or `false` in the `values.yaml`.
|
||||
By default, Windows node logging will be enabled if the Cluster Explorer UI is used to install the logging application on a Windows cluster.
|
||||
In this scenario, setting `global.cattle.windows.enabled` to `false` will disable Windows node logging on the cluster.
|
||||
When disabled, logs will still be collected from Linux nodes within the Windows cluster.
|
||||
|
||||
> Note: Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists where Windows nodeAgents are not deleted when performing a `helm upgrade` after disabling Windows logging in a Windows cluster. In this scenario, users may need to manually remove the Windows nodeAgents if they are already installed.
|
||||
For details on how to enable or disable Windows node logging, see [this section.](./helm-chart-options/#enable-disable-windows-node-logging)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.7" %}}
|
||||
Clusters with Windows workers support exporting logs from Linux nodes, but Windows node logs are currently unable to be exported.
|
||||
Only Linux node logs are able to be exported.
|
||||
|
||||
To allow the logging pods to be scheduled on Linux nodes, tolerations must be added to the pods. Refer to the [Working with Taints and Tolerations](#working-with-taints-and-tolerations) section for details and an example.
|
||||
To allow the logging pods to be scheduled on Linux nodes, tolerations must be added to the pods. Refer to the [Working with Taints and Tolerations]({{<baseurl>}}/rancher/v2.5/en/logging/taints-tolerations/) section for details and an example.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
# Role-based Access Control
|
||||
|
||||
Rancher logging has two roles, `logging-admin` and `logging-view`.
|
||||
### Working with a Custom Docker Root Directory
|
||||
|
||||
- `logging-admin` gives users full access to namespaced flows and outputs
|
||||
- `logging-view` allows users to *view* namespaced flows and outputs, and cluster flows and outputs
|
||||
|
||||
> **Why choose one role over the other?** Edit access to cluster flow and cluster output resources is powerful. Any user with it has edit access for all logs in the cluster.
|
||||
|
||||
In Rancher, the cluster administrator role is the only role with full access to all `rancher-logging` resources. Cluster members are not able to edit or read any logging resources. Project owners and members have the following privileges:
|
||||
|
||||
Project Owners | Project Members
|
||||
--- | ---
|
||||
able to create namespaced flows and outputs in their projects' namespaces | only able to view the flows and outputs in projects' namespaces
|
||||
can collect logs from anything in their projects' namespaces | cannot collect any logs in their projects' namespaces
|
||||
|
||||
Both project owners and project members require at least *one* namespace in their project to use logging. If they do not, then they may not see the logging button in the top nav dropdown.
|
||||
|
||||
# Configuring the Logging Application
|
||||
|
||||
To configure the logging application, go to the **Cluster Explorer** in the Rancher UI. In the upper left corner, click **Cluster Explorer > Logging**.
|
||||
|
||||
### Overview of Logging Custom Resources
|
||||
|
||||
The following Custom Resource Definitions are used to configure logging:
|
||||
|
||||
- [Flow and ClusterFlow](https://banzaicloud.com/docs/one-eye/logging-operator/crds/#flows-clusterflows)
|
||||
- [Output and ClusterOutput](https://banzaicloud.com/docs/one-eye/logging-operator/crds/#outputs-clusteroutputs)
|
||||
|
||||
According to the [Banzai Cloud documentation,](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)
|
||||
|
||||
> You can define `outputs` (destinations where you want to send your log messages, for example, Elasticsearch, or and Amazon S3 bucket), and `flows` that use filters and selectors to route log messages to the appropriate outputs. You can also define cluster-wide outputs and flows, for example, to use a centralized output that namespaced users cannot modify.
|
||||
|
||||
# Examples
|
||||
|
||||
Once logging is installed, you can use these examples to help craft your own logging pipeline.
|
||||
|
||||
### Cluster Output to ElasticSearch
|
||||
|
||||
Let's say you wanted to send all logs in your cluster to an `elasticsearch` cluster. First, we create a cluster output.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-es"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
elasticsearch:
|
||||
host: elasticsearch.example.com
|
||||
port: 9200
|
||||
scheme: http
|
||||
```
|
||||
|
||||
We have created this cluster output, without elasticsearch configuration, in the same namespace as our operator: `cattle-logging-system.`. Any time we create a cluster flow or cluster output, we have to put it in the `cattle-logging-system` namespace.
|
||||
|
||||
Now that we have configured where we want the logs to go, let's configure all logs to go to that output.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-es"
|
||||
```
|
||||
|
||||
We should now see our configured index with logs in it.
|
||||
|
||||
### Output to Splunk
|
||||
|
||||
What if we have an application team who only wants logs from a specific namespaces sent to a `splunk` server? For this case, we can use namespaced outputs and flows.
|
||||
|
||||
Before we start, let's set up that team's application: `coolapp`.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: devteam
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: coolapp
|
||||
namespace: devteam
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: coolapp
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
containers:
|
||||
- name: generator
|
||||
image: paynejacob/loggenerator:latest
|
||||
```
|
||||
|
||||
With `coolapp` running, we will follow a similar path as when we created a cluster output. However, unlike cluster outputs, we create our output in our application's namespace.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Output
|
||||
metadata:
|
||||
name: "devteam-splunk"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
SplunkHec:
|
||||
host: splunk.example.com
|
||||
port: 8088
|
||||
protocol: http
|
||||
```
|
||||
|
||||
Once again, let's feed our output some logs.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: "devteam-logs"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
localOutputRefs:
|
||||
- "devteam-splunk"
|
||||
```
|
||||
|
||||
### Output to Syslog
|
||||
|
||||
Let's say you wanted to send all logs in your cluster to an `syslog` server. First, we create a cluster output.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-syslog"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
syslog:
|
||||
buffer:
|
||||
timekey: 30s
|
||||
timekey_use_utc: true
|
||||
timekey_wait: 10s
|
||||
flush_interval: 5s
|
||||
format:
|
||||
type: json
|
||||
app_name_field: test
|
||||
host: syslog.example.com
|
||||
insecure: true
|
||||
port: 514
|
||||
transport: tcp
|
||||
```
|
||||
|
||||
Now that we have configured where we want the logs to go, let's configure all logs to go to that output.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-syslog"
|
||||
```
|
||||
|
||||
### Unsupported Output
|
||||
|
||||
For the final example, we create an output to write logs to a destination that is not supported out of the box:
|
||||
|
||||
> **Note on syslog** As of Rancher v2.5.4, `syslog` is a supported output. However, this example still provides an overview on using unsupported plugins.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: syslog-config
|
||||
namespace: cattle-logging-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
fluent-bit.conf: |
|
||||
[INPUT]
|
||||
Name forward
|
||||
Port 24224
|
||||
|
||||
[OUTPUT]
|
||||
Name syslog
|
||||
InstanceName syslog-output
|
||||
Match *
|
||||
Addr syslog.example.com
|
||||
Port 514
|
||||
Cluster ranchers
|
||||
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: fluentbit-syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
output: syslog
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
containers:
|
||||
- name: fluentbit
|
||||
image: paynejacob/fluent-bit-out-syslog:latest
|
||||
ports:
|
||||
- containerPort: 24224
|
||||
volumeMounts:
|
||||
- mountPath: "/fluent-bit/etc/"
|
||||
name: configuration
|
||||
volumes:
|
||||
- name: configuration
|
||||
secret:
|
||||
secretName: syslog-config
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
selector:
|
||||
output: syslog
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 24224
|
||||
targetPort: 24224
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: all-logs
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- syslog
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: syslog
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
forward:
|
||||
servers:
|
||||
- host: "syslog-forwarder.cattle-logging-system"
|
||||
require_ack_response: false
|
||||
ignore_network_errors_at_startup: false
|
||||
```
|
||||
|
||||
Let's break down what is happening here. First, we create a deployment of a container that has the additional `syslog` plugin and accepts logs forwarded from another `fluentd`. Next we create an output configured as a forwarder to our deployment. The deployment `fluentd` will then forward all logs to the configured `syslog` destination.
|
||||
|
||||
# Working with a Custom Docker Root Directory
|
||||
|
||||
_Applies to v2.5.6+_
|
||||
|
||||
If using a custom Docker root directory, you can set `global.dockerRootDirectory` in `values.yaml`.
|
||||
This will ensure that the Logging CRs created will use your specified path rather than the default Docker `data-root` location.
|
||||
Note that this only affects Linux nodes.
|
||||
If there are any Windows nodes in the cluster, the change will not be applicable to those nodes.
|
||||
|
||||
# Working with Taints and Tolerations
|
||||
|
||||
"Tainting" a Kubernetes node causes pods to repel running on that node.
|
||||
Unless the pods have a `toleration` for that node's taint, they will run on other nodes in the cluster.
|
||||
[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint.
|
||||
Using `nodeSelector` gives pods an affinity towards certain nodes.
|
||||
Both provide choice for the what node(s) the pod will run on.
|
||||
For details on using a custom Docker root directory, see [this section.](./helm-chart-options/#working-with-a-custom-docker-root-directory)
|
||||
|
||||
|
||||
### Default Implementation in Rancher's Logging Stack
|
||||
### Working with Taints and Tolerations
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
|
||||
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
|
||||
Moreover, most logging stack pods run on Linux only and have a `nodeSelector` added to ensure they run on Linux nodes.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.7" %}}
|
||||
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
|
||||
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
|
||||
Moreover, we can populate the `nodeSelector` to ensure that our pods *only* run on Linux nodes.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
Let's look at an example pod YAML file with these settings...
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
# metadata...
|
||||
spec:
|
||||
# containers...
|
||||
tolerations:
|
||||
- key: cattle.io/os
|
||||
operator: "Equal"
|
||||
value: "linux"
|
||||
effect: NoSchedule
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
```
|
||||
|
||||
In the above example, we ensure that our pod only runs on Linux nodes, and we add a `toleration` for the taint we have on all of our Linux nodes.
|
||||
You can do the same with Rancher's existing taints, or with your own custom ones.
|
||||
|
||||
### Adding NodeSelector Settings and Tolerations for Custom Taints
|
||||
|
||||
If you would like to add your own `nodeSelector` settings, or if you would like to add `tolerations` for additional taints, you can pass the following to the chart's values.
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
# insert tolerations...
|
||||
nodeSelector:
|
||||
# insert nodeSelector...
|
||||
```
|
||||
|
||||
These values will add both settings to the `fluentd`, `fluentbit`, and `logging-operator` containers.
|
||||
Essentially, these are global settings for all pods in the logging stack.
|
||||
|
||||
However, if you would like to add tolerations for *only* the `fluentbit` container, you can add the following to the chart's values.
|
||||
|
||||
```yaml
|
||||
fluentbit_tolerations:
|
||||
# insert tolerations list for fluentbit containers only...
|
||||
```
|
||||
For information on how to use taints and tolerations with the logging application, see [this page.](./taints-tolerations)
|
||||
|
||||
|
||||
# Logging v2 with SELinux
|
||||
### Logging V2 with SELinux
|
||||
|
||||
_Available as of v2.5.8_
|
||||
|
||||
> **Requirements:** Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
|
||||
For information on enabling the logging application for SELinux-enabled nodes, see [this section.](./helm-chart-options/#enabling-the-logging-application-to-work-with-selinux)
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
|
||||
### Additional Logging Sources
|
||||
|
||||
To use Logging v2 with SELinux, we recommend installing the `rancher-selinux` RPM according to the instructions on [this page.]({{<baseurl>}}/rancher/v2.5/en/security/selinux/#installing-the-rancher-selinux-rpm)
|
||||
|
||||
Then you will need to configure the logging application to work with SELinux as shown in [this section.]({{<baseurl>}}/rancher/v2.5/en/security/selinux/#configuring-the-logging-application-to-work-with-selinux)
|
||||
|
||||
# Additional Logging Sources
|
||||
|
||||
By default, Rancher collects logs for [control plane components](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) and [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for all cluster types.
|
||||
In some cases, Rancher may be able to collect additional logs.
|
||||
|
||||
The following table summarizes the sources where additional logs may be collected for each node types:
|
||||
|
||||
| Logging Source | Linux Nodes (including in Windows cluster) | Windows Nodes |
|
||||
| --- | --- | ---|
|
||||
| RKE | ✓ | ✓ |
|
||||
| RKE2 | ✓ | |
|
||||
| K3s | ✓ | |
|
||||
| AKS | ✓ | |
|
||||
| EKS | ✓ | |
|
||||
| GKE | ✓ | |
|
||||
|
||||
To enable hosted Kubernetes providers as additional logging sources, go to **Cluster Explorer > Logging > Chart Options** and select the **Enable enhanced cloud provider logging** option.
|
||||
When enabled, Rancher collects all additional node and control plane logs the provider has made available, which may vary between providers.
|
||||
If you're already using a cloud provider's own logging solution such as AWS CloudWatch or Google Cloud operations suite (formerly Stackdriver), it is not necessary to enable this option as the native solution will have unrestricted access to all logs.
|
||||
By default, Rancher collects logs for control plane components and node components for all cluster types. In some cases additional logs can be collected. For details, see [this section.](./helm-chart-options/#enabling-the-logging-application-to-work-with-selinux)
|
||||
|
||||
|
||||
# Troubleshooting
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Architecture
|
||||
weight: 1
|
||||
---
|
||||
|
||||
This section summarizes the architecture of the Rancher logging application.
|
||||
|
||||
For more details about how the Banzai Cloud Logging operator works, see the [official documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)
|
||||
|
||||
### Changes in Rancher v2.5
|
||||
|
||||
The following changes were introduced to logging in Rancher v2.5:
|
||||
|
||||
- The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
|
||||
- [Fluent Bit](https://fluentbit.io/) is now used to aggregate the logs, and [Fluentd](https://www.fluentd.org/) is used for filtering the messages and routing them to the `Outputs`. Previously, only Fluentd was used.
|
||||
- Logging can be configured with a Kubernetes manifest, because logging now uses a Kubernetes operator with Custom Resource Definitions.
|
||||
- We now support filtering logs.
|
||||
- We now support writing logs to multiple `Outputs`.
|
||||
- We now always collect Control Plane and etcd logs.
|
||||
|
||||
### How the Banzai Cloud Logging Operator Works
|
||||
|
||||
The Logging operator automates the deployment and configuration of a Kubernetes logging pipeline. It deploys and configures a Fluent Bit DaemonSet on every node to collect container and application logs from the node file system.
|
||||
|
||||
Fluent Bit queries the Kubernetes API and enriches the logs with metadata about the pods, and transfers both the logs and the metadata to Fluentd. Fluentd receives, filters, and transfers logs to multiple `Outputs`.
|
||||
|
||||
The following custom resources are used to define how logs are filtered and sent to their `Outputs`:
|
||||
|
||||
- A `Flow` is a namespaced custom resource that uses filters and selectors to route log messages to the appropriate `Outputs`.
|
||||
- A `ClusterFlow` is used to route cluster-level log messages.
|
||||
- An `Output` is a namespaced resource that defines where the log messages are sent.
|
||||
- A `ClusterOutput` defines an `Output` that is available from all `Flows` and `ClusterFlows`.
|
||||
|
||||
Each `Flow` must reference an `Output`, and each `ClusterFlow` must reference a `ClusterOutput`.
|
||||
|
||||
The following figure from the [Banzai documentation](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture) shows the new logging architecture:
|
||||
|
||||
<figcaption>How the Banzai Cloud Logging Operator Works with Fluentd and Fluent Bit</figcaption>
|
||||
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Custom Resource Configuration
|
||||
weight: 5
|
||||
---
|
||||
|
||||
The following Custom Resource Definitions are used to configure logging:
|
||||
|
||||
- [Flow and ClusterFlow](./flows)
|
||||
- [Output and ClusterOutput](./outputs)
|
||||
@@ -0,0 +1,161 @@
|
||||
---
|
||||
title: Flows and ClusterFlows
|
||||
weight: 1
|
||||
---
|
||||
|
||||
For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)
|
||||
|
||||
- [Configuration](#configuration)
|
||||
- [YAML Example](#yaml-example)
|
||||
|
||||
# Configuration
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
|
||||
- [Flows](#flows-2-5-8)
|
||||
- [Matches](#matches-2-5-8)
|
||||
- [Filters](#filters-2-5-8)
|
||||
- [Outputs](#outputs-2-5-8)
|
||||
- [ClusterFlows](#clusterflows-2-5-8)
|
||||
|
||||
# Changes in v2.5.8
|
||||
|
||||
The `Flows` and `ClusterFlows` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
|
||||
<a id="flows-2-5-8"></a>
|
||||
|
||||
# Flows
|
||||
|
||||
A `Flow` defines which logs to collect and filter and which output to send the logs to.
|
||||
|
||||
The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
|
||||
<a id="matches-2-5-8"></a>
|
||||
|
||||
### Matches
|
||||
|
||||
Match statements are used to select which containers to pull logs from.
|
||||
|
||||
You can specify match statements to select or exclude logs according to Kubernetes labels, container and host names. Match statements are evaluated in the order they are defined and processed only until the first matching select or exclude rule applies.
|
||||
|
||||
Matches can be configured by filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
|
||||
|
||||
For detailed examples on using the match statement, see the [official documentation on log routing.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/log-routing/)
|
||||
|
||||
<a id="filters-2-5-8"></a>
|
||||
|
||||
### Filters
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Banzai Cloud Logging operator, see [this page.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/filters/)
|
||||
|
||||
Filters need to be configured in YAML.
|
||||
|
||||
<a id="outputs-2-5-8"></a>
|
||||
|
||||
### Outputs
|
||||
|
||||
This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
`Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
|
||||
|
||||
<a id="clusterflows-2-5-8"></a>
|
||||
|
||||
# ClusterFlows
|
||||
|
||||
Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-v2.5.7" %}}
|
||||
|
||||
- [Flows](#flows-2-5-0)
|
||||
- [Matches](#matches-2-5-0)
|
||||
- [Filters](#filters-2-5-0)
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
- [ClusterFlows](#clusterflows-2-5-0)
|
||||
|
||||
|
||||
<a id="flows-2-5-0"></a>
|
||||
|
||||
# Flows
|
||||
|
||||
A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
`Flows` need to be defined in YAML.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
|
||||
<a id="matches-2-5-0"></a>
|
||||
|
||||
### Matches
|
||||
|
||||
Match statements are used to select which containers to pull logs from.
|
||||
|
||||
You can specify match statements to select or exclude logs according to Kubernetes labels, container and host names. Match statements are evaluated in the order they are defined and processed only until the first matching select or exclude rule applies.
|
||||
|
||||
For detailed examples on using the match statement, see the [official documentation on log routing.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/log-routing/)
|
||||
|
||||
<a id="filters-2-5-0"></a>
|
||||
|
||||
### Filters
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Banzai Cloud Logging operator, see [this page.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/filters/)
|
||||
|
||||
<a id="outputs-2-5-0"></a>
|
||||
|
||||
### Outputs
|
||||
|
||||
This `Output` will receive logs from the `Flow`.
|
||||
|
||||
Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
<a id="clusterflows-2-5-0"></a>
|
||||
|
||||
# ClusterFlows
|
||||
|
||||
Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
`ClusterFlow` selects logs from all namespaces in the cluster. Logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
`ClusterFlows` need to be defined in YAML.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
|
||||
# YAML Example
|
||||
|
||||
The following example `Flow` transforms the log messages from the default namespace and sends them to an S3 `Output`:
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: flow-sample
|
||||
namespace: default
|
||||
spec:
|
||||
filters:
|
||||
- parser:
|
||||
remove_key_name_field: true
|
||||
parse:
|
||||
type: nginx
|
||||
- tag_normaliser:
|
||||
format: ${namespace_name}.${pod_name}.${container_name}
|
||||
localOutputRefs:
|
||||
- s3-output
|
||||
match:
|
||||
- select:
|
||||
labels:
|
||||
app: nginx
|
||||
```
|
||||
@@ -0,0 +1,346 @@
|
||||
---
|
||||
title: Outputs and ClusterOutputs
|
||||
weight: 2
|
||||
---
|
||||
|
||||
For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)
|
||||
|
||||
- [Configuration](#configuration)
|
||||
- [YAML Examples](#yaml-examples)
|
||||
- [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch)
|
||||
- [Output to Splunk](#output-to-splunk)
|
||||
- [Output to Syslog](#output-to-syslog)
|
||||
- [Unsupported Outputs](#unsupported-outputs)
|
||||
|
||||
# Configuration
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.8+" %}}
|
||||
|
||||
- [Outputs](#outputs-2-5-8)
|
||||
- [ClusterOutputs](#clusteroutputs-2-5-8)
|
||||
|
||||
# Changes in v2.5.8
|
||||
|
||||
The `Outputs` and `ClusterOutputs` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
|
||||
<a id="outputs-2-5-8"></a>
|
||||
# Outputs
|
||||
|
||||
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
|
||||
|
||||
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
|
||||
|
||||
You can use secrets in these definitions, but they must also be in the same namespace.
|
||||
|
||||
For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)
|
||||
|
||||
The Rancher UI provides forms for configuring the following `Output` types:
|
||||
|
||||
- Amazon ElasticSearch
|
||||
- Azure Storage
|
||||
- Cloudwatch
|
||||
- Datadog
|
||||
- Elasticsearch
|
||||
- File
|
||||
- Fluentd
|
||||
- GCS
|
||||
- Kafka
|
||||
- Kinesis Stream
|
||||
- LogDNA
|
||||
- LogZ
|
||||
- Loki
|
||||
- New Relic
|
||||
- Splunk
|
||||
- SumoLogic
|
||||
- Syslog
|
||||
|
||||
The Rancher UI provides forms for configuring the `Output` type, target, and access credentials if applicable.
|
||||
|
||||
For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)
|
||||
|
||||
<a id="clusteroutputs-2-5-8"></a>
|
||||
|
||||
# ClusterOutputs
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "v2.5.0-v2.5.7" %}}
|
||||
|
||||
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
- [ClusterOutputs](#clusteroutputs-2-5-0)
|
||||
|
||||
|
||||
<a id="outputs-2-5-0"></a>
|
||||
# Outputs
|
||||
|
||||
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
|
||||
|
||||
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
|
||||
|
||||
You can use secrets in these definitions, but they must also be in the same namespace.
|
||||
|
||||
`Outputs` are configured in YAML. For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)
|
||||
|
||||
For examples of configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)
|
||||
|
||||
<a id="clusteroutputs-2-5-0"></a>
|
||||
|
||||
# ClusterOutputs
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
The Rancher UI provides forms for configuring the `ClusterOutput` type, target, and access credentials if applicable.
|
||||
|
||||
`ClusterOutputs` are configured in YAML. For the details of `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)
|
||||
|
||||
For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
|
||||
# YAML Examples
|
||||
|
||||
Once logging is installed, you can use these examples to help craft your own logging pipeline.
|
||||
|
||||
- [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch)
|
||||
- [Output to Splunk](#output-to-splunk)
|
||||
- [Output to Syslog](#output-to-syslog)
|
||||
- [Unsupported Outputs](#unsupported-outputs)
|
||||
|
||||
### Cluster Output to ElasticSearch
|
||||
|
||||
Let's say you wanted to send all logs in your cluster to an `elasticsearch` cluster. First, we create a cluster `Output`.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-es"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
elasticsearch:
|
||||
host: elasticsearch.example.com
|
||||
port: 9200
|
||||
scheme: http
|
||||
```
|
||||
|
||||
We have created this `ClusterOutput`, without elasticsearch configuration, in the same namespace as our operator: `cattle-logging-system.`. Any time we create a `ClusterFlow` or `ClusterOutput`, we have to put it in the `cattle-logging-system` namespace.
|
||||
|
||||
Now that we have configured where we want the logs to go, let's configure all logs to go to that `ClusterOutput`.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-es"
|
||||
```
|
||||
|
||||
We should now see our configured index with logs in it.
|
||||
|
||||
|
||||
### Output to Splunk
|
||||
|
||||
What if we have an application team who only wants logs from a specific namespaces sent to a `splunk` server? For this case, we can use namespaced `Outputs` and `Flows`.
|
||||
|
||||
Before we start, let's set up that team's application: `coolapp`.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: devteam
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: coolapp
|
||||
namespace: devteam
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: coolapp
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
containers:
|
||||
- name: generator
|
||||
image: paynejacob/loggenerator:latest
|
||||
```
|
||||
|
||||
With `coolapp` running, we will follow a similar path as when we created a `ClusterOutput`. However, unlike `ClusterOutputs`, we create our `Output` in our application's namespace.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Output
|
||||
metadata:
|
||||
name: "devteam-splunk"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
SplunkHec:
|
||||
host: splunk.example.com
|
||||
port: 8088
|
||||
protocol: http
|
||||
```
|
||||
|
||||
Once again, let's feed our `Output` some logs:
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: "devteam-logs"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
localOutputRefs:
|
||||
- "devteam-splunk"
|
||||
```
|
||||
|
||||
|
||||
### Output to Syslog
|
||||
|
||||
Let's say you wanted to send all logs in your cluster to an `syslog` server. First, we create a `ClusterOutput`:
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-syslog"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
syslog:
|
||||
buffer:
|
||||
timekey: 30s
|
||||
timekey_use_utc: true
|
||||
timekey_wait: 10s
|
||||
flush_interval: 5s
|
||||
format:
|
||||
type: json
|
||||
app_name_field: test
|
||||
host: syslog.example.com
|
||||
insecure: true
|
||||
port: 514
|
||||
transport: tcp
|
||||
```
|
||||
|
||||
Now that we have configured where we want the logs to go, let's configure all logs to go to that `Output`.
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-syslog"
|
||||
```
|
||||
|
||||
### Unsupported Outputs
|
||||
|
||||
For the final example, we create an `Output` to write logs to a destination that is not supported out of the box:
|
||||
|
||||
> **Note on syslog** As of Rancher v2.5.4, `syslog` is a supported `Output`. However, this example still provides an overview on using unsupported plugins.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: syslog-config
|
||||
namespace: cattle-logging-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
fluent-bit.conf: |
|
||||
[INPUT]
|
||||
Name forward
|
||||
Port 24224
|
||||
|
||||
[OUTPUT]
|
||||
Name syslog
|
||||
InstanceName syslog-output
|
||||
Match *
|
||||
Addr syslog.example.com
|
||||
Port 514
|
||||
Cluster ranchers
|
||||
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: fluentbit-syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
output: syslog
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
containers:
|
||||
- name: fluentbit
|
||||
image: paynejacob/fluent-bit-out-syslog:latest
|
||||
ports:
|
||||
- containerPort: 24224
|
||||
volumeMounts:
|
||||
- mountPath: "/fluent-bit/etc/"
|
||||
name: configuration
|
||||
volumes:
|
||||
- name: configuration
|
||||
secret:
|
||||
secretName: syslog-config
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
selector:
|
||||
output: syslog
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 24224
|
||||
targetPort: 24224
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: all-logs
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- syslog
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: syslog
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
forward:
|
||||
servers:
|
||||
- host: "syslog-forwarder.cattle-logging-system"
|
||||
require_ack_response: false
|
||||
ignore_network_errors_at_startup: false
|
||||
```
|
||||
|
||||
Let's break down what is happening here. First, we create a deployment of a container that has the additional `syslog` plugin and accepts logs forwarded from another `fluentd`. Next we create an `Output` configured as a forwarder to our deployment. The deployment `fluentd` will then forward all logs to the configured `syslog` destination.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: rancher-logging Helm Chart Options
|
||||
shortTitle: Helm Chart Options
|
||||
weight: 4
|
||||
---
|
||||
|
||||
- [Enable/Disable Windows Node Logging](#enable-disable-windows-node-logging)
|
||||
- [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory)
|
||||
- [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints)
|
||||
- [Enabling the Logging Application to Work with SELinux](#enabling-the-logging-application-to-work-with-selinux)
|
||||
- [Additional Logging Sources](#additional-logging-sources)
|
||||
|
||||
|
||||
### Enable/Disable Windows Node Logging
|
||||
|
||||
_Available as of v2.5.8_
|
||||
|
||||
You can enable or disable Windows node logging by setting `global.cattle.windows.enabled` to either `true` or `false` in the `values.yaml`.
|
||||
|
||||
By default, Windows node logging will be enabled if the Cluster Explorer UI is used to install the logging application on a Windows cluster.
|
||||
|
||||
In this scenario, setting `global.cattle.windows.enabled` to `false` will disable Windows node logging on the cluster.
|
||||
When disabled, logs will still be collected from Linux nodes within the Windows cluster.
|
||||
|
||||
> Note: Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists where Windows nodeAgents are not deleted when performing a `helm upgrade` after disabling Windows logging in a Windows cluster. In this scenario, users may need to manually remove the Windows nodeAgents if they are already installed.
|
||||
|
||||
### Working with a Custom Docker Root Directory
|
||||
|
||||
_Applies to v2.5.6+_
|
||||
|
||||
If using a custom Docker root directory, you can set `global.dockerRootDirectory` in `values.yaml`.
|
||||
|
||||
This will ensure that the Logging CRs created will use your specified path rather than the default Docker `data-root` location.
|
||||
|
||||
Note that this only affects Linux nodes.
|
||||
|
||||
If there are any Windows nodes in the cluster, the change will not be applicable to those nodes.
|
||||
|
||||
### Adding NodeSelector Settings and Tolerations for Custom Taints
|
||||
|
||||
You can add your own `nodeSelector` settings and add `tolerations` for additional taints by editing the logging Helm chart values. For details, see [this page.](../taints-tolerations)
|
||||
|
||||
### Enabling the Logging Application to Work with SELinux
|
||||
|
||||
_Available as of v2.5.8_
|
||||
|
||||
> **Requirements:** Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
|
||||
|
||||
To use Logging v2 with SELinux, we recommend installing the `rancher-selinux` RPM according to the instructions on [this page.]({{<baseurl>}}/rancher/v2.5/en/security/selinux/#installing-the-rancher-selinux-rpm)
|
||||
|
||||
Then, when installing the logging application, configure the chart to be SELinux aware by changing `global.seLinux.enabled` to `true` in the `values.yaml`.
|
||||
|
||||
### Additional Logging Sources
|
||||
|
||||
By default, Rancher collects logs for [control plane components](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) and [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for all cluster types.
|
||||
|
||||
In some cases, Rancher may be able to collect additional logs.
|
||||
|
||||
The following table summarizes the sources where additional logs may be collected for each node types:
|
||||
|
||||
| Logging Source | Linux Nodes (including in Windows cluster) | Windows Nodes |
|
||||
| --- | --- | ---|
|
||||
| RKE | ✓ | ✓ |
|
||||
| RKE2 | ✓ | |
|
||||
| K3s | ✓ | |
|
||||
| AKS | ✓ | |
|
||||
| EKS | ✓ | |
|
||||
| GKE | ✓ | |
|
||||
|
||||
To enable hosted Kubernetes providers as additional logging sources, go to **Cluster Explorer > Logging > Chart Options** and select the **Enable enhanced cloud provider logging** option.
|
||||
|
||||
When enabled, Rancher collects all additional node and control plane logs the provider has made available, which may vary between providers
|
||||
|
||||
If you're already using a cloud provider's own logging solution such as AWS CloudWatch or Google Cloud operations suite (formerly Stackdriver), it is not necessary to enable this option as the native solution will have unrestricted access to all logs.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Migrating to Rancher v2.5 Logging
|
||||
weight: 5
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.5/en/logging/v2.5/migrating
|
||||
---
|
||||
@@ -8,13 +8,26 @@ Starting in v2.5, the logging feature available within Rancher has been complete
|
||||
|
||||
Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ.
|
||||
|
||||
> Note: The pre-v2.5 user interface is now referred to as the _Cluster Manager_. The v2.5+ dashboard is referred to as the _Cluster Explorer_.
|
||||
> Note: The pre-v2.5 user interface is now referred to as the _Cluster Manager_. The v2.5+ dashboard is referred to as the _Cluster Explorer_.
|
||||
|
||||
## Installation
|
||||
- [Installation](#installation)
|
||||
- [Terminology](#terminology)
|
||||
- [Cluster Logging](#cluster-logging)
|
||||
- [Project Logging](#project-logging)
|
||||
- [Output Configuration](#output-configuration)
|
||||
- [Elasticsearch](#elasticsearch)
|
||||
- [Splunk](#splunk)
|
||||
- [Kafka](#kafka)
|
||||
- [Fluentd](#fluentd)
|
||||
- [Syslog](#syslog)
|
||||
- [Custom Log Fields](#custom-log-fields)
|
||||
- [System Logging](#system-logging)
|
||||
|
||||
To install logging in Rancher v2.5+, refer to [installation instructions]({{<baseurl>}}/rancher/v2.5/en/logging/v2.5/#enabling-logging-for-rancher-managed-clusters).
|
||||
# Installation
|
||||
|
||||
## Terminology & Familiarity
|
||||
To install logging in Rancher v2.5+, refer to the [installation instructions]({{<baseurl>}}/rancher/v2.5/en/logging/#enabling-logging).
|
||||
|
||||
### Terminology
|
||||
|
||||
In v2.5, logging configuration is centralized under a _Logging_ menu option available in the _Cluster Explorer_. It is from this menu option that logging for both cluster and namespace is configured.
|
||||
|
||||
@@ -24,57 +37,57 @@ There are four key concepts to understand for v2.5+ logging:
|
||||
|
||||
1. Outputs
|
||||
|
||||
_Outputs_ are a configuration resource that determine a destination for collected logs. This is where settings for aggregators such as ElasticSearch, Kafka, etc. are stored. _Outputs_ are namespaced resources.
|
||||
`Outputs` are a configuration resource that determine a destination for collected logs. This is where settings for aggregators such as ElasticSearch, Kafka, etc. are stored. `Outputs` are namespaced resources.
|
||||
|
||||
2. Flows
|
||||
|
||||
_Flows_ are a configuration resource that determine collection, filtering, and destination rules for logs. It is within a flow that one will configure what logs to collect, how to mutate or filter them, and which outputs to send the logs to. _Flows_ are namespaced resources, and can connect either to an _Output_ in the same namespace, or a _ClusterOutput_.
|
||||
`Flows` are a configuration resource that determine collection, filtering, and destination rules for logs. It is within a flow that one will configure what logs to collect, how to mutate or filter them, and which `Outputs` to send the logs to. `Flows` are namespaced resources, and can connect either to an `Output` in the same namespace, or a `ClusterOutput`.
|
||||
|
||||
3. ClusterOutputs
|
||||
|
||||
_ClusterOutputs_ serve the same functionality as _Outputs_, except they are a cluster-scoped resource. _ClusterOutputs_ are necessary when collecting logs cluster-wide, or if you wish to provide an output to all namespaces in your cluster.
|
||||
`ClusterOutputs` serve the same functionality as `Outputs`, except they are a cluster-scoped resource. `ClusterOutputs` are necessary when collecting logs cluster-wide, or if you wish to provide an `Output` to all namespaces in your cluster.
|
||||
|
||||
4. ClusterFlows
|
||||
|
||||
_ClusterFlows_ serve the same function as _Flows_, but at the cluster level. They are used to configure log collection for an entire cluster, instead of on a per-namespace level. _ClusterFlows_ are also where mutations and filters are defined, same as _Flows_ (in functionality).
|
||||
`ClusterFlows` serve the same function as `Flows`, but at the cluster level. They are used to configure log collection for an entire cluster, instead of on a per-namespace level. `ClusterFlows` are also where mutations and filters are defined, same as `Flows` (in functionality).
|
||||
|
||||
# Cluster Logging
|
||||
|
||||
To configure cluster-wide logging for v2.5+ logging, one needs to setup a _ClusterFlow_. This object defines the source of logs, any transformations or filters to be applied, and finally the output(s) for the logs.
|
||||
To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs.
|
||||
|
||||
> Important: _ClusterFlows_ must be defined within the `cattle-logging-system` namespace. _ClusterFlows_ will not work if defined in any other namespace.
|
||||
> Important: `ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace.
|
||||
|
||||
In legacy logging, in order to collect logs from across the entire cluster, one only needed to enable cluster-level logging and define the desired output. This basic approach remains in v2.5+ logging. To replicate legacy cluster-level logging, follow these steps:
|
||||
In legacy logging, in order to collect logs from across the entire cluster, one only needed to enable cluster-level logging and define the desired `Output`. This basic approach remains in v2.5+ logging. To replicate legacy cluster-level logging, follow these steps:
|
||||
|
||||
1. Define a _ClusterOutput_ according to the instructions found under [Output Configuration](#output-configuration)
|
||||
2. Create a _ClusterFlow_, ensuring that it is set to be created in the `cattle-logging-system` namespace
|
||||
1. Remove all _Include_ and _Exclude_ rules from the flow definition. This ensures that all logs are gathered.
|
||||
1. Define a `ClusterOutput` according to the instructions found under [Output Configuration](#output-configuration)
|
||||
2. Create a `ClusterFlow`, ensuring that it is set to be created in the `cattle-logging-system` namespace
|
||||
1. Remove all _Include_ and _Exclude_ rules from the `Flow` definition. This ensures that all logs are gathered.
|
||||
2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
|
||||
3. Define your cluster output(s)
|
||||
3. Define your cluster `Output` or `Outputs`
|
||||
|
||||
This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the output(s) you defined in the _ClusterFlow_.
|
||||
This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`.
|
||||
|
||||
# Project Logging
|
||||
|
||||
Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define _Flows_ for those namespaces.
|
||||
Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces.
|
||||
|
||||
To collect logs from a specific namespace, follow these steps:
|
||||
|
||||
1. Define an _Output_ or _ClusterOutput_ according to the instructions found under [Output Configuration](#output-configuration)
|
||||
2. Create a _Flow_, ensuring that it is set to be created in the namespace in which you want to gather logs.
|
||||
1. Define an `Output` or `ClusterOutput` according to the instructions found under [Output Configuration](#output-configuration)
|
||||
2. Create a `Flow`, ensuring that it is set to be created in the namespace in which you want to gather logs.
|
||||
1. If you wish to define _Include_ or _Exclude_ rules, you may do so. Otherwise, removal of all rules will result in all pods in the target namespace having their logs collected.
|
||||
2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
|
||||
3. Define your output(s) - these can be either _ClusterOutput_ or _Output_ objects.
|
||||
3. Define your outputs - these can be either `ClusterOutput` or `Output` objects.
|
||||
|
||||
This will result in logs from all sources in the namespace (pods) being collected and sent to the output(s) you defined in your _Flow_.
|
||||
This will result in logs from all sources in the namespace (pods) being collected and sent to the `Output` (or `Outputs`) you defined in your `Flow`.
|
||||
|
||||
> To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a _ClusterFlow_ to collect logs from all pods matching this label.
|
||||
> To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label.
|
||||
|
||||
# Output Configuration
|
||||
In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+.
|
||||
|
||||
|
||||
## Elasticsearch
|
||||
### Elasticsearch
|
||||
|
||||
| Legacy Logging | v2.5+ Logging | Notes |
|
||||
|-----------------------------------------------|-----------------------------------|-----------------------------------------------------------|
|
||||
@@ -87,7 +100,7 @@ In legacy logging, there are five logging destinations to choose from: Elasticse
|
||||
| SSL Configuration -> Enabled SSL Verification | SSL -> Certificate Authority File | Certificate must now be stored in a secret |
|
||||
|
||||
|
||||
In legacy logging, indices were automatically created according to the format in the "Index Patterns" section. In v2.5 logging, default behavior has been changed to logging to a single index. You can still configure index pattern functionality on the output object by editing as YAML and inputting the following values:
|
||||
In legacy logging, indices were automatically created according to the format in the "Index Patterns" section. In v2.5 logging, default behavior has been changed to logging to a single index. You can still configure index pattern functionality on the `Output` object by editing as YAML and inputting the following values:
|
||||
|
||||
```
|
||||
...
|
||||
@@ -101,7 +114,7 @@ spec:
|
||||
|
||||
Replace `<desired prefix>` with the prefix for the indices that will be created. In legacy logging, this defaulted to the name of the cluster.
|
||||
|
||||
## Splunk
|
||||
### Splunk
|
||||
|
||||
| Legacy Logging | v2.5+ Logging | Notes |
|
||||
|------------------------------------------|----------------------------------------|----------------------------------------------------------------------------------------|
|
||||
@@ -118,7 +131,7 @@ _(1) `client_key` and `client_cert` values must be paths to the key and cert fil
|
||||
|
||||
_(2) Users can configure either `ca_file` (a path to a PEM-encoded CA certificate) or `ca_path` (a path to a directory containing CA certificates in PEM format). These files must be mounted into the `rancher-logging-fluentd` pod in order to be used._
|
||||
|
||||
## Kafka
|
||||
### Kafka
|
||||
|
||||
| Legacy Logging | v2.5+ Logging | Notes |
|
||||
|-----------------------------------------|----------------------------|------------------------------------------------------|
|
||||
@@ -132,9 +145,9 @@ _(2) Users can configure either `ca_file` (a path to a PEM-encoded CA certificat
|
||||
| SASL Configuration -> Password | Access -> Password | Password must be stored in a secret |
|
||||
| SASL Configuration -> Scram Mechanism | Access -> Scram Mechanism | Input mechanism as string, e.g. "sha256" or "sha512" |
|
||||
|
||||
## Fluentd
|
||||
### Fluentd
|
||||
|
||||
As of v2.5.2, it is only possible to add a single Fluentd server using the "Edit as Form" option. To add multiple servers, edit the output as YAML and input multiple servers.
|
||||
As of v2.5.2, it is only possible to add a single Fluentd server using the "Edit as Form" option. To add multiple servers, edit the `Output` as YAML and input multiple servers.
|
||||
|
||||
| Legacy Logging | v2.5+ Logging | Notes |
|
||||
|------------------------------------------|-----------------------------------------------------|----------------------------------------------------------------------|
|
||||
@@ -154,13 +167,13 @@ As of v2.5.2, it is only possible to add a single Fluentd server using the "Edit
|
||||
|
||||
_(1) These values are to be specified as paths to files. Those files must be mounted into the `rancher-logging-fluentd` pod in order to be used._
|
||||
|
||||
## Syslog
|
||||
### Syslog
|
||||
|
||||
As of v2.5.2, syslog is not currently supported as an output using v2.5+ logging.
|
||||
As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging.
|
||||
|
||||
## Custom Log Fields
|
||||
# Custom Log Fields
|
||||
|
||||
In order to add custom log fields, you will need to add the following YAML to your flow configuration:
|
||||
In order to add custom log fields, you will need to add the following YAML to your `Flow` configuration:
|
||||
|
||||
```
|
||||
...
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
shortTitle: Role-based Access Control
|
||||
title: Role-based Access Control for Logging
|
||||
weight: 3
|
||||
---
|
||||
|
||||
Rancher logging has two roles, `logging-admin` and `logging-view`.
|
||||
|
||||
- `logging-admin` gives users full access to namespaced `Flows` and `Outputs`
|
||||
- `logging-view` allows users to *view* namespaced `Flows` and `Outputs`, and `ClusterFlows` and `ClusterOutputs`
|
||||
|
||||
> **Why choose one role over the other?** Edit access to `ClusterFlow` and `ClusterOutput` resources is powerful. Any user with it has edit access for all logs in the cluster.
|
||||
|
||||
In Rancher, the cluster administrator role is the only role with full access to all `rancher-logging` resources. Cluster members are not able to edit or read any logging resources. Project owners and members have the following privileges:
|
||||
|
||||
Project Owners | Project Members
|
||||
--- | ---
|
||||
able to create namespaced `Flows` and `Outputs` in their projects' namespaces | only able to view the `Flows` and `Outputs` in projects' namespaces
|
||||
can collect logs from anything in their projects' namespaces | cannot collect any logs in their projects' namespaces
|
||||
|
||||
Both project owners and project members require at least *one* namespace in their project to use logging. If they do not, then they may not see the logging button in the top nav dropdown.
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Working with Taints and Tolerations
|
||||
weight: 6
|
||||
---
|
||||
|
||||
"Tainting" a Kubernetes node causes pods to repel running on that node.
|
||||
|
||||
Unless the pods have a `toleration` for that node's taint, they will run on other nodes in the cluster.
|
||||
|
||||
[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint.
|
||||
|
||||
Using `nodeSelector` gives pods an affinity towards certain nodes.
|
||||
|
||||
Both provide choice for the what node(s) the pod will run on.
|
||||
|
||||
- [Default Implementation in Rancher's Logging Stack](#default-implementation-in-rancher-s-logging-stack)
|
||||
- [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints)
|
||||
|
||||
|
||||
### Default Implementation in Rancher's Logging Stack
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
|
||||
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
|
||||
Moreover, most logging stack pods run on Linux only and have a `nodeSelector` added to ensure they run on Linux nodes.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.7" %}}
|
||||
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
|
||||
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
|
||||
Moreover, we can populate the `nodeSelector` to ensure that our pods *only* run on Linux nodes.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
This example Pod YAML file shows a nodeSelector being used with a toleration:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
# metadata...
|
||||
spec:
|
||||
# containers...
|
||||
tolerations:
|
||||
- key: cattle.io/os
|
||||
operator: "Equal"
|
||||
value: "linux"
|
||||
effect: NoSchedule
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
```
|
||||
|
||||
In the above example, we ensure that our pod only runs on Linux nodes, and we add a `toleration` for the taint we have on all of our Linux nodes.
|
||||
|
||||
You can do the same with Rancher's existing taints, or with your own custom ones.
|
||||
|
||||
### Adding NodeSelector Settings and Tolerations for Custom Taints
|
||||
|
||||
If you would like to add your own `nodeSelector` settings, or if you would like to add `tolerations` for additional taints, you can pass the following to the chart's values.
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
# insert tolerations...
|
||||
nodeSelector:
|
||||
# insert nodeSelector...
|
||||
```
|
||||
|
||||
These values will add both settings to the `fluentd`, `fluentbit`, and `logging-operator` containers.
|
||||
Essentially, these are global settings for all pods in the logging stack.
|
||||
|
||||
However, if you would like to add tolerations for *only* the `fluentbit` container, you can add the following to the chart's values.
|
||||
|
||||
```yaml
|
||||
fluentbit_tolerations:
|
||||
# insert tolerations list for fluentbit containers only...
|
||||
```
|
||||
Reference in New Issue
Block a user