[root@k8s-server1 ~]# cat kubeadm-config.yaml |grep token cat: kubeadm-config.yaml: 没有那个文件或目录

很抱歉，我无法直接读取您的服务器上的文件。但是，您可以手动查看文件 "kubeadm-config.yaml" 并使用 grep 命令查找 token。只需键入以下命令：

cat kubeadm-config.yaml | grep token

请确保您在运行该命令之前，已经切换到包含 "kubeadm-config.yaml" 文件的正确目录。

相关问题

TASK [webRoles : print L3 cache] ****************************************************************************************************************************** fatal: [192.168.10.110]: FAILED! => {"msg": "template error while templating string: expected token 'end of print statement', got 'string'. String: 主机{{ inventory_hostname }}的L3缓存为：{{ cache.stdout | grep \"L3\" }}. expected token 'end of print statement', got 'string'"} fatal: [192.168.10.100]: FAILED! => {"msg": "template error while templating string: expected token 'end of print statement', got 'string'. String: 主机{{ inventory_hostname }}的L3缓存为：{{ cache.stdout | grep \"L3\" }}. expected token 'end of print statement', got 'string'"} PLAY RECAP **************************************************************************************************************************************************** 192.168.10.100 : ok=3 changed=2 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 192.168.10.110 : ok=3 changed=2 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 192.168.10.120 : ok=10 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 192.168.10.130 : ok=10 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 [root@node-1 tasks]# cat cache.yaml - name: get cache shell: lscpu register: cache - name: print L3 cache debug: msg='主机{{ inventory_hostname }}的L3缓存为：{{ cache.stdout | grep "L3" }}'

<think>好的，我现在需要分析用户提供的Ansible任务错误信息，并找出问题所在。用户的任务在打印L3缓存时失败了，错误信息是关于模板错误的，提到了“expected token 'end of print statement', got 'string'”。首先，我需要理解这个错误的原因。

首先，用户的任务文件cache.yaml中有两个任务：第一个是运行lscpu命令并将结果注册到cache变量，第二个是使用debug模块打印L3缓存信息。在第二个任务中，用户尝试使用grep过滤器来提取包含"L3"的行，但这里可能语法有误。

在Ansible中，Jinja2模板语法使用管道符应用过滤器，但grep并不是Ansible默认提供的过滤器。用户可能在尝试使用类似于Shell的grep命令，但Ansible中需要使用正确的过滤器，比如regex_search或者使用split结合查找列表中的元素。此外，用户的debug模块的msg参数中的字符串可能没有正确使用引号，导致Jinja2解析错误。

用户的错误信息指出在模板字符串中遇到了意外的字符串，而不是预期的结束语句符号。这可能是因为在msg参数中，用户混用了单引号和双引号，导致解析混乱。例如，在msg='主机{{ ... }}的L3缓存为：{{ cache.stdout | grep "L3" }}'中，最外层使用了单引号，而内部过滤器参数使用了双引号，这可能导致Jinja2解析器在遇到双引号时认为语句未正确结束，从而抛出错误。

此外，使用grep过滤器可能不正确，因为Ansible的Jinja2过滤器中没有内置的grep，正确的做法是使用regex_search或者自定义过滤器。例如，应该使用{{ cache.stdout | regex_search('L3') }}来提取包含L3的行。

可能的解决方案包括：修正引号的使用，确保整个字符串的引号一致，避免内部和外部引号冲突；替换grep为正确的Jinja2过滤器如regex_search；以及确保变量插值的正确性。此外，还需要检查是否在需要列表处理时使用了正确的过滤器，比如当可能有多个匹配行时，可能需要使用select或match等过滤器。

另外，用户可能在Playbook中使用了不兼容的语法，例如在msg参数中直接使用管道符和过滤器，而没有正确转义或使用括号，导致模板引擎无法正确解析表达式。需要确保所有的Jinja2表达式都被正确包裹在{{}}中，并且过滤器应用正确。

总结来说，用户需要做以下调整：将grep替换为regex_search或其他有效过滤器，统一引号的使用以避免解析错误，并确保Jinja2表达式的正确格式。修改后的debug任务可能类似于使用双引号包裹整个msg字符串，并对内部的双引号进行转义，或者改用单引号，同时使用正确的过滤器。例如：msg="主机{{ inventory_hostname }}的L3缓存为：{{ cache.stdout | regex_search('L3.*') }}"。</think>### **错误分析与解决方案**

---

#### **1. 错误定位**
错误信息 `expected token 'end of print statement', got 'string'` 表示 **Jinja2 模板语法错误**，具体原因是：
- 在 `debug` 模块的 `msg` 参数中，混合使用单引号 `'` 和未转义的双引号 `"`，导致模板解析失败。
- 错误写法：

  debug: msg='主机{{ ... }}的L3缓存为：{{ cache.stdout | grep "L3" }}'

---

