mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
zh/2.8 fix header levels
This commit is contained in:
Billy Tat
+10
-10
@@ -8,7 +8,7 @@ title: DNS
|
||||
|
||||
在运行 DNS 检查之前，请检查集群的[默认 DNS 提供商](../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#默认-dns-提供商)，并确保[覆盖网络正常运行](networking.md#检查覆盖网络是否正常运行)，因为这也可能导致 DNS 解析（部分）失败。
|
||||
|
||||
### 检查 DNS pod 是否正在运行
|
||||
## 检查 DNS pod 是否正在运行
|
||||
|
||||
```
|
||||
kubectl -n kube-system get pods -l k8s-app=kube-dns
|
||||
@@ -26,7 +26,7 @@ NAME READY STATUS RESTARTS AGE
|
||||
kube-dns-5fd74c7488-h6f7n 3/3 Running 0 4m13s
|
||||
```
|
||||
|
||||
### 检查 DNS 服务是否显示正确的 cluster-ip
|
||||
## 检查 DNS 服务是否显示正确的 cluster-ip
|
||||
|
||||
```
|
||||
kubectl -n kube-system get svc -l k8s-app=kube-dns
|
||||
@@ -37,7 +37,7 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
service/kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP 4m13s
|
||||
```
|
||||
|
||||
### 检查是否正在解析域名
|
||||
## 检查是否正在解析域名
|
||||
|
||||
检查是否正在解析内部集群名称（在本例中为 `kubernetes.default`），`Server:` 后面显示的 IP 应与 `kube-dns` 服务的 `CLUSTER-IP` 一致。
|
||||
|
||||
@@ -128,15 +128,15 @@ command terminated with exit code 1
|
||||
|
||||
运行 `kubectl delete ds/dnstest` 清理 alpine DaemonSet。
|
||||
|
||||
### CoreDNS 相关
|
||||
## CoreDNS 相关
|
||||
|
||||
#### 检查 CoreDNS 日志记录
|
||||
### 检查 CoreDNS 日志记录
|
||||
|
||||
```
|
||||
kubectl -n kube-system logs -l k8s-app=kube-dns
|
||||
```
|
||||
|
||||
#### 检查配置
|
||||
### 检查配置
|
||||
|
||||
CoreDNS 配置存储在 `kube-system` 命名空间中 configmap 的 `coredns` 中。
|
||||
|
||||
@@ -144,7 +144,7 @@ CoreDNS 配置存储在 `kube-system` 命名空间中 configmap 的 `coredns`
|
||||
kubectl -n kube-system get configmap coredns -o go-template={{.data.Corefile}}
|
||||
```
|
||||
|
||||
#### 检查 resolv.conf 中的上游名称服务器
|
||||
### 检查 resolv.conf 中的上游名称服务器
|
||||
|
||||
默认情况下，配置在主机（在 `/etc/resolv.conf` 里）上的名称服务器会用作 CoreDNS 的上游名称服务器。你可以在主机上检查此文件，或将 `dnsPolicy` 设置为 `Default`（将继承其主机的 `/etc/resolv.conf`）并运行以下 Pod：
|
||||
|
||||
@@ -152,7 +152,7 @@ kubectl -n kube-system get configmap coredns -o go-template={{.data.Corefile}}
|
||||
kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"dnsPolicy":"Default"}}' -- sh -c 'cat /etc/resolv.conf'
|
||||
```
|
||||
|
||||
#### 启用日志查询
|
||||
### 启用日志查询
|
||||
|
||||
你可以通过在 configmap `coredns` 的 Corefile 配置中启用 [log plugin](https://coredns.io/plugins/log/) 来启用日志查询。为此，你可以使用 `kubectl -n kube-system edit configmap coredns`，或运行以下命令来替换配置：
|
||||
|
||||
@@ -162,9 +162,9 @@ kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log
|
||||
|
||||
这样，所有查询都会记入日志，并且可以使用[检查 CoreDNS 日志记录](#检查-coredns-日志记录)中的命令进行检查。
|
||||
|
||||
### kube-dns 相关
|
||||
## kube-dns 相关
|
||||
|
||||
#### 检查 kubedns 容器中的上游名称服务器
|
||||
### 检查 kubedns 容器中的上游名称服务器
|
||||
|
||||
默认情况下，配置在主机（在 `/etc/resolv.conf` 里）上的名称服务器会用作 kube-dns 的上游名称服务器。有时，主机会运行本地缓存 DNS 名称服务器，这意味着 `/etc/resolv.conf` 中的地址将指向 Loopback 范围（`127.0.0.0/8`）内的地址，而容器将无法访问该范围。对于 Ubuntu 18.04，这是由 `systemd-resolved` 进行的。我们会检测 `systemd-resolved` 是否正在运行，并自动使用具有正确上游名称服务器的 `/etc/resolv.conf` 文件（位于 `/run /systemd/resolve/resolv.conf`）。
|
||||
|
||||
|
||||
+3
-2
@@ -6,14 +6,15 @@ title: 过期 Webhook 证书轮换
|
||||
|
||||
在 Rancher v2.6.3 及更高版本中，rancher-webhook deployments 将在到期日期后 30 天或更短的时间内自动更新其 TLS 证书。如果你使用的是 v2.6.2 或更低版本，你可以通过下面两种方法来解决这个问题。
|
||||
|
||||
##### 1. 如果用户具有集群访问权限，运行以下命令：
|
||||
## 1. 如果用户具有集群访问权限，运行以下命令：
|
||||
|
||||
```
|
||||
kubectl delete secret -n cattle-system cattle-webhook-tls
|
||||
kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
|
||||
kubectl delete pod -n cattle-system -l app=rancher-webhook
|
||||
```
|
||||
|
||||
##### 2. 如果用户没有集群访问权限，使用 `kubectl`：
|
||||
## 2. 如果用户没有集群访问权限，使用 `kubectl`：
|
||||
|
||||
1. 删除 local 集群 `cattle-system` 命名空间中的 `cattle-webhook-tls` 密文。
|
||||
|
||||
|
||||
+4
-4
@@ -6,10 +6,11 @@ title: 网络
|
||||
|
||||
请确保你配置了正确的 kubeconfig（例如，为 Rancher HA 配置了 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
|
||||
|
||||
### 仔细检查你的（主机）防火墙中是否打开了所有必需的端口
|
||||
## 仔细检查你的（主机）防火墙中是否打开了所有必需的端口
|
||||
|
||||
仔细检查你的（主机）防火墙中是否打开了所有[必需的端口](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。其他所需的端口都使用 TCP，而覆盖网络使用 UDP。
|
||||
### 检查覆盖网络是否正常运行
|
||||
|
||||
## 检查覆盖网络是否正常运行
|
||||
|
||||
你可以将 Pod 调度到集群中的任何主机，但是 NGINX Ingress Controller 需要能够将 `NODE_1` 请求路由到 `NODE_2`。这会在覆盖网络上进行。如果覆盖网络无法正常工作，由于 NGINX Ingress Controller 无法路由到 pod，因此 TCP/HTTP 连接会间歇性失败。
|
||||
|
||||
@@ -92,8 +93,7 @@ title: 网络
|
||||
如果你在输出中看到错误，则说明两台主机上的 Pod 路由存在问题。在上面的输出中，节点 `wk2` 在覆盖网络上没有连接。原因可能是没有为 `wk2` 打开覆盖网络的[必需端口](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
|
||||
6. 你现在可以通过运行 `kubectl delete ds/overlaytest` 来清理 DaemonSet。
|
||||
|
||||
|
||||
### 检查主机和对等/隧道设备/设备上的 MTU 是否正确配置
|
||||
## 检查主机和对等/隧道设备/设备上的 MTU 是否正确配置
|
||||
|
||||
如果 MTU 在运行 Rancher 的主机、创建/导入集群中的节点或两者之间的设备上配置不正确，Rancher 和 Agent 会记录类似以下的错误信息：
|
||||
|
||||
|
||||
+7
-7
@@ -6,7 +6,7 @@ title: Rancher HA
|
||||
|
||||
请确保你配置了正确的 kubeconfig（例如，`export KUBECONFIG=$PWD/kube_config_cluster.yml`）。
|
||||
|
||||
### 检查 Rancher Pod
|
||||
## 检查 Rancher Pod
|
||||
|
||||
Rancher pod 会部署为 `cattle-system` 命名空间中的一个 Deployment。
|
||||
|
||||
@@ -27,25 +27,25 @@ rancher-7dbd7875f7-qw7wb 1/1 Running 0 8m x.x.x.x x.x.x.
|
||||
|
||||
如果 pod 无法运行（即状态不是 **Running**，Ready 状态未显示 `1/1`，或者有大量 Restarts），请检查 pod 详细信息，日志和命名空间事件。
|
||||
|
||||
#### Pod 详细信息
|
||||
### Pod 详细信息
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe pods -l app=rancher
|
||||
```
|
||||
|
||||
#### Pod 容器日志
|
||||
### Pod 容器日志
|
||||
|
||||
```
|
||||
kubectl -n cattle-system logs -l app=rancher
|
||||
```
|
||||
|
||||
#### 命名空间事件
|
||||
### 命名空间事件
|
||||
|
||||
```
|
||||
kubectl -n cattle-system get events
|
||||
```
|
||||
|
||||
### 检查 Ingress
|
||||
## 检查 Ingress
|
||||
|
||||
Ingress 应该具有正确的 `HOSTS`（显示配置的 FQDN）和 `ADDRESS`（将被路由到该主机地址）：
|
||||
|
||||
@@ -60,7 +60,7 @@ NAME HOSTS ADDRESS PORTS AGE
|
||||
rancher rancher.yourdomain.com x.x.x.x,x.x.x.x,x.x.x.x 80, 443 2m
|
||||
```
|
||||
|
||||
### 检查 Ingress Controller 日志
|
||||
## 检查 Ingress Controller 日志
|
||||
|
||||
如果访问你配置的 Rancher FQDN 时没有显示 UI，请检查 Ingress Controller 日志以查看尝试访问 Rancher 时发生了什么：
|
||||
|
||||
@@ -68,7 +68,7 @@ rancher rancher.yourdomain.com x.x.x.x,x.x.x.x,x.x.x.x 80, 443 2m
|
||||
kubectl -n ingress-nginx logs -l app=ingress-nginx
|
||||
```
|
||||
|
||||
### Leader 选举
|
||||
## Leader 选举
|
||||
|
||||
Leader 由 Leader 选举确定。确定 Leader 后，Leader（`holderIdentity`）会保存在 `cattle-controllers` ConfigMap 中（在本例中为 `rancher-7dbd7875f7-qbj5k`）：
|
||||
|
||||
|
||||
+3
-3
@@ -6,13 +6,13 @@ title: 注册集群
|
||||
|
||||
请确保你配置了正确的 kubeconfig（例如，`export KUBECONFIG=$PWD/kubeconfig_from_imported_cluster.yml`）。
|
||||
|
||||
### Rancher Agents
|
||||
## Rancher Agents
|
||||
|
||||
Rancher Agent 用于实现与集群的通信（通过 cattle-cluster-agent 的 Kubernetes API）和与节点的通信。
|
||||
|
||||
如果 cattle-cluster-agent 无法连接到配置的 `server-url`，集群将保持在 **Pending** 状态并显示 `Waiting for full cluster configuration`。
|
||||
|
||||
#### cattle-node-agent
|
||||
### cattle-node-agent
|
||||
|
||||
:::note
|
||||
|
||||
@@ -45,7 +45,7 @@ cattle-node-agent-t8mtz 1/1 Running 0 2h x.x.x.x
|
||||
kubectl -n cattle-system logs -l app=cattle-agent
|
||||
```
|
||||
|
||||
#### cattle-cluster-agent
|
||||
### cattle-cluster-agent
|
||||
|
||||
检查 cattle-cluster-agent pod 是否存在于集群中，状态是否为 **Running**，并且重启次数不多：
|
||||
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ Rancher 2.6 增强了审计日志，在 Rancher 和下游 Kubernetes 审计日
|
||||
如果集群传出了审计日志，日志系统的用户就能够识别外部身份提供程序中的用户。
|
||||
Rancher 管理员现在能够查看 Rancher 审计日志，并使用外部身份提供程序用户名来跟踪 Kubernetes 审计日志。
|
||||
|
||||
### 功能描述
|
||||
## 功能描述
|
||||
|
||||
- 在下游集群启用了 Kubernetes 审计日志后，会在“元数据”级别为每个请求记录外部身份提供程序的用户名。
|
||||
- 在 Rancher 启用 Rancher API 审计日志后，每个到达 Rancher API Server 的请求记录（包括登录请求）对应的外部身份提供程序用户名也会记录在 `auditLog.level=1` 中。
|
||||
|
||||
Reference in New Issue
Block a user