DNS最佳实践及问题排查
转自: https://help.aliyun.com/document_detail/172339.html#11 DNS最佳实践优化域名解析请求DNS域名解析请求是Kubernetes最高频的网络行为之一,其中很多请求是可以优化和避免的。您可以通过以下方式优化域名解析请求: (推荐)使用连接池:当一个容器应用需要频繁请求另一服务时,推荐使用连接池。连接池可以将请求上游服务的链接缓存在内存中,避免每次访问时域名解析和TCP建连的开销。 使用DNS缓存: (推荐)当您的应用无法改造成通过连接池连接另一服务时,可以考虑在应用侧缓存DNS解析结果,具体操作,请参见使用节点DNS缓存NodeLocal DNSCache。 如果NodeLocal DNSCache无法适用的,可以在容器内置NSCD(Name Service Cache Daemon)缓存。关于如何使用NSCD缓存,请参见在Kubernetes集群中使用NSCD。 优化resolv.conf文件:由于resolv.conf文件中ndots和search两个参数的机制作用,容器内配置域名的不同写法决定了域名解析的效...
Endpoints
k8s集群中创建一个名为hello的service,就会生成一个同名的endpoint对象,ENDPOINTS就是service关联的pod的ip地址和端口, 即动态存储pod ip地址和端口对应关系的list,Kubernetes在创建Service时,根据Service的标签选择器(Label Selector)来查找Pod,据此创建与Service同名的EndPoints对象。当Pod的地址发生变化时,EndPoints也随之变化。Service接收到请求时,就能通过EndPoints找到请求转发的目标地址endpoint不可以用来固定podip,endpoint是随着pod的改变而改变,而非pod随着endpoint的改变而改变 手动创建 Endpoint 创建service: 略 创建一个 endpoint.yaml 文件,内容如下(注意替换ip为你容器访问ip(pod ip)): 12345678910apiVersion: v1kind: Endpointsmetadata: name: nginxsubsets: - addresses: - i...
HPA(水平伸缩)和 PodDisruptionBudget(干扰预算)
HPA我们可以实现通过手工执行kubectl scale命令实现Pod扩容或缩容,但是这显然不符合Kubernetes的定位目标–自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况,实现pod数量的自动调整,于是就产生了Horizontal Pod Autoscaler(HPA)这种控制器。 HPA可以获取每个Pod利用率,然后和HPA中定义的指标进行对比,同时计算出需要伸缩的具体值,最后实现Pod的数量的调整。其实HPA与之前的Deployment一样,也属于一种Kubernetes资源对象,它通过追踪分析RC控制的所有目标Pod的负载变化情况,来确定是否需要针对性地调整目标Pod的副本数,这是HPA的实现原理 注: 在 K8S 1.18之前,HPA 扩容是无法调整灵敏度的 对于缩容,由 kube-controller-manager 的 --horizontal-pod-autoscaler-downscale-stabilization-window 参数控制缩容时间窗口,默认 5 分钟,即负载减小后至少需要等 5 分钟才会缩容。 对于扩容,由 ...
在 K8s 中如何使用存储卷的详细介绍
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 的使用
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...
几种强制删除资源对象的方式
在 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 集群中,集群负载并不是完全均匀地在节点间分配的,通常内存不均匀分配的情况较为突出,集群中某些节点的内存使用率明显高于其...
解决镜像下载失败的几种方法
前言在学习、研究 Kubernetes 的过程中,经常遇到镜像拉取不了的网络问题,这并不是镜像本身的问题,而是国内的"国情"导致无法正常访问墙外资源。 这些镜像有的是 Kubernetes 团队自研的插件,也有一些是爱好者开发的第三方组件,正常来说,它们会存放于 gcr.io 或者 quay.io 中。 gcr.io 是谷歌的镜像仓库,在国内是禁止访问的 quay.io 是 Red Hat 的镜像仓库,可以访问,但速度较慢 那如何应对这种网络问题呢? 现成的镜像代理仓库k8s.gcr.io 源代理仓库这是 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:v2.3.0 也可以使用 lank8s.cn,它们的对应关系:k8s.gcr.io → lank8s.cn,gcr.io →...
记录 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...