#### **2. 根本原因**
- **引号冲突**：外层使用单引号 `'` 包裹 `msg`，内部又直接使用双引号 `"L3"`，导致 Jinja2 解析器误判模板边界。
- **非法过滤器**：Ansible 中 **没有内置 `grep` 过滤器**，直接使用 `grep "L3"` 会引发语法错误。

---

#### **3. 修复方案**
##### **方案一：统一引号并转义**

- name: print L3 cache
  debug:
    msg: "主机{{ inventory_hostname }}的L3缓存为：{{ cache.stdout | regex_search('L3.*') }}"

- **关键改动**：
- 使用双引号 `"` 包裹整个 `msg` 参数。
- 用 Ansible 内置的 `regex_search` 替代 `grep`，并修正正则表达式为 `'L3.*'`。

##### **方案二：安全转义写法**

- name: print L3 cache
  debug:
    msg: '主机{{ inventory_hostname }}的L3缓存为：{{ cache.stdout | regex_search("L3.*") }}'

- **关键改动**：
- 外层用单引号 `'`，内部正则表达式用双引号 `"`，避免冲突。

---

#### **4. 验证修复后的效果**
- **正确输出示例**：

  ok: [192.168.10.100] => {
    "msg": "主机192.168.10.100的L3缓存为：L3 cache: 16384K"
  }

---

#### **5. 扩展优化建议**
- **提取具体数值**：若只需提取缓存大小（如 `16384K`），使用正则分组：

  msg: "L3缓存大小：{{ cache.stdout | regex_search('L3 cache:\\s*(\\d+[KMGT]?B?)') | regex_replace('.*?(\\d+[KMGT]?B?).*', '\\1') }}"

- 通过两次正则处理，精准提取数值部分。

- **兼容不同格式**：适配 `L3_cache` 或大小写变体：

  regex_search('L3[_ ]cache.*', ignorecase=True)

---

#### **6. 错误预防**
- **语法检查工具**：使用 `ansible-lint` 检查 Playbook 语法：

  ansible-lint cache.yaml

- **调试模式**：通过 `-vvv` 参数输出详细执行过程：

  ansible-playbook playbook.yml -vvv

---

### **总结**
通过修复引号冲突、替换非法过滤器为 `regex_search`，可解决模板语法错误。建议遵循 Ansible 的 Jinja2 语法规范，优先使用双引号包裹含变量的字符串，并通过正则表达式精准提取目标信息。

Linux k8s 使用 Kubeadm 进行集群部署 ，并定期进行巡检以确保集群的稳定性

<think>嗯，用户问的是如何在Linux上使用Kubeadm部署Kubernetes集群，并且定期巡检以确保稳定性。首先，我需要回顾一下Kubeadm的基本步骤，确保自己记得正确的流程。可能用户是刚开始接触K8s，或者需要搭建一个测试环境，也可能是生产环境。不过考虑到他们提到了定期巡检，可能更偏向于生产环境的维护。

接下来，部署部分需要分步骤讲解。Kubeadm的安装通常包括安装容器运行时、安装kubeadm、kubelet、kubectl，然后初始化控制平面，加入工作节点。需要确认用户是否了解这些组件的用途，可能需要简要说明。同时，常见的安装问题比如swap未关闭、防火墙配置、镜像拉取失败等，应该提醒用户注意。

然后是定期巡检的部分。巡检的内容应该包括节点状态、Pod状态、资源使用情况、网络策略、证书有效期、etcd健康状态、备份情况、安全更新等。用户可能不太清楚具体要检查哪些方面，所以需要详细列出每个检查项，并提供相应的命令示例，比如kubectl get nodes，kubectl top等。巡检周期方面，可能需要建议每日、每周、每月的不同检查频率，但用户可能希望有一个灵活的方案，所以最好给出建议，并说明可以根据实际情况调整。

另外，用户可能需要自动化巡检的方法，比如使用Prometheus和Grafana进行监控，或者编写脚本自动检查并发送报告。这部分可以简要提及，作为高级建议，帮助用户进一步提升效率。

还要注意命令的正确性，比如初始化集群时的参数，可能需要根据最新版本调整。例如，Kubernetes新版本可能不再需要某些参数，或者推荐使用其他配置。比如，1.24版本之后containerd成为默认的容器运行时，可能需要用户提前安装，而不是Docker。需要确认当前的最佳实践，避免给出过时的信息。

在回答结构上，用户之前的对话中，助手使用了分块说明，拆解命令，典型场景，注意事项等。这次也应该保持类似的结构，先讲部署步骤，再讲巡检方法，注意事项，以及可能的工具推荐。同时，使用适当的代码块和公式格式，确保符合用户之前设定的系统级指令，比如独立公式用$$包围，行内用$符号。

还需要考虑用户可能的错误操作，比如忘记关闭swap，或者节点之间时间不同步导致证书问题，巡检时如何检查这些点。比如在巡检部分提到检查节点时间同步状态，使用timedatectl命令。

