mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Merge pull request #2329 from rancher/v2.14.2
Merge release v2.14.2 to main
This commit is contained in:
Sunil Singh
@@ -12,6 +12,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2) | May 28, 2026 |
|
||||
| [2.14.1](https://github.com/rancher/rancher/releases/tag/v2.14.1) | April 30, 2026 |
|
||||
| [2.14.0](https://github.com/rancher/rancher/releases/tag/v2.14.0) | March 25, 2026 |
|
||||
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.14.2 | 109.0.0+up9.0.0 |
|
||||
| v2.14.1 | 109.0.0+up9.0.0 |
|
||||
| v2.14.0 | 109.0.0+up9.0.0 |
|
||||
|
||||
|
||||
@@ -116,6 +116,19 @@ By default, Rancher collects logs for control plane components and node componen
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### The Logging Buffer Overloads Pods
|
||||
|
||||
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
|
||||
|
||||
@@ -20,7 +20,8 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.14.1 | v0.10.1 | ✓ | ✓ |
|
||||
| v2.14.2 | v0.10.5 | ✓ | ✓ |
|
||||
| v2.14.1 | v0.10.4 | ✓ | ✓ |
|
||||
| v2.14.0 | v0.10.0 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
@@ -12,6 +12,7 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
|
||||
|
||||
| Patch 版本 | 发布时间 |
|
||||
| ----------------------------------------------------------------- | ------------------ |
|
||||
| [2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2) | 2026 年 05 月 28 日 |
|
||||
| [2.14.1](https://github.com/rancher/rancher/releases/tag/v2.14.1) | 2026 年 04 月 30 日 |
|
||||
| [2.14.0](https://github.com/rancher/rancher/releases/tag/v2.14.0) | 2026 年 03 月 25 日 |
|
||||
|
||||
|
||||
+1
@@ -15,6 +15,7 @@ title: 安装 Adapter
|
||||
|
||||
| Rancher 版本 | Adapter 版本 |
|
||||
|-----------------|------------------|
|
||||
| v2.14.2 | 109.0.0+up9.0.0 |
|
||||
| v2.14.1 | 109.0.0+up9.0.0 |
|
||||
| v2.14.0 | 109.0.0+up9.0.0 |
|
||||
|
||||
|
||||
+13
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`
|
||||
|
||||
## 故障排除
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
@@ -20,7 +20,8 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.14.1 | v0.10.1 | ✓ | ✓ |
|
||||
| v2.14.2 | v0.10.5 | ✓ | ✓ |
|
||||
| v2.14.1 | v0.10.4 | ✓ | ✓ |
|
||||
| v2.14.0 | v0.10.0 | ✗ | ✓ |
|
||||
|
||||
## 为什么我们需要它？
|
||||
|
||||
+13
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`
|
||||
|
||||
## 故障排除
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
+13
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`
|
||||
|
||||
## 故障排除
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
+13
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`
|
||||
|
||||
## 故障排除
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
+13
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`
|
||||
|
||||
## 故障排除
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
@@ -12,6 +12,7 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/
|
||||
|
||||
| Patch 版本 | 发布时间 |
|
||||
| ----------------------------------------------------------------- | ------------------ |
|
||||
| [2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2) | 2026 年 05 月 28 日 |
|
||||
| [2.14.1](https://github.com/rancher/rancher/releases/tag/v2.14.1) | 2026 年 04 月 30 日 |
|
||||
| [2.14.0](https://github.com/rancher/rancher/releases/tag/v2.14.0) | 2026 年 03 月 25 日 |
|
||||
|
||||
|
||||
+1
@@ -15,6 +15,7 @@ title: 安装 Adapter
|
||||
|
||||
| Rancher 版本 | Adapter 版本 |
|
||||
|-----------------|------------------|
|
||||
| v2.14.2 | 109.0.0+up9.0.0 |
|
||||
| v2.14.1 | 109.0.0+up9.0.0 |
|
||||
| v2.14.0 | 109.0.0+up9.0.0 |
|
||||
|
||||
|
||||
+13
@@ -79,6 +79,19 @@ Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`
|
||||
|
||||
## 故障排除
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
+2
-1
@@ -20,7 +20,8 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.14.1 | v0.10.1 | ✓ | ✓ |
|
||||
| v2.14.2 | v0.10.5 | ✓ | ✓ |
|
||||
| v2.14.1 | v0.10.4 | ✓ | ✓ |
|
||||
| v2.14.0 | v0.10.0 | ✗ | ✓ |
|
||||
|
||||
## 为什么我们需要它？
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
<!-- releaseTask -->
|
||||
The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in December 2025.
|
||||
The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in May 2026.
|
||||
|
||||
| Provider | Project | Stars | Forks | Contributors |
|
||||
| ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | https://github.com/projectcalico/canal | 722 | 97 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 9.4k | 2.9k | 248 |
|
||||
| Canal | https://github.com/projectcalico/canal | 723 | 97 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 9.5k | 2.9k | 249 |
|
||||
| Calico | https://github.com/projectcalico/calico | 7.2k | 1.6k | 412 |
|
||||
| Weave | https://github.com/weaveworks/weave | 6.6k | 675 | 82 |
|
||||
| Cilium | https://github.com/cilium/cilium | 24.2k | 3.7k | 1067 |
|
||||
| Cilium | https://github.com/cilium/cilium | 24.4k | 3.8k | 1085 |
|
||||
|
||||
+10
-2
@@ -17,9 +17,9 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.14.1</b></td>
|
||||
<td><b>v2.14.2</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.14">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.14.1">Release Notes</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.14.2">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
@@ -123,6 +123,14 @@ Here you can find links to supporting documentation for previous versions of Ran
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.14.1</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.14">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.14.1">Release Notes</a></td>
|
||||
<td><center><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-14-1/">Support Matrix</a></center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.14.0</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.14">Documentation</a></td>
|
||||
|
||||
@@ -116,6 +116,19 @@ By default, Rancher collects logs for control plane components and node componen
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### The Logging Buffer Overloads Pods
|
||||
|
||||
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
|
||||
|
||||
@@ -116,6 +116,19 @@ By default, Rancher collects logs for control plane components and node componen
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### The Logging Buffer Overloads Pods
|
||||
|
||||
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
|
||||
|
||||
@@ -116,6 +116,19 @@ By default, Rancher collects logs for control plane components and node componen
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### The Logging Buffer Overloads Pods
|
||||
|
||||
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
|
||||
|
||||
@@ -116,6 +116,19 @@ By default, Rancher collects logs for control plane components and node componen
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### The Logging Buffer Overloads Pods
|
||||
|
||||
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
|
||||
|
||||
@@ -12,6 +12,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.14.2](https://github.com/rancher/rancher/releases/tag/v2.14.2) | May 28, 2026 |
|
||||
| [2.14.1](https://github.com/rancher/rancher/releases/tag/v2.14.1) | April 30, 2026 |
|
||||
| [2.14.0](https://github.com/rancher/rancher/releases/tag/v2.14.0) | March 25, 2026 |
|
||||
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.14.2 | 109.0.0+up9.0.0 |
|
||||
| v2.14.1 | 109.0.0+up9.0.0 |
|
||||
| v2.14.0 | 109.0.0+up9.0.0 |
|
||||
|
||||
|
||||
@@ -116,6 +116,19 @@ By default, Rancher collects logs for control plane components and node componen
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Resource Exhaustion of `inotify` Watchers and File Descriptors
|
||||
|
||||
When enabling the **Logging** app on Linux systems that heavily monitor the filesystem, you may encounter `Too many open files` or `CrashLoopBackOff` failures related to applications that leverage `inotify` to watch for file changes.
|
||||
|
||||
This happens because the Linux kernel caps the number of files a user can open and the number of directory paths a subsystem can watch simultaneously. To resolve this, you must explicitly increase your `inotify` system limits.
|
||||
|
||||
Below are example commands an admin user can run to increase system limits for `inotify` user instances and watches:
|
||||
|
||||
```shell
|
||||
sysctl -w fs.inotify.max_user_instances=8192
|
||||
sysctl -w fs.inotify.max_user_watches=524288
|
||||
```
|
||||
|
||||
### The Logging Buffer Overloads Pods
|
||||
|
||||
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
|
||||
|
||||
@@ -20,7 +20,8 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.14.1 | v0.10.1 | ✓ | ✓ |
|
||||
| v2.14.2 | v0.10.5 | ✓ | ✓ |
|
||||
| v2.14.1 | v0.10.4 | ✓ | ✓ |
|
||||
| v2.14.0 | v0.10.0 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
Reference in New Issue
Block a user