subPath的使用场景及方法
在Pod中共享卷以供多方使用是很有用的。VolumeMounts.subPath属性可用于指定所引用的卷内的子路径，而不是其根路径。 subpath的两种使用场景 1个Pod中可以有多个容器，将不同容器的路径挂载在存储卷volume的子路径，这种场景需要使用到subpath。 volume支持将configMap/secret挂载到容器的路径，但是会覆盖容器路径下原有的文件。如何支持选定configmap/secret的key-value挂载到容器中，且不会覆盖掉原目录下的文件，这个时候可以用subpath。 一个pod多组容器的情况12345678910111213141516171819202122apiVersion: v1kind: Podmetadata: name: pod-subpath-yuhaohaospec: containers: - name: redis-container image: redis volumeMounts: - mountPath: /var/lib # 容器1的挂 ...
使用NFS作为PV的绑定存储卷
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服务器时， ...
使用kubeconfig或token进行用户身份认证
参考：https://jimmysong.io/kubernetes-handbook/guide/auth-with-kubeconfig-or-token.html 在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式，在 dashboard 的登录功能就可以使用这两种登录功能。 下文分两块以示例的方式来讲解两种登陆认证方式： 为 brand 命名空间下的 brand 用户创建 kubeconfig 文件 为集群的管理员（拥有所有命名空间的 amdin 权限）创建 token 使用 kubeconfig 方式如何生成kubeconfig文件请参考创建用户认证授权的kubeconfig文件。 注意我们生成的 kubeconfig 文件中没有 token 字段，需要手动添加该字段。 比如我们为 brand namespace 下的 brand 用户生成了名为 brand.kubeconfig 的 kubeconfig 文件，还要再该文件中追加一行 token 的配置（ ...
使用metricbeats监控k8s
简介 Metricbeat 是服务器上的轻量级收集器，用于定期收集主机和服务的监控指标【包括events】。 Metribeat 默认收集系统指标，但也包含大量其他模块，用于收集 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，这是一个组件，它是一个侦听 Kubernet ...
几种强制删除资源对象的方式
仅删除1kubectl delete namespace <ns> 强制删除12# grace-period=0: 设置优雅删除时间为0kubectl delete namespace <ns> --force --grace-period=0 修改.spec.finalizer和metadata.finalizer字段12kubectl edit namespace cattle-system查找finalizers,将后面的值置为[] 通过k8s提供的api接口，修改.spec.finalizers和metadata.finalizer字段,将后面的值置为[]，从而k8s会直接将该ns删除1234561. kubectl get namespace <ns> -o json > xx.json2. 编辑该xx.json文件，修改.spec.finalizers字段,将后面的值置为[]3. 另开一个终端，开启k8s apiserver的一个http代理，以免必须带上证书才能访问: kubectl proxy --port=80814. 另开一 ...
如何合理的解决资源分配问题
资源分配不均匀问题简述 资源相关的打分算法 LeastRequestedPriority 和 MostRequestedPriority 都是基于 request 来进行评分，而不是按 Node 当前资源水位进行调度（在没有安装 Prometheus/Metrics 等资源监控相关组件之前，kube-scheduler 也无法实时统计 Node 当前的资源情况）。 简单来说，k8s在进行调度时，计算的就是requests的值，不管你limits设置多少，k8s都不关心。所以当这个值没有达到资源瓶颈时，理论上，该节点就会一直有pod调度上去。 综上所述，在实际场景就可能会遇到以下几种情况 经常在 K8s 集群种部署负载的时候不设置 CPU requests （这样“看上去”就可以在每个节点上容纳更多 Pod ）。在业务比较繁忙的时候，节点的 CPU 全负荷运行。业务延迟明显增加，有时甚至机器会莫名其妙地进入 CPU 软死锁等“假死”状态。 在 K8s 集群中，集群负载并不是完全均匀地在节点间分配的，通常内存不均匀分配的情况较为突出，集群中某些节点的内存使用率明显高于其他节点 ...
记一次接口慢调用问题排查
现象 系统的商户端出现响应慢，加载慢的问题 关于慢调用问题 可能带来的危害包括： 前端业务维度：首先慢调用可能会引起前端加载慢的问题，前端加载慢可能会进一步导致应用卸载率高，进而影响品牌的口碑。 项目交付的维度：由于接口慢导致达不到 服务质量目标，进而导致项目延期。 业务架构稳定性：当接口调用慢时，非常容易引起超时，当其他业务服务都依赖这个接口，那么就会引发大量重试，进而导致资源耗尽，最终导致部分服务或者整个服务不可用的雪崩的现象。 问题排查 先排查下其他端是否也存在慢响应等问题，发现加载正常 检查网关日志(orange)，发现有大量status：499。 关于status code 499, client has closed connection 代表客户端主动断开了连接，一般是服务端处理时间太长了，客户端等不了就断开了还有一种情况就是有人攻击，故意消耗服务端资源。 说明网关下游服务响应时间过长，网关路由到app_tenant服务 此时怀疑是不是因为app_tenant服务占用cpu过多，导致将节点cpu打满（目前app_tenant服务并没有限制c ...
获取客户端IP之externalTrafficPolicy
externaltrafficpolicy作用阐述把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持【当我们的集群服务需要访问k8s之外的集群时，可以选择这种类型，然后把外部服务的IP及端口写入到k8s服务中来，k8s的代理将会帮助我们访问到外部的集群服务】 什么是external-traffic-policy在k8s的Service对象（申明一条访问通道）中，有一个“externalTrafficPolicy”字段可以设置。有2个值可以设置：Cluster或者Local。 1）Cluster表示：流量可以转发到其他节点上的Pod。 2）Local表示：流量只发给本机的Pod。 这2种模式有什么区别存在这2种模式的原因就是，当前节点的Kube-proxy在转发报文的时候，会不会保留原始访问者的IP。 选择（1）Cluster注：这个是默认模式，Kube-proxy不管容器实例在哪，公平转发。 Kube-proxy转发时会替换掉报文的源IP。即：容器收的报文，源IP地址，已经被替换 ...
解决镜像下载失败的几种方法
前言 在学习、研究 K8S 的过程中，经常遇到镜像拉取不了的网络问题，这并不是镜像本身的问题，而是国内的“国情”导致无法正常访问墙外资源。 这些镜像有的是 K8S 团队自研的插件，也有一些是爱好者开发的第三方组件，正常来说，他们会存放于 gcr.io 或者 quay.io 中。 gcr.io 是 谷歌的镜像仓库，是禁止访问的，而 quay.io 是 RedHat 的镜像仓库，可以访问，但速度较慢。 那如何应对这种网络问题呢？ 现成的镜像代理仓库k8s.gcr.io 源代理仓库ctr images tag k8s.m.daocloud.io/scheduler-plugins/kube-scheduler:v0.24.9 这是 gcr.io/google-containers 的仓库，使用阿里云镜像 123k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.3.0# 换成registry.aliyuncs.com/google_containers/csi-node-driver-registrar:v ...
记录k8s-service中的几种类型以及port区别
官方介绍k8s service 分为几种类型，分别为：ClusterIp （默认类型，每个Node分配一个集群内部的Ip，内部可以互相访问，外部无法访问集群内部） NodePort （基于ClusterIp，另外在每个Node上开放一个端口，可以从所有的位置访问这个地址） LoadBalance （基于NodePort，并且有云服务商在外部创建了一个负载均衡层，将流量导入到对应Port。要收费的，一般由云服务商提供，比如阿里云、AWS等均提供这种服务, k3s也默认提供了一个lbs - klipper-lb, 本地集群可以使用metallb, metallb解释文档） ExternalName （将外部地址经过集群内部的再一次封装，实际上就是集群DNS服务器将CNAME解析到了外部地址上，实现了集群内部访问） 例如，以下 Service 定义将 prod 名称空间中的 my-service 服务映射到 my.database.example.com： 12345678apiVersion: v1kind: Servicemetadata:name: my-service # ...
公告