最后，可能需要提醒用户备份集群的重要配置，比如使用etcd备份，或者在初始化集群时记录生成的join命令，避免丢失。巡检中的备份检查也是关键点，确保在出现故障时可以快速恢复。

总结下来，回答需要结构清晰，分步骤讲解部署流程，详细列出巡检的各个项目和对应的命令，注意事项中强调常见问题，并提供自动化工具的建议。同时，保持语言简洁，符合中文习惯，避免技术术语过于晦涩，让不同层次的用户都能理解。</think>以下是通过 Kubeadm 部署 Kubernetes 集群及维护稳定性的完整指南：

---

### 一、Kubeadm 集群部署流程
#### 1. 环境预检（所有节点）

$ cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
$ sudo modprobe overlay && sudo modprobe br_netfilter
$ swapoff -a && sed -i '/ swap / s/^/#/' /etc/fstab  # 禁用 SWAP
$ sysctl --system  # 加载内核参数

#### 2. 安装容器运行时（以 containerd 为例）

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt-get update && sudo apt-get install -y containerd.io
$ containerd config default | sudo tee /etc/containerd/config.toml
$ sudo systemctl restart containerd

#### 3. 安装 kubeadm/kubelet/kubectl

$ sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl
$ curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg
$ echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get update && sudo apt-get install -y kubelet kubeadm kubectl
$ sudo apt-mark hold kubelet kubeadm kubectl  # 锁定版本

#### 4. 初始化控制平面（Master 节点）

$ sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
  --apiserver-advertise-address=<MASTER_IP> \
  --upload-certs

完成后的关键输出示例：

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

#### 5. 部署网络插件（Calico）

$ kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

#### 6. 加入工作节点

$ kubeadm join <MASTER_IP>:6443 --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<HASH>

---

### 二、集群稳定性巡检方案
#### 每日检查项

$ kubectl get nodes -o wide  # 节点状态
$ kubectl top nodes         # 资源利用率
$ kubectl get pods -A | grep -Ev 'Running|Completed'  # 异常 Pod

#### 每周检查项

$ journalctl -u kubelet --since "1 week ago" | grep -i error  # kubelet 错误日志
$ kubectl get cs              # 组件健康状态
$ kubectl get events -A --sort-by='.metadata.creationTimestamp'  # 事件审计

#### 每月检查项

$ kubeadm certs check-expiration  # 证书有效期（1.19+）
$ etcdctl --endpoints=https://127.0.0.1:2379 \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt endpoint health  # etcd 健康检查

---

### 三、关键维护操作
#### 1. 证书续期

$ kubeadm certs renew all  # 续期所有证书
$ systemctl restart kubelet

#### 2. 版本升级策略
$$ \text{升级顺序：kubeadm → 控制平面 → 工作节点 → kubectl} $$

$ sudo apt-get update && sudo apt-get install -y kubeadm=1.28.2-00
$ sudo kubeadm upgrade plan
$ sudo kubeadm upgrade apply v1.28.2
$ sudo apt-get install -y kubelet=1.28.2-00 kubectl=1.28.2-00
$ sudo systemctl daemon-reload && sudo systemctl restart kubelet

#### 3. 备份恢复（etcd）

# 备份
$ etcdctl snapshot save /data/backup/etcd-snapshot-$(date +%F).db

# 恢复
$ sudo systemctl stop kube-apiserver etcd
$ etcdctl snapshot restore /data/backup/etcd-snapshot.db --data-dir /var/lib/etcd
$ sudo systemctl start etcd kube-apiserver

---

### 四、稳定性增强建议
1. **节点配置优化**

   $ echo 'vm.swappiness=0' >> /etc/sysctl.conf  # 减少内存交换
   $ echo 'net.core.somaxconn=65535' >> /etc/sysctl.conf  # 提升网络性能

2. **监控告警集成**
- 推荐工具栈：Prometheus + Grafana + Alertmanager
- 核心监控指标：
$$ \text{API Server 延迟} \leq 1s,\ \text{节点 CPU 使用率} \leq 80\% $$

3. **自动化巡检脚本示例**

   #!/bin/bash
   ERROR_LOG=$(kubectl get nodes | grep -v Ready)
   if [ -n "$ERROR_LOG" ]; then
     echo "节点异常: $ERROR_LOG" | mail -s "集群告警" admin@example.com
   fi

---

### 五、故障排查速查表
| 现象 | 诊断命令 |
|-----------------------|----------------------------------|
| Pod 无法调度 | `kubectl describe pod <name>` |
| 网络不通 | `kubectl exec -it <pod> -- ping <target>` |
| 镜像拉取失败 | `kubectl get events --field-selector involvedObject.kind=Pod` |
| API Server 无响应 | `curl -k https://localhost:6443/healthz` |

建议将巡检结果记录到文档中，形成可追踪的维护历史记录。