nvd11的专栏

本文详细介绍了如何为部署在GKE上的Web应用（前端chat-ui和后端chat-api-svc）启用Google账号登录的IAP（Identity-Aware Proxy）保护。主要内容包括：1）架构设计，通过Google负载均衡器拦截请求并强制认证；2）创建OAuth凭证，配置授权重定向URI；3）将凭证存储为Kubernetes Secret；4）为后端API创建专用IAP Service和策略。该方案实现了用户访问前端时自动跳转Google登录，并将认证信息安全传递给后端服务，同时保持内部通信不受影

本文记录了在GKE托管Web服务中排查/chat接口超时问题的完整过程。最初发现长文本生成请求被截断，通过curl确认是HTTP/2 INTERNAL_ERROR。排查发现应用层设置300秒超时无异常，但HTTPRoute超时配置无效，GKE Gateway回退到默认短超时。最终采用GCPBackendPolicy方案，为后端服务设置300秒超时成功解决问题。关键教训包括：验证配置实际生效状态、优先参考云厂商特定文档、善用kubectl诊断工具。此次排查不仅解决了技术问题，更深化了对GKE Gateway工

本文介绍了为域名gateway.jpgcp.cloud和jpgcp.shop启用HTTPS访问的技术方案。采用Google托管证书方案，具有完全免费、自动管理续订、高度可信等优势。实施过程分为两步：首先通过gcloud命令创建全局SSL证书资源；随后修改gateway.yaml配置，使用"TLS终止"模式将加密层前置到网关。这种架构既保障了外部通信安全，又简化了后端应用处理，无需管理证书或处理HTTPS加解密工作。特别说明了"TLS终止"模式的实际含义是将加密终点设在

本文详细介绍了如何利用Vite和Lit构建单页应用(SPA)，并通过Docker和Nginx容器化部署到Google Kubernetes Engine(GKE)。重点解决了在GKE Gateway API下将应用部署到子路径(如/chat/)的核心问题： 使用Vite初始化Lit项目并开发基础页面 通过多阶段Docker构建和Nginx配置实现容器化 提出"双管齐下"解决方案：前端通过Vite配置base路径，后端通过Gateway的URLRewrite过滤器剥离前缀 最终实现请求路径

摘要： 本文介绍如何配置py-api-svc服务在GKE上的日志，确保GCP Cloud Logging正确显示日志级别（如DEBUG、INFO）。默认情况下，GKE将stderr日志标记为ERROR，导致loguru等库的INFO日志被误判。解决方案是使用loguru输出JSON结构化日志到stdout，通过设置serialize=True，使GCP自动解析JSON中的level字段并正确分类日志级别。无需额外代理，仅需调整日志配置即可实现，并通过GCP日志浏览器验证效果。此方法兼顾准确性与简便性。

本文档旨在通过 `py-webhook-svc` 项目的实际案例，详细介绍在 Google Kubernetes Engine (GKE) 上进行部署的两种主要方法：传统的 `kubectl` 部署和现代的 Helm Chart 部署。我们将对比这两种方法的优劣，并深入讲解最终完善的 Helm Chart 配置。

GKE（Google Kubernetes Engine）是 Google Cloud 提供的容器管理服务，它基于 Kubernetes 构建，可以帮助您轻松部署、管理和扩展容器化的应用程序。您可以把它想象成一个强大的“容器编排大师”，让您的应用在云端高效、稳定地运行。GKE 简化了 Kubernetes 的复杂性，让您专注于应用开发，而无需花费大量精力在底层基础设施的管理上。它提供了自动伸缩、自动修复、滚动更新等功能，确保您的应用始终可用并保持最佳性能。

Kubernetes（K8s）的权限认证机制主要涉及认证（Authentication）和授权（Authorization）两个方面：Authentication 包括用户验证与 服务帐号(SA) 认证至于Authorization 授权方面， 就是我们常见的RBAC (Role-based Access Control)如下图， 其实一切对k8s集群的管理操作都是通过api service 去调用nodes 的kubelet 去完成。

刚安装好k8s时我就可以用kubectl 在master server里管理k8s的资源。这时我们是感觉不到 k8s的用户和权限管理存在的， 但是其实用户的配置都在kubeclt 的配置文件中/etc/kubernetes/admin.conf 中我们可以用下命令来查看当前正在用的帐号当我们把这个配置复制到另1台机器上， 那么那台机器也可以用kubernetes-admin 来登陆kubectl。

在之前的文章里已经介绍了 K8S 中两个简单卷类型 hostpath 和 emptydir但是这两种卷都有同1个限制， 就是依赖于 k8s nodes的空间如果某个service pod中需要的volumn 空间很大， 这时我们就需要考虑网络磁盘方案， 其中NAS 类型的Volume 是常用且简单的选择之一。

