搜索到
98
篇与
的结果
-
问题 一、找回密码root@k8s-01:~# kubectl -n monitoring get pod | grep grafana grafana-7ff454c477-l9x2k 1/1 Running 0 8d root@k8s-01:~# kubectl -n monitoring exec -it grafana-7ff454c477-l9x2k -- sh /usr/share/grafana $ grafana-cli admin reset-admin-password '33070595Abc' Deprecation warning: The standalone 'grafana-cli' program is deprecated and will be removed in the future. Please update all uses of 'grafana-cli' to 'grafana cli' INFO [01-29|12:45:37] Starting Grafana logger=settings version= commit= branch= compiled=1970-01-01T00:00:00Z INFO [01-29|12:45:37] Config loaded from logger=settings file=/usr/share/grafana/conf/defaults.ini INFO [01-29|12:45:37] Config overridden from Environment variable logger=settings var="GF_PATHS_DATA=/var/lib/grafana" INFO [01-29|12:45:37] Config overridden from Environment variable logger=settings var="GF_PATHS_LOGS=/var/log/grafana" INFO [01-29|12:45:37] Config overridden from Environment variable logger=settings var="GF_PATHS_PLUGINS=/var/lib/grafana/plugins" INFO [01-29|12:45:37] Config overridden from Environment variable logger=settings var="GF_PATHS_PROVISIONING=/etc/grafana/provisioning" INFO [01-29|12:45:37] Target logger=settings target=[all] INFO [01-29|12:45:37] Path Home logger=settings path=/usr/share/grafana INFO [01-29|12:45:37] Path Data logger=settings path=/var/lib/grafana INFO [01-29|12:45:37] Path Logs logger=settings path=/var/log/grafana INFO [01-29|12:45:37] Path Plugins logger=settings path=/var/lib/grafana/plugins INFO [01-29|12:45:37] Path Provisioning logger=settings path=/etc/grafana/provisioning INFO [01-29|12:45:37] App mode production logger=settings INFO [01-29|12:45:37] FeatureToggles logger=featuremgmt recoveryThreshold=true panelMonitoring=true lokiQuerySplitting=true nestedFolders=true logsContextDatasourceUi=true cloudWatchNewLabelParsing=true logRowsPopoverMenu=true kubernetesPlaylists=true dataplaneFrontendFallback=true recordedQueriesMulti=true transformationsVariableSupport=true addFieldFromCalculationStatFunctions=true cloudWatchCrossAccountQuerying=true prometheusAzureOverrideAudience=true lokiQueryHints=true logsExploreTableVisualisation=true annotationPermissionUpdate=true lokiMetricDataplane=true prometheusMetricEncyclopedia=true lokiStructuredMetadata=true topnav=true alertingInsights=true exploreMetrics=true formatString=true ssoSettingsApi=true autoMigrateXYChartPanel=true tlsMemcached=true prometheusConfigOverhaulAuth=true logsInfiniteScrolling=true alertingSimplifiedRouting=true awsAsyncQueryCaching=true managedPluginsInstall=true cloudWatchRoundUpEndTime=true transformationsRedesign=true alertingNoDataErrorExecution=true dashgpt=true influxdbBackendMigration=true prometheusDataplane=true groupToNestedTableTransformation=true correlations=true publicDashboards=true angularDeprecationUI=true INFO [01-29|12:45:37] Connecting to DB logger=sqlstore dbtype=sqlite3 INFO [01-29|12:45:37] Locking database logger=migrator INFO [01-29|12:45:37] Starting DB migrations logger=migrator INFO [01-29|12:45:37] migrations completed logger=migrator performed=0 skipped=594 duration=359.617µs INFO [01-29|12:45:37] Unlocking database logger=migrator INFO [01-29|12:45:37] Envelope encryption state logger=secrets enabled=true current provider=secretKey.v1 Admin password changed successfully ✔ /usr/share/grafana $ exit root@k8s-01:~# cat <<'EOF' | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-traefik-to-grafana namespace: monitoring spec: podSelector: matchLabels: app.kubernetes.io/component: grafana app.kubernetes.io/name: grafana app.kubernetes.io/part-of: kube-prometheus policyTypes: ["Ingress"] ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: traefik ports: - protocol: TCP port: 3000 --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-traefik-to-prometheus namespace: monitoring spec: podSelector: matchLabels: app.kubernetes.io/component: prometheus app.kubernetes.io/instance: k8s app.kubernetes.io/name: prometheus app.kubernetes.io/part-of: kube-prometheus policyTypes: ["Ingress"] ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: traefik ports: - protocol: TCP port: 9090 --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-traefik-to-alertmanager namespace: monitoring spec: podSelector: matchLabels: app.kubernetes.io/component: alert-router app.kubernetes.io/instance: main app.kubernetes.io/name: alertmanager app.kubernetes.io/part-of: kube-prometheus policyTypes: ["Ingress"] ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: traefik ports: - protocol: TCP port: 9093 EOF 需要放行 monitoring 里原来的 NetworkPolicy 没放行 traefik → 导致 Traefik 转发到 grafana/prometheus/alertmanager 全部被丢包，最后表现成 504/超时。#添加节点 创建 additionalScrapeConfigs 的 Secret（把外部节点加进去） #我这里用 job_name: node-exporter 是为了让你现成的 Node Exporter / Nodes 仪表盘直接复用（很多面板按 job 过滤）。 cat <<'EOF' | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: prometheus-additional-scrape-configs namespace: monitoring type: Opaque stringData: additional-scrape-configs.yaml: | - job_name: node-exporter static_configs: - targets: - 192.168.1.12:9100 - 192.168.1.15:9100 - 192.168.1.30:9100 labels: origin: external relabel_configs: - source_labels: [__address__] target_label: instance regex: '([^:]+):\d+' replacement: '$1' EOF #把 Secret 挂到 Prometheus（prometheus-k8s） kubectl -n monitoring patch prometheus prometheus-k8s --type merge -p ' { "spec": { "additionalScrapeConfigs": { "name": "prometheus-additional-scrape-configs", "key": "additional-scrape-configs.yaml" } } }' #验证 kubectl -n monitoring port-forward svc/prometheus-k8s 9090:9090 -
-
-
istio istio是什么？Istio 是一种开源服务网格，可透明地分层到现有的分布式应用程序上。 Istio 的强大功能提供了一种统一且更高效的方式来保护、连接和监控服务。 Istio 是实现负载均衡、服务到服务身份验证和监控的途径 - 几乎无需更改服务代码。 功能： 使用双向 TLS 加密、强大的基于身份的身份验证和鉴权在集群中保护服务到服务通信 HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡 使用丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制 支持访问控制、限流和配额的可插入策略层和配置 API 集群内所有流量（包括集群入口和出口）的自动指标、日志和链路追踪 如何工作？ Istio 使用代理来拦截您的所有网络流量，从而根据您设置的配置允许使用一系列应用程序感知功能。 控制平面采用您所需的配置及其对服务的视图，并动态地编程代理服务器，并根据规则或环境的变化对其进行更新。 数据平面是服务之间的通信。如果没有服务网格，网络就无法理解正在发送的流量，也无法根据流量类型、流量来源或目的地做出任何决策。 Istio 支持两种数据平面模式： Sidecar 模式，它会与您在集群中启动的每个 Pod 一起部署一个 Envoy 代理，或者与在虚拟机上运行的服务一同运行。（下面使用的了sidecar模式） Ambient 模式，它使用每个节点的四层代理，并且可选地使用每个命名空间的 Envoy 代理来实现七层功能。 一、部署#官网 https://istio.io/#下载 https://github.com/istio/istio/releases/download/1.28.2/istio-1.28.2-linux-amd64.tar.gz #解压 tar -zxvf istio-1.28.2-linux-amd64.tar.gz #部署 root@k8s-01:/woke/istio# ls istio-1.28.2 istio-1.28.2-linux-amd64.tar.gz root@k8s-01:/woke/istio# cd istio-1.28.2/ root@k8s-01:/woke/istio/istio-1.28.2# export PATH=$PWD/bin:$PATH root@k8s-01:/woke/istio/istio-1.28.2# istioctl install -f samples/bookinfo/demo-profile-no-gateways.yaml -y |\ | \ | \ | \ /|| \ / || \ / || \ / || \ / || \ / || \ /______||__________\ ____________________ \__ _____/ \_____/ ✔ Istio core installed ⛵️ Processing resources for Istiod. Waiting for Deployment/istio-system/istiod ✔ Istiod installed 🧠 ✔ Installation complete root@k8s-01:/woke/istio/istio-1.28.2# kubectl label namespace default istio-injection=enabled namespace/default labeled root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# kubectl get crd gateways.gateway.networking.k8s.io NAME CREATED AT gateways.gateway.networking.k8s.io 2025-11-17T15:05:26Z root@k8s-01:/woke/istio/istio-1.28.2# kubectl get crd httproutes.gateway.networking.k8s.io NAME CREATED AT httproutes.gateway.networking.k8s.io 2025-11-17T15:05:26Z root@k8s-01:/woke/istio/istio-1.28.2# kubectl get crd gatewayclasses.gateway.networking.k8s.io NAME CREATED AT gatewayclasses.gateway.networking.k8s.io 2025-11-17T15:05:26Z root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# kubectl get crd | egrep 'tlsroutes|tcproutes|udproutes|grpcroutes\.gateway\.networking\.k8s\.io' grpcroutes.gateway.networking.k8s.io 2025-11-17T15:05:26Z root@k8s-01:/woke/istio/istio-1.28.2# kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>" <title>Simple Bookstore App</title> root@k8s-01:/woke/istio/istio-1.28.2# kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml gateway.networking.istio.io/bookinfo-gateway created virtualservice.networking.istio.io/bookinfo created root@k8s-01:/woke/istio/istio-1.28.2# kubectl get gateway NAME CLASS ADDRESS PROGRAMMED AGE traefik-gw traefik True 25d root@k8s-01:/woke/istio/istio-1.28.2# kubectl get gateway NAME CLASS ADDRESS PROGRAMMED AGE traefik-gw traefik True 25d root@k8s-01:/woke/istio/istio-1.28.2# kubectl get pod -A | grep gateway root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# kubectl get gateways.networking.istio.io -A kubectl get virtualservices.networking.istio.io -A NAMESPACE NAME AGE default bookinfo-gateway 2m55s NAMESPACE NAME GATEWAYS HOSTS AGE default bookinfo ["bookinfo-gateway"] ["*"] 2m55s root@k8s-01:/woke/istio/istio-1.28.2# kubectl get svc -n istio-system | egrep 'ingress|gateway' kubectl get pods -n istio-system | egrep 'ingress|gateway' root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# istioctl install -y --set profile=demo istioctl: command not found root@k8s-01:/woke/istio/istio-1.28.2# ls bin LICENSE manifests manifest.yaml README.md samples tools root@k8s-01:/woke/istio/istio-1.28.2# export PATH=$PWD/bin:$PATH istioctl version client version: 1.28.2 control plane version: 1.28.2 data plane version: 1.28.2 (6 proxies) root@k8s-01:/woke/istio/istio-1.28.2# istioctl install -y --set profile=demo |\ | \ | \ | \ /|| \ / || \ / || \ / || \ / || \ / || \ /______||__________\ ____________________ \__ _____/ \_____/ ✔ Istio core installed ⛵️ ✔ Istiod installed 🧠 ✔ Egress gateways installed 🛫 ✔ Ingress gateways installed 🛬 ✔ Installation complete root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# root@k8s-01:/woke/istio/istio-1.28.2# kubectl get pods -n istio-system | egrep 'istio-ingressgateway|istiod' kubectl get svc -n istio-system | egrep 'istio-ingressgateway' istio-ingressgateway-796f5cf647-n28c8 1/1 Running 0 107s istiod-5c84f8c79d-q7p2x 1/1 Running 0 91m istio-ingressgateway LoadBalancer 10.99.189.246 <pending> 15021:31689/TCP,80:32241/TCP,443:30394/TCP,31400:31664/TCP,15443:32466/TCP 107s #调通 root@k8s-01:/woke/istio/istio-1.28.2# kubectl port-forward -n istio-system svc/istio-ingressgateway 8080:80 Forwarding from 127.0.0.1:8080 -> 8080 Forwarding from [::1]:8080 -> 8080 Handling connection for 8080 #访问 root@k8s-01:/woke/istio/istio-1.28.2# curl -sS http://127.0.0.1:8080/productpage | grep -o "<title>.*</title>" <title>Simple Bookstore App</title> 1）更细的发布策略（不止权重灰度） 基于请求特征的灰度（更精准） 按 Header（用户/设备/地区/灰度标记） 按 Cookie（特定用户群） 按 URI（某些路径走新版本） 例子：带 x-canary: true 的请求走 v2，其余走 v1。 镜像流量（Shadow / Mirroring） 真实流量仍走 v1 同时“复制一份”给 v2 做压测/验证（不影响线上返回） 适合：验证新版本行为、性能。 2）限流与保护（Resilience） 超时 / 重试 / 连接池 timeout: 2s retries: attempts: 3 连接池限制（避免下游被打爆） 熔断 / 异常剔除（Outlier Detection） 连续 5xx 多就把某个 pod/实例踢出一段时间 故障注入（Chaos Testing） 人为注入延迟/错误（只对某类请求），验证系统韧性 3）流量控制与安全 mTLS 加密（服务到服务） 自动给网格内东西向流量加密 可做 STRICT/ PERMISSIVE 模式 配 PeerAuthentication / DestinationRule 细粒度访问控制（RBAC） 谁可以访问谁、什么路径、什么方法 支持基于 JWT claim、source principal、namespace、ip 等条件 用 AuthorizationPolicy JWT/OIDC 校验（API 鉴权） 在网关或服务侧校验 token（不必应用自己写） 用 RequestAuthentication + AuthorizationPolicy 4）入口网关能力（North-South） 多域名/多证书（HTTPS/TLS） Gateway 配多 SNI、证书、重定向 HTTP→HTTPS 路径重写/跳转/多服务路由 /api 去 A 服务、/web 去 B 服务 rewrite /v1 → / 等 速率限制（通常需配合 EnvoyFilter 或外部组件） 入口处做全局/按 key（IP、用户）限流 （Istio 原生 CRD 的“全局限流”需要看你用的扩展方案，常见是 Envoy ext-authz / ratelimit service） 5）可观测性（你在 Kiali/Prometheus 上看到的背后能力） 指标：QPS、P99、错误率、TCP 指标 分布式追踪：Jaeger/Zipkin/Tempo（需要装 tracing） 访问日志：Envoy access log（可输出到 stdout 或日志系统） 拓扑：Kiali 图里展示服务调用关系 6）多集群/多网格（更高级） 多集群同网格 跨集群服务发现与 mTLS East-West Gateway 给你一个“从 Bookinfo 出发最值得尝试”的 6 个玩法（上手快） Header 灰度：指定用户走 reviews v3 流量镜像：把部分流量镜像到 v3（不影响返回） 超时+重试：让 productpage 调 reviews 更稳定 熔断：reviews 出现错误时自动隔离坏实例 故障注入：只对某路径注入 2s 延迟测试体验 mTLS STRICT + 授权策略：禁止网格外/未授权服务访问 reviews
-
问题 调用 grafana 接口失败 error trying to reach service: dial tcp 10.244.2.60:3000: i/o timeout① 背景（30 秒） “有一次我们在 Kubernetes 集群里部署监控体系（Prometheus + Grafana），Grafana Pod 本身是 Running 的，但从节点或者其他组件访问 Grafana 的 Pod IP 的时候一直超时，curl 会直接 i/o timeout，影响监控平台的接入和联调。” “表面看 Grafana 是正常的，但网络层面存在异常。”② 问题拆解与排查思路（1 分钟） “我当时按分层排查的思路来做，而不是直接改网络策略。” 1️⃣ 先排除应用问题 我先 kubectl exec 进 Grafana Pod，直接 curl 127.0.0.1:3000/api/health 返回 200，说明 Grafana 本身没问题，端口监听正常 👉 这一步可以明确：不是应用、不是容器启动问题。 2️⃣ 再定位是 Service 层还是 Pod 网络问题 我确认 Service / Endpoint 都指向正确的 Pod IP 但从节点直接 curl PodIP 仍然超时 在同节点起一个临时 curl Pod 访问 PodIP，也同样超时 👉 这一步可以确定： 不是宿主机路由问题，而是 Pod 网络路径被拦截。 3️⃣ 确认 CNI 和隧道是否正常 集群使用的是 Cilium + VXLAN 我抓包看到 8472/UDP 的 VXLAN 流量是存在的 说明 overlay 隧道本身工作正常，否则整个集群通信都会异常 👉 到这里，网络连通性问题基本被排除。③ 关键突破点（40 秒） “真正的突破点是在 Cilium 的可观测工具 上。” 我在节点上执行了： cilium monitor --type drop 发现每一次访问 Grafana 3000 端口的 TCP SYN 都被丢弃 丢包原因非常明确：Policy denied 源身份显示为 remote-node 或 host 👉 这一步明确告诉我： 不是网络问题，而是被 Cilium 的策略明确拒绝了。④ 根因分析（30 秒） “回头检查发现，Grafana 所在命名空间里存在默认的 NetworkPolicy，只允许 Prometheus Pod 访问 Grafana 的 3000 端口。” 节点 / 宿主机访问 Grafana 时： 在 Cilium 里会被标记为 host 或 remote-node 并不属于普通 Pod identity 所以即使我用 Kubernetes NetworkPolicy 加了 ipBlock，依然无法命中这类流量 👉 本质原因是： Cilium 是以 identity/entity 为核心做策略决策，而不是单纯基于 IP。⑤ 解决方案（30 秒） “最终我使用的是 CiliumNetworkPolicy，显式放行来自节点的流量。” 在策略里允许： fromEntities: host fromEntities: remote-node 只放行到 Grafana 的 3000/TCP 应用策略后，从节点 curl PodIP 立刻恢复正常。⑥ 总结与价值（20 秒） “这个问题让我印象很深的一点是： 在使用 Cilium 这类 eBPF CNI 时，排查网络问题一定要用它自己的观测工具，而不是只停留在 Kubernetes NetworkPolicy 的抽象层。” “后续我也把这个问题整理成了 SOP，明确： Pod→Pod Node→Pod Service→Pod 在 Cilium 下对应的 identity 和策略差异，避免再踩坑。”面试官常见追问 & 标准答法（加分项） ❓追问 1：为什么 ipBlock 不生效？ 答： “因为在 Cilium 里，Node / Host 流量优先按 identity（host / remote-node）匹配策略，而不是单纯按源 IP。 NetworkPolicy 的 ipBlock 在这类流量场景下不会命中，所以需要用 CiliumNetworkPolicy 的 fromEntities。” ❓追问 2：为什么不用 NodePort / LoadBalancer？ 答： “NodePort 确实能绕开 Pod 网络策略，但会引入额外暴露面，不符合最小权限原则。 这里的目标只是节点内部访问 Pod 服务，用 CNI 级别策略精确放行更安全、更可控。” ❓追问 3：如何避免以后再发生？ 答： 明确区分 Pod 流量 vs Node/Host 流量 在启用 Cilium 的集群里： 默认 NetworkPolicy + 例外的 CiliumNetworkPolicy 遇到网络问题第一时间用 cilium monitor / hubble observe 定位丢包原因，而不是盲改规则 🧠 面试官听到的“隐藏信号” 你这段回答会传递出几个非常强的信号： 你理解 CNI 底层实现，不只是会写 YAML 你会用 可观测工具定位问题 你做的是 体系化排障，而不是拍脑袋改配置 你有 复盘和沉淀能力 如果你愿意，下一步我还能帮你： 把这个案例改成 简历上的一条高质量项目经历 或模拟一次面试官“深挖追问”的对话，帮你把回答打磨到非常顺 你这个案例，放在 K8s 运维 / 平台工程 / SRE 面试里，是妥妥的加分项。root@k8s-01:~# cat > /tmp/cnp-allow-grafana-3000-from-nodes.yaml <<'EOF' apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-grafana-3000-from-nodes namespace: kuboard spec: endpointSelector: matchLabels: app.kubernetes.io/name: grafana ingress: - fromEntities: - host - remote-node toPorts: - ports: - port: "3000" protocol: TCP EOF kubectl apply -f /tmp/cnp-allow-grafana-3000-from-nodes.yaml kubectl -n kuboard get cnp | grep allow-grafana-3000-from-nodes ciliumnetworkpolicy.cilium.io/allow-grafana-3000-from-nodes created allow-grafana-3000-from-nodes 0s True root@k8s-01:~# curl -sS -m 3 http://10.244.2.60:3000/api/health { "database": "ok", "version": "11.2.0", "commit": "2a88694fd3ced0335bf3726cc5d0adc2d1858855" }root@k8s-01:~# 可以了 你现在是一个资深的k8s运维工程师 你帮我详细复盘分析之前的上下文 然后总结根因是什么？怎么解决的？为什么会出现这种情况 然后我想把这个问题也在面试上比如面试官问我 工作当中遇到了什么问题 可以说这个 我是怎么遇到这个问题的 过程尝试了用什么方法解决 然后最后怎么找到问题的 怎么解决的 下面我按“资深 K8s 运维复盘”的方式，把你这次 Grafana Pod IP 不通的问题完整复盘一遍：现象 → 排查路径 → 关键证据 → 根因 → 解决方案 → 为什么会这样。最后再给你一段面试可直接复述的 STAR/故事版本。 1）现象是什么 Pod 里 Grafana 本身是好的： kubectl exec grafana -- curl 127.0.0.1:3000/api/health 返回 OK 日志正常、监听正常（Grafana 启动成功） 但是从 宿主机 / 节点 访问 Pod IP 超时： curl http://10.244.2.60:3000/api/health → i/o timeout 从 同节点的测试 Pod 访问 Pod IP 也超时： 你在 k8s-01 强制调度了 curlimages/curl 去 curl PodIP，仍然 timeout 这说明：不是“宿主机路由不通”，而是“到 Pod 的流量在某处被拦截/丢弃” 2）你做了哪些正确的排查动作（过程复盘） A. 先确认应用是否健康（排除应用问题） 你先在 grafana 容器内 curl 自己： 容器内 OK → Grafana 服务与端口没问题 这一步很关键：把“应用/容器问题”先排掉。 B. 再验证网络路径（区分 host、pod、service） kubectl get svc/ep 确认 endpoint 就是 10.244.2.60:3000 curl PodIP 超时，说明不是 Service 负载均衡层的问题，而是到 endpoint 的流量被拦截 C. 检查 CNI 模式与隧道 你确认了 Cilium 配置： routing-mode: tunnel tunnel-protocol: vxlan 并且抓包能看到 8472/UDP 的 VXLAN 流量 进出（说明隧道本身在工作） 这一点也非常关键：overlay 通道是通的，否则集群内大量 Pod 通信都会异常。 D. 最关键的一步：用 Cilium 观测“丢包原因” 你执行： cilium monitor --type drop 立刻得到核心证据： xx drop (Policy denied) ... identity 6820->29952: 10.244.0.206 -> 10.244.2.60:3000 tcp SYN 以及后面： xx drop (Policy denied) ... identity remote-node->29952: 10.244.0.18 -> 10.244.2.60:3000 tcp SYN 这两条信息极其重要，等价于告诉你： 不是路由问题 不是端口没监听 是 Cilium 的策略（Policy）明确拒绝了 SYN 到这一步，根因已经锁定在 NetworkPolicy / CiliumPolicy 方向。 3）根因是什么（总结一句话版） Grafana 所在命名空间存在默认更严格的 NetworkPolicy（只允许 Prometheus Pod 访问 Grafana:3000），而节点/宿主机流量在 Cilium 里被标记成 remote-node/host 身份，不会被普通 K8s NetworkPolicy 的 ipBlock 命中，最终被 Cilium 以 Policy denied 丢弃。 再拆开说得更专业一点： 你原来的 NetworkPolicy（kuboard/grafana）是这样： ingress: - from: - podSelector: matchLabels: app.kubernetes.io/name: prometheus ports: - port: 3000 含义是： 只允许 prometheus 的 Pod 去访问 grafana 的 3000 其他来源（包括你从节点直接 curl PodIP）默认拒绝 为什么你加了 K8s NetworkPolicy（ipBlock）也没效果？ 因为你的访问路径是“节点/宿主机 → Pod”： 从节点发起的流量到了 Cilium，会以 entity identity 来归类： host（本节点宿主机） remote-node（其他节点过来的 node traffic） 这类流量不是普通 Pod identity，很多情况下也不是单纯按源 IP去匹配 NetworkPolicy 的 ipBlock（尤其在 Cilium 的实现/模式下，优先按 identity 进行策略决策）。 所以你看到的现象就是： 你用 ipBlock: 192.168.1.0/24 放行 —— 依然被 remote-node identity 拒绝 你用 ipBlock: 10.244.0.0/16 放行 —— 依然被 remote-node identity 拒绝 而 cilium monitor 也明确显示拒绝原因是：Policy denied + identity remote-node->... 4）怎么解决的（你最终的正确做法） 你最终用了 CiliumNetworkPolicy： apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy spec: endpointSelector: matchLabels: app.kubernetes.io/name: grafana ingress: - fromEntities: - host - remote-node toPorts: - ports: - port: "3000" protocol: TCP 这条规则的效果是： 明确放行 Cilium 的 entity host：本机宿主机进来的流量 remote-node：其他节点过来的 node 流量 只放行到 grafana pod 的 3000/TCP 所以你立刻在 k8s-01 上 curl PodIP 成功 5）为什么会出现这种情况（更“体系化”的解释） 1）装监控栈/平台时经常自带 NetworkPolicy 很多 kube-prometheus-stack / 平台化套件会默认创建 NetworkPolicy，实现“默认拒绝 + 白名单放行”，比如： Prometheus 可 scrape 其他来源默认不允许访问 UI/端口 这属于“安全默认值”，但会让排障时出现“明明 Pod Running，却访问超时”。 2）Cilium 对 Node/Host 流量有自己的 identity 体系 Cilium 的策略引擎不是只看 IP，而是以 identity/entity 为第一等公民： Pod 有 identity（基于 labels） Node/Host/Remote-node 是 entity 所以要放通 node→pod，最稳的是用 fromEntities: host/remote-node 这也是你最终方案成功的根本原因。 3）“Pod->Pod 通，Node->Pod 不通”是典型特征 因为： Pod→Pod 可能被某些 policy 放行了（或在同 namespace 里满足 selector） Node→Pod 不属于 podSelector 能匹配的对象，常被默认 deny 6）面试：如何把这件事讲成一个漂亮的“排障故事” 下面给你一个可直接背的版本（STAR + 技术细节），你按自己实际环境改两句就能用。 面试复述版本（建议 2~3 分钟） 背景（S） “我们在 K8s 集群里部署监控（Grafana/Prometheus），Grafana Pod Running，但业务方/运维侧从节点访问 Grafana API 一直 i/o timeout，影响监控平台接入和联调。” 任务（T） “我需要快速确认是应用问题、服务暴露问题还是集群网络策略问题，并给出可控的修复方案。” 行动（A） 先排除应用故障：进入 Grafana Pod 内部 curl 127.0.0.1:3000/api/health，确认服务健康、端口正常监听。 定位网络层级：从节点 curl PodIP 超时，同时在同节点跑一个临时 curl Pod 访问 PodIP 也超时，说明不是宿主机网络工具问题，而是集群网络路径被拦。 检查 CNI 与隧道：确认集群使用 Cilium，VXLAN 隧道 8472/UDP 有流量，说明 overlay 本身工作正常。 用可观测手段找“丢包理由”：运行 cilium monitor --type drop，发现对 Grafana:3000 的 SYN 被明确标记为 Policy denied，源身份显示为 remote-node/host。 回查 NetworkPolicy：发现 Grafana 命名空间有默认 NetworkPolicy，只允许 Prometheus Pod 访问 Grafana 3000，节点/宿主机流量不在白名单内，因此被 Cilium 拒绝。 修复策略：使用 CiliumNetworkPolicy 放行 fromEntities: host, remote-node 到 Grafana 的 3000/TCP，修复后节点 curl PodIP 立刻恢复。 结果（R） “Grafana API 访问恢复，监控平台联调继续推进。过程中我把排查步骤固化成 SOP：先应用健康检查→再分层定位→最后用 CNI 可观测工具确认策略/丢包原因，避免盲目改防火墙或路由。” 补充亮点（技术总结） “这类问题的关键点在于：Cilium 以 identity/entity 为核心做策略决策，Node/Host 流量常显示为 remote-node/host，单纯用 K8s NetworkPolicy 的 ipBlock 不一定能匹配到，需要用 CiliumNetworkPolicy 的 fromEntities 精准放行。”你是一个资深的k8s云原生运维工程师 你觉得碰到的这个问题有深度吗？ 有，而且深度不在“Grafana 访问不通”这件事本身，而在你最后定位到的点：Cilium（eBPF）语义下，Host/Node 流量与 Pod 流量的身份模型差异，这已经超出“会用 K8s”的层级了。 我用面试官视角给你拆一下它为什么算“有深度”。 为什么这个问题有深度 1) 不是“网络不通”，是“策略语义不一致” 你一开始看到的是 timeout，很容易被带偏去查： VXLAN 8472/UDP、防火墙、路由、MTU、kube-proxy、Service/Endpoint 但最终根因是： NetworkPolicy 只放了 Prometheus 节点访问在 Cilium 里变成 host/remote-node identity 所以被 Policy denied 掉了 这属于 “抽象层（K8s NP） vs 实现层（Cilium identity/entity）”的差异问题，很典型也很难踩得准。 2) 你用的是“正确的高级排障工具链” 真正有经验的人会很快转向： cilium monitor --type drop / hubble 而不是一直“猜”。 你抓到的那句： drop (Policy denied) ... identity remote-node->... tcp SYN 这就是一锤定音的证据链。很多人排障卡住就是因为拿不到“谁丢的、为什么丢”。 3) 这是“集群行为”层面的知识点，不是某个组件 bug 你解决的不是 Grafana，也不是 curl，而是： CNI datapath identity-based enforcement node/host traffic classification NetworkPolicy 与 CiliumNetworkPolicy 的边界 这类问题在生产里经常发生在： metrics/health check 从节点探测 Pod ingress controller / node-local agent 访问业务 Pod 节点上跑的守护进程（daemonset 外部探测）访问 Pod 属于“平台层运维”常见痛点。 面试视角：它值不值得讲？ 值得，尤其适合这些岗位： Kubernetes 运维 / 平台工程 / 云原生 SRE 网络/安全/可观测性方向 用 Cilium、Calico、Istio 的团队 但要注意一点： 你讲的重点一定要是“如何定位到 Policy denied + identity”，而不是“我改了很多 yaml”。 这题在“深度等级”大概在哪？ 我会给它一个比较客观的分级： 初级：只会说“加个 NetworkPolicy 放行” 中级：知道分层排查（Pod 内 curl、Service、路由） 高级：能用 Cilium/Hubble 看到 Policy denied 并解释 host/remote-node identity 更高级：能进一步讲“为什么 ipBlock 不命中、为什么需要 fromEntities、如何标准化策略/避免误伤” 你这次已经到 高级门槛了。 如果你愿意，我还可以帮你把它再“拔高一档”——补上两句很能镇住面试官的话，比如： “我们在 Cilium 下把 Node->Pod 探测流量单独建了 fromEntities: host/remote-node 的 allowlist，避免跟业务 NP 混在一起。” “排查网络我会先看 datapath drop reason，避免在 overlay、iptables、policy 之间盲猜。” 你想把这题定位成你“最有含金量的一个案例”吗？我可以顺手帮你润色成简历 bullet。
