mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-27 05:28:22 +00:00
Merge pull request #2329 from rancher/v2.14.2
Merge release v2.14.2 to main
This commit is contained in:
@@ -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 | ✗ | ✓ |
|
||||
|
||||
## 为什么我们需要它?
|
||||
|
||||
Reference in New Issue
Block a user