Kubernetes中的EmptyDir是一种用于容器之间共享临时存储的空目录卷类型。EmptyDir卷在Pod内的容器之间共享，并且在Pod被删除时，其中的数据也会被删除。以下是EmptyDir卷的一些关键特点：临时存储：EmptyDir卷用于临时存储数据。当Pod被删除时，EmptyDir中的数据也会被删除。容器共享：EmptyDir卷可以在同一个Pod中的多个容器之间共享数据。这对于需要在容器之间共享数据的场景非常有用。

官方定义：hostPath 卷能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。虽然这不是大多数 Pod 需要的，但是它为一些应用提供了强大的逃生舱。简单来讲就是让k8s node 的目录or 文件map在你的POD 容器里至于为什么上面提到的逃生舱， 是因为假如你的POD 崩溃了or 被shutdown， 我们仍然可以在node对应的path上找到我们想要的数据(前提是把相应的数据output 到hostpath）但是 官方并不推荐使用hostpath 把数据输出到node上。

在上一篇文章中介绍了springboot 中如何实时读取外部配置文件的内容。

Kubernetes（k8s）中的 Secret 是一种用于存储敏感信息的 Kubernetes 资源对象，如密码、API 密钥、证书等。Secret 被设计为用于安全地存储和管理敏感数据，并且可以通过 Volume 或环境变量的方式将这些数据提供给 Pod 中的容器。简单来讲， K8S 的secret 和 configmap 的作用都是存放configuration 配置数据但是 configmap 不适合存放证书， 密码等敏感数据。

Kubernetes中的ConfigMap 是用于存储非敏感数据的API对象，用于将配置数据与应用程序的镜像分离。ConfigMap可以包含键值对、文件或者环境变量等配置信息，应用程序可以通过挂载ConfigMap来访问其中的数据，从而实现应用配置的动态管理。ConfigMap的使用有助于提高应用程序的可移植性、可伸缩性和可维护性。简单来讲， configmap 是用来存储app的配置或者容器的环境变量的， 避免这些配置hard code 在容器内。

1个ingress controller 可以对应多个ingress 吗？答： 可以的如果1个ingress 的controller 配有多个ingress instance, 里面的配置会冲突吗？如果有相同的path 设置答： 会冲突， 所以要保证多个ingress instance 的配置中 path 互相不重复如果一个 Ingress 控制器对应两个 Ingress 资源，并且这两个 Ingress 的配置中具有相同的路径，那么会发生冲突。

referring:无头服务（Headless Services）有时你并不需要负载均衡，也不需要单独的 Service IP。遇到这种情况，可以通过显式设置 集群 IP（spec.clusterIP）的值为 "None" 来创建无头服务（Headless Service）。你可以使用无头 Service 与其他服务发现机制交互，而不必绑定到 Kubernetes 的实现。

集群内部通信：ClusterIP 为 Service 提供了一个虚拟的内部 IP 地址，用于在 Kubernetes 集群内的其他组件和服务之间进行通信。其他 Pod 可以通过该虚拟 IP 地址和 Service 的端口来访问该 Service。内部负载均衡：ClusterIP 实现了基于轮询算法的负载均衡，它将请求均匀地分发给 Service 关联的后端 Pod。这意味着无论有多少个后端 Pod，它们都可以被平等地访问，从而实现负载均衡和高可用性。

参考理解 什么是 滚动更新，蓝绿部署，灰度发布 以及它们的区别。

滚动更新，蓝绿部署，灰度发布这3种 现代化的 发布模式相信很多人都听过， 但是并不是都能正确理解他们的作用和区别。

有状态服务（Stateful Service）：有状态服务是指在处理请求期间维护和跟踪用户状态或会话信息的服务。这意味着服务在多个请求之间保持状态，并且需要在请求之间共享和使用这些状态信息。通常，有状态服务会将用户数据存储在内存、数据库或其他持久化存储中，并使用该状态来处理后续请求。有状态服务通常需要进行会话管理和状态同步，以确保正确处理和维护用户状态。无状态服务（Stateless Service）：无状态服务是指在处理请求期间不维护任何用户状态或会话信息的服务。

在之前的文章介绍过， 通过任何node 的主机， 用kubectl 管理集群是很简单。

严格来说,Kubernetes中的Service仅仅包括ClusterIP、NodePort和LoadBalancer这三种类型。NodePort类型的Service是Kubernetes中最常见的一种服务类型。让我来详细介绍一下NodePort Service:NodePort Service会在每个NodeNode上随机分配一个端口(默认范围30000-32767),通过这个端口就可以从集群外访问Service。

更新回之前的版本， 与一般的更新不同， 因为之前已经有1个RS 是for image 1.1.2的所以这次k8s 重用了之前的rs而并没有增加1个。只不过1.1.3 版本的RS 有5个当前运行的POD 副本， 而1.1.1 和 1.1.2 的副本数量是0, 符合常规.可以看到回滚的实现就是无非把1.1.2的rs 里的pod副本逐渐增加到5, 而1.1.3 rs的pod副本从5 减少到0。有5个pod 正在运行， 关键pod 名字是包含了 rs 的对象名字的。回滚1个service 的版本有多种方法。

结果是 deployment 和 rs 的属性都更新了， 而且pod 也增加了两个， 但是实际上rs 的hash 没变， 还是那个RS, 而且pod 的版本仍然是1.1.1 并没有触发滚动更新。至于ReplicaSet 则是直接多了1个， 足以看出k8s 是新建1个 RS 作为临时的POD 容器进行滚动更新， 当新的RS 完成所有pod 更新时， 旧的RS 就被丢弃放在一边了。结果， 单纯地添加了1个label在deployment 对象， rs 和 pod 都没有触发更新。结果， 触发了滚动更新。

当谈到 Kubernetes 集群中的应用程序部署和管理时，Deployment、ReplicaSet 和 Pod 是三个重要的概念。它们之间存在一定的关系和层次结构。下面是对 Deployment、ReplicaSet 和 Pod 的详细解释以及它们之间的关系。

本文会介绍 1个 POD 从启动到被关闭删除， 有什么事情发生， 和有什么组件被参与进来。

当我们启动一个POD 时， 当k8s detect 里面的容器启动成功时， 就会认为这个POD 启动完成了， 通常就会在状态里表示 ready 1/1 …例如至于K8S 是怎么判断pod 是否启动完成的：对于容器内没有设置探测规则的情况，默认的探测规则如下：启动完成检测：Kubernetes将监视容器的启动状态。如果容器的进程启动并且不处于终止状态（例如，未崩溃），Kubernetes将认为该容器已启动完成。

当我们初步安装玩k8s （master 带 2 nodes） 时正常来讲kubectl 只能在master node 里运行当我们尝试在某个 node 节点来执行时， 通常会遇到下面错误看起来像是访问某个服务器的8080 端口失败了。

我刚安装完k8s, 1个master 两个node然后用下面两句命令安装了1个nginxnginx 这个pod 安装在了k8s-node1 中但是我只能在k8s 上用k8s-node1 来访问这个nginx 服务， 例如但是用k8s-master 和 k8s-node0的ip都是不能访问的。

看1个例子：我们用下面命令去创建1个pod2， 里面运行的是1个nginx当这个POD被创建后， 其实并不能被外部访问， 因为端口映射并没有完成.我们用下面这个命令去创建1个svc ， 暴露端口生成了1个service， service name is pod2-service， nodePort是31382 （这里是随机生成）这时pod2的nginx就可以被外部的机器访问了我的k8s 集群中有5个node， 而上面创建的pod2 只部署在了其中1个node k8snode0 上。

如果我们直接使用kubectl delete pod命令去简单删除1个pod是没用的因为在deployment的replicas 中已经指定了这个pod的副本数量可以见到， 我上面即使删除了nginx-6799fc88d8-xwbnh 这个pod， 但是1个新的pod nginx-6799fc88d8-h6tkj会被重新创建所以我们必须从deployment 下手用下面命令去获得k8s的deployments list### 方法1： 修改replicas 的数量为0。

当我修改某个node的hostname后， k8s就显示这个node状态时not ready了这时只能删除和重新加入这个node(新的node 里面并没有部署任何pod）

Pod 是K8s 系统中可以创建（部署）和管理的最小单元。Pod 里面可以包含多个容器(多实例），是一组容器的集合。也就是讲K8S 不会直接管理容器1个POD中的容器共享网络命名空间（共享ip）POD 是短暂的（可以被创建 迁移）来自google的解析， POD的存在是为了覆盖container的细节上图的Pause 表示POD里面必须存在的根容器通常POD的实现基于两种机制分别是我们知道， 在docker中各个容器之间是相互隔离的。在K8S 中， 容器也可以用namespace 和 group进行隔离

k8s安装完后， kubectl这个工具可以很方便地让我们操作k8s。。但其实一旦用于大规模部署， kubectl 就不那么方便了. 这时我们需要用资源编排文件（Resource Orchestration）来实现组合和批量操作。在k8s 中， 一般使用yaml格式的资源编排文件来创建我们预期期望的pod。

由于这个世界越来越卷，作为一个大龄程序员， 学习K8S 很有必要。

2014年， 伟大的google公司开源了Kubernates 产品， 因为这个单词K与S之间有8个字母， 所以简写就是K8S.简单来讲。