k8s

概述Deployment 是 Kubernetes 中最常用的工作负载资源，用于声明式地管理 Pod 和 ReplicaSet，提供滚动更新、回滚、扩缩容等功能。 核心功能： 🔄 声明式更新和回滚 📊 副本数量管理 🚀 滚动更新策略 💚 健康检查和自愈 🎯 资源配额管理 适用场景： 无状态应用部署 微服务容器化 应用版本管理 高可用服务 Deployment 完整配置基本结构12345678910111213141516171819202122apiVersion: apps/v1 # API 版本kind: Deployment # 资源类型metadata: # Deployment 自身的元数据 name: my-app # Deployment 名称 namespace: default # 命名空间 labels: # Deplo...

Kubernetes 自己提供了 secret 这种方式，但其是一种编码方式，而非加密方式，如果需要用版本控制系统（比如 git）来对所有的文件、内容等进行版本控制时，这种用编码来处理敏感信息的方式就显得很不安全了（即使是采用私有库），这一点在实现 GitOps 时，是一个痛点。 Sealed Secrets Sealed Secrets 充分利用 kuberntes 的高扩展性，通过 CRD 来创建一个 SealedSecret 对象，通过将加密的内容存储在扩展 SealedSecret 对象中，而 SealedSecret 只能够被运行于目标集群上的 controller 解密，其他人员和方式都无法正确解密原始数据。SealedSecret 对象同时又会生成与其名称相同的 secret 对象，随后就可以按照常规方式使用 secret 对象了。最后将加密后的文件直接推送至版本控制系统即可，而不用担心敏感信息被泄漏. 简单来说就是, 我们需要用 YAML 的形式生成一个 Secret，但是我们希望 YAML 自身的内容是加密的，以保证传输过程中，Secret 自身的内容不...

PersistentVolume（PV）和PersistentVolumeClaim（PVC）这两个概念用于pod和volume之间解耦。Pod根据自己的需要提出数据卷的申请，k8s系统将符合条件的数据卷返回给pod。这样一来pod就无需直接和数据卷本身强绑定了。Pod无需知道数据卷的细节信息，比如具体用的是什么存储。 Pod中对数据卷的申请为PVC，用来和PVC绑定的数据卷称为PV。 PV可以有多种存储方式，比如NFS，iSCSI等。 PVC是使用PV资源的声明。 PVC和PV的关系是一对一的, 不能将多个PVC绑定到同一个PV上.PV和PVC的生命周期 供应阶段PV有两种供应方式 static 静态方式由系统管理员创建PV dynamic 如果没有静态的PV。系统会动态创建出PV来满足PVC。PV的提供者为StorageClass。要使用动态供应，PVC必须要指定一个StorageClass。如果StorageClass设置为空，那么针对这个PVC的动态供应特性会被禁用。 绑定阶段这个阶段指的是PV和PVC绑定的过程。系统有一个机制，循环检查新创建的PVC，然后找到一个符...

StatefulSet和Deployment控制器的区别 statefulSet下的Pod有DNS地址,通过解析Pod的DNS可以返回Pod的IP deployment下的Pod没有DNS 通过StatefulSet和headless service部署的服务效果 为什么要用headless service+statefulSet部署有状态应用?使用headless service+statefulSet可以实现 StatefulSet会为关联的Pod保持一个不变的Pod Name，其hostname格式为$(StatefulSet name)-$(序号【从0开始】) StatefulSet关联到的每一个Pod分配一个dnsName$<Pod Name>.$<service name>.$<namespace name>.svc.cluster.local headless service会为关联的statefulSet分配一个域，通过dns解析该域能获取到每个pod的ip+port<service name>.$<na...

在 Pod 中共享卷以供多方使用是很有用的。VolumeMounts.subPath 属性可用于指定所引用的卷内的子路径，而不是其根路径。 subPath 的两种使用场景： 一个 Pod 中有多个容器时，将不同容器的路径挂载到存储卷的子路径，需要使用 subPath。 Volume 支持将 ConfigMap/Secret 挂载到容器路径，但会覆盖原有文件。使用 subPath 可以只挂载指定的 key，且不覆盖原目录下的其他文件。 一个 Pod 多组容器的情况12345678910111213141516171819202122apiVersion: v1kind: Podmetadata: name: pod-subpath-yuhaohaospec: containers: - name: redis-container image: redis volumeMounts: - mountPath: /var/lib # 容器1的挂载目录 name: subpath-volume ...

