容器化

仅删除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 ...

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 分为几种类型，分别为：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 # ...

官方文档 记录下longhorn的使用 - rancherlab提供的开源分布式块存储方案 Longhorn 支持以下架构： AMD64 ARM64（实验性） longhotn需要open-iscsi,curl,findmnt,grep,awk,blkid,lsblk的依赖(是否需要单独安装可以使用这个脚本进行验证,centos7有可能需要单独安装下jq和open-iscsi) 利用rancher安装: 在rancher ui上选择自己的集群,然后找到对应app安装即可,v2.6.3测试没问题(尝试用kubectl安装的时候告诉我缺少NODE_NAME ENV,但是rancher就正常): https://longhorn.io/docs/1.2.3/deploy/install/install-with-rancher/查看对应几个node是否正常创建longhorn(默认数据路径)ls /var/lib/longhorn界面 创建应用进行测试应用 yaml 创建 PVC 和 pod pvc.yaml1234567891011apiVersion: v1kind: Pers ...

K3s私有镜像仓库配置 Containerd配置镜像仓库 参考 Kubernetes 在 Changelog 中宣布自 Kubernetes 1.20 之后将弃用 Docker 作为容器运行时之后，containerd成为下一个容器运行时的热门选项。虽然 containerd 很早就已经是 Docker 的一部分，但是纯粹使用 containerd 还是给大家带来了诸多困扰，本文将介绍如何使用 containerd 配置镜像仓库和加速器。 本文将以K3s为例对containerd进行配置，如果您的环境未使用 K3s 而是使用的 Kubernetes，你也可以参考本文来配置 containerd 的镜像仓库，因为 containerd 的配置是通用的。 关于 K3s 和 containerd K3s 是一个轻量级 Kubernetes 发行版，二进制大小小于100MB，所需内存不到Kubernetes的一半。K3s 为了降低资源消耗，将默认的 runtime 修改为 containerd，同时也内置了 Kubernetes CLI 工具 crictl和ctr。 K3s 默认的 con ...

前言Ingress Service可能会有很多，如果每个资源都绑定一个 node port的话，主机则需要开放外围的端口进行服务调用，管理上会比较混乱。 比较优雅的方式是通过一个外部的负载均衡器，比如 nginx ，绑定固定的端口比如80，然后根据域名/服务名向后面的Service Ip转发，但是这里对问题在于：当有新服务加入的时候如何修改 Nginx 配置？ 手动改或者 Rolling Update Nginx Pod 都是不现实的。 对于这个问题， k8s 给出的七层解决方案是：Ingress Traefik Træfik 是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。Traefix是k3s里面的Ingress Controller。支持负载均衡和反向代理，类似于ngnix。 Traefik 的仪表板 ...

每次创建了新的namespace下都会生成一个默认的token，名为default-token-xxxx。default就相当于该namespace下的一个用户。也可以考虑新建service count来获取token 查看token secret 123[root@k3s-release-server1 ~]# kubectl get secretsNAME TYPE DATA AGEdefault-token-6f7xb kubernetes.io/service-account-token 3 16m 使用脚本方式访问api 12345678#!/usr/bin/env bashurl=$1token=`kubectl get secrets|awk 'NR>1'|awk '{print $1}'|xargs -i kubectl describe secret {
...