nvd11的专栏

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.简单来讲。