NFSNFS 是 Network File System 的缩写，即网络文件系统。功能是让客户端通过网络访问不同主机上磁盘里的数据，主要用在类Unix系统上实现文件共享的一种方法。 本例演示 CentOS 7 下安装和配置 NFS 的基本步骤。 记得保证所有pod可部署机器都要安装NFS服务端或者NFS客户端，否则出现类似错误：wrong fs type, bad option, bad superblock on 192.168.1.5:/home/shared, missing codepage or helper program, or other error NFS服务的优缺点优点 节省本地存储空间将常用的数据存放在一台服务器可以通过网络访问 简单容易上手 方便部署非常快速，维护十分简单 缺点 局限性容易发生单点故障，及server机宕机了所有客户端都不能访问 在高并发下NFS效率/性能有限 客户端没用用户认证机制，且数据是通过明文传送，安全性一般（一般建议在局域网内使用） NFS的数据是明文的，对数据完整性不做验证 多台机器挂载NFS服务...

参考：https://jimmysong.io/kubernetes-handbook/guide/auth-with-kubeconfig-or-token.html 在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式，在 dashboard 的登录功能就可以使用这两种登录功能。 下文分两块以示例的方式来讲解两种登陆认证方式： 为 brand 命名空间下的 brand 用户创建 kubeconfig 文件 为集群的管理员（拥有所有命名空间的 admin 权限）创建 token 使用 kubeconfig 方式如何生成kubeconfig文件请参考创建用户认证授权的kubeconfig文件。 注意我们生成的 kubeconfig 文件中没有 token 字段，需要手动添加该字段。 比如我们为 brand namespace 下的 brand 用户生成了名为 brand.kubeconfig 的 kubeconfig 文件，还要再该文件中追加一行 token 的...

简介 Metricbeat 是服务器上的轻量级收集器，用于定期收集主机和服务的监控指标【包括events】。 Metricbeat 默认收集系统指标，但也包含大量其他模块，用于收集 Nginx、Kafka、MySQL、Redis 等服务的指标。支持的模块的完整列表可以在 Elastic 官网查看：https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-modules.html。 kube-state-metrics官方地址：https://github.com/kubernetes/kube-state-metrics 注：对于使用 prometheus-operator/kube-prometheus 的用户， kube-prometheus 将 kube-state-metrics 作为其组件之一。 如果已经安装了 kube-prometheus，则无需安装 kube-state-metrics。 首先，我们需要安装 kube-state-metrics，这是一个组件，它是一个侦听 Kube...

在 Kubernetes 中，有时候删除资源对象（如 Namespace）时会卡住无法删除完成，这通常是因为存在 finalizers。以下是几种强制删除资源对象的方式。 1. 仅删除1kubectl delete namespace <ns> 2. 强制删除12# --grace-period=0: 设置优雅删除时间为 0kubectl delete namespace <ns> --force --grace-period=0 3. 修改 finalizers 字段12kubectl edit namespace <ns># 查找 finalizers，将后面的值置为 [] 4. 通过 API 接口修改 finalizers通过 Kubernetes 提供的 API 接口，修改 .spec.finalizers 和 metadata.finalizers 字段，将值置为 []，从而让 Kubernetes 直接删除该资源。 1234567891011# 1. 导出 namespace JSONkubectl get namespace...

资源分配不均匀问题简述 资源相关的打分算法 LeastRequestedPriority 和 MostRequestedPriority 都是基于 request 来进行评分，而不是按 Node 当前资源水位进行调度（在没有安装 Prometheus/Metrics 等资源监控相关组件之前，kube-scheduler 也无法实时统计 Node 当前的资源情况）。 简单来说，k8s在进行调度时，计算的就是requests的值，不管你limits设置多少，k8s都不关心。所以当这个值没有达到资源瓶颈时，理论上，该节点就会一直有pod调度上去。 综上所述，在实际场景就可能会遇到以下几种情况 经常在 K8s 集群种部署负载的时候不设置 CPU requests （这样“看上去”就可以在每个节点上容纳更多 Pod ）。在业务比较繁忙的时候，节点的 CPU 全负荷运行。业务延迟明显增加，有时甚至机器会莫名其妙地进入 CPU 软死锁等“假死”状态。 在 K8s 集群中，集群负载并不是完全均匀地在节点间分配的，通常内存不均匀分配的情况较为突出，集群中某些节点的内存使用率明显高于其...