book
/
kubernetes-guide
mirror of https://github.com/imroc/kubernetes-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

update at 2024-04-11 10:24:44

pull/158/head
roc 2024-04-11 10:24:44 +08:00
parent df3ce8f939
commit 8cf9d77577
6 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
content/basics/deploy/terraform.md
View File

@ -4,7 +4,7 @@
## 准备配置文件 ## 准备配置文件
创建 `main.tf`, 可参考[附录](../appendix/terraform) 中的示例，根据自己需求按照注释提示替换内容 创建 `main.tf`, 可参考[附录](../../appendix/terraform/) 中的示例，根据自己需求按照注释提示替换内容
## 创建集群 ## 创建集群
@ -36,13 +36,13 @@ terraform show -json | jq -r '.values.root_module.resources[] | select(.address
> 注意替换 `roc-test` 为自己在 `main.tf` 文件中定义的名字。 > 注意替换 `roc-test` 为自己在 `main.tf` 文件中定义的名字。
使用 [kubecm](../kubectl/merge-kubeconfig-with-kubecm.md) 可以一键导入合并 kubeconfig: 使用 [kubecm](../kubectl/merge-kubeconfig-with-kubecm) 可以一键导入合并 kubeconfig:
```bash ```bash
kubecm add -f eks kubecm add -f eks
``` ```
使用 [kubectx](../kubectl/quick-switch-with-kubectx.md) 可以切换 context: 使用 [kubectx](../kubectl/quick-switch-with-kubectx) 可以切换 context:
```bash ```bash
kubectl ctx eks kubectl ctx eks

2
content/troubleshooting-cases/network/arp-cache-overflow-causing-healthcheck-failed.md
View File

@ -14,4 +14,4 @@ net.ipv4.neigh.default.gc_thresh2 = 90000
net.ipv4.neigh.default.gc_thresh3 = 100000 net.ipv4.neigh.default.gc_thresh3 = 100000
``` ```
并给 node 打下 label，修改 pod spec，加下 nodeSelector 或者 nodeAffnity，让 pod 只调度到这部分改过内核参数的节点，更多请参考本书 [节点排障: ARP 表爆满](../../troubleshooting/node/arp-cache-overflow.md) 并给 node 打下 label，修改 pod spec，加下 nodeSelector 或者 nodeAffnity，让 pod 只调度到这部分改过内核参数的节点，更多请参考本书 [节点排障: ARP 表爆满](../../troubleshooting/node/arp-cache-overflow)

2
content/troubleshooting-cases/network/dns-lookup-5s-delay.md
View File

@ -6,7 +6,7 @@
## 抓包 ## 抓包
* [使用 nsenter 进入 netns](../../troubleshooting/skill/enter-netns-with-nsenter.md)，然后使用节点上的 tcpdump 抓 pod 中的包，发现是有的 DNS 请求没有收到响应，超时 5 秒后，再次发送 DNS 请求才成功收到响应。 * [使用 nsenter 进入 netns](../../troubleshooting/skill/enter-netns-with-nsenter)，然后使用节点上的 tcpdump 抓 pod 中的包，发现是有的 DNS 请求没有收到响应，超时 5 秒后，再次发送 DNS 请求才成功收到响应。
* 在 kube-dns pod 抓包，发现是有 DNS 请求没有到达 kube-dns pod，在中途被丢弃了。 * 在 kube-dns pod 抓包，发现是有 DNS 请求没有到达 kube-dns pod，在中途被丢弃了。
为什么是 5 秒？ `man resolv.conf` 可以看到 glibc 的 resolver 的缺省超时时间是 5s: 为什么是 5 秒？ `man resolv.conf` 可以看到 glibc 的 resolver 的缺省超时时间是 5s:

6
content/troubleshooting/network/dns-exception.md
View File

@ -44,7 +44,7 @@ kube-dns-898dbbfc6-hvwlr 3/3 Running 0 8d 172
$ telnet 172.16.14.217 53 $ telnet 172.16.14.217 53
``` ```
> 如果容器内没有 telnet 等测试工具，可以 [使用 nsenter 进入 netns](../skill/enter-netns-with-nsenter.md)，然后利用宿主机上的 telnet 进行测试。 > 如果容器内没有 telnet 等测试工具，可以 [使用 nsenter 进入 netns](../skill/enter-netns-with-nsenter)，然后利用宿主机上的 telnet 进行测试。
如果检查到是网络不通，就需要排查下网络设置: 如果检查到是网络不通，就需要排查下网络设置:
@ -54,7 +54,7 @@ $ telnet 172.16.14.217 53
### 抓包 ### 抓包
如果前面检查都没问题，可以考虑抓包看下，如果好复现，可以直接 [使用 nsenter 进入 netns](../skill/enter-netns-with-nsenter.md) 抓容器内的包: 如果前面检查都没问题，可以考虑抓包看下，如果好复现，可以直接 [使用 nsenter 进入 netns](../skill/enter-netns-with-nsenter) 抓容器内的包:
```bash ```bash
tcpdump -i any port 53 -w dns.pcap tcpdump -i any port 53 -w dns.pcap
@ -67,7 +67,7 @@ tcpdump -i any port 53 -w dns.pcap
### 5 秒延时 ### 5 秒延时
如果DNS查询经常延时5秒才返回，通常是遇到内核 conntrack 冲突导致的丢包，详见 [排障案例: DNS 5秒延时](../cases/network/dns-lookup-5s-delay.md) 如果DNS查询经常延时5秒才返回，通常是遇到内核 conntrack 冲突导致的丢包，详见 [排障案例: DNS 5秒延时](../../troubleshooting-cases/network/dns-lookup-5s-delay)
### 解析外部域名超时 ### 解析外部域名超时

2
content/troubleshooting/node/no-space-left-on-device.md
View File

@ -45,7 +45,7 @@ $ find -L /sys/fs/cgroup/memory -type d | wc -l
当 cgroup 泄露发生时，这里的数量就不是真实的了，低版本内核限制最大 65535 个 cgroup，并且开启 kmem 删除 cgroup 时会泄露，大量创建删除容器后泄露了许多 cgroup，最终总数达到 65535，新建容器创建 cgroup 将会失败，报 `no space left on device` 当 cgroup 泄露发生时，这里的数量就不是真实的了，低版本内核限制最大 65535 个 cgroup，并且开启 kmem 删除 cgroup 时会泄露，大量创建删除容器后泄露了许多 cgroup，最终总数达到 65535，新建容器创建 cgroup 将会失败，报 `no space left on device`
详细请参考本书 [排障案例: cgroup 泄露](../cases/node/cgroup-leaking.md) 详细请参考本书 [排障案例: cgroup 泄露](../../troubleshooting-cases/node/cgroup-leaking)
## 磁盘被写满 ## 磁盘被写满

4
content/troubleshooting/pod/status/pod-terminating.md
View File

@ -211,7 +211,7 @@ $ grep 8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59 /proc/*/
ps -f 27187 ps -f 27187
``` ```
> 更多请参考 [排查 device or resource busy](../device-or-resource-busy.md)。 > 更多请参考 [排查 device or resource busy](../device-or-resource-busy)。
## 检查 Finalizers ## 检查 Finalizers
@ -241,4 +241,4 @@ Pod 事件报错:
unlinkat /var/run/netns/cni-49ddd103-d374-1f86-7324-13abaeb9c910: device or resource busy unlinkat /var/run/netns/cni-49ddd103-d374-1f86-7324-13abaeb9c910: device or resource busy
``` ```
原因与解决方案参考: [挂载根目录导致 device or resource busy](../../cases/runtime/mount-root-causing-device-or-resource-busy.md)。 原因与解决方案参考: [挂载根目录导致 device or resource busy](../../../troubleshooting-cases/runtime/mount-root-causing-device-or-resource-busy)。