1 Service详解1.1Service介绍在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时
文章目录k8s日志收集方案1、elasticsearch安装配置1.1es安装1.2es配置1.3启动es2、kibana安装配置2.1kibana安装2.2kibana配置2.3启动kibana3、zookeeper安装配置3.1zookeeper安装3.2启动zookeeper3.3检查zookeeper状态4、kafka安装配置4.1kafka安装4.2配置kafka4.3启动kafka5、安装配置logstash5.1安装logstash5.2启动logstash6、配置日志收集6.1基于daemonset的日志收集6.2构建logstash镜像6.3部署logstashdaemons
原理内存优化是一个经典问题，在看具体 K8S 做了哪些工作之前，可以先抽象一些这个过程，思考一下如果是我们的话，会如何来优化。这个过程可以简单抽象为外部并发请求从服务端获取数据，如何在不影响吞吐的前提下降低服务端内存消耗？一般有几种方式：缓存序列化的结果优化序列化过程内存分配数据压缩在这个场景可能不适用，压缩确实可以降低网络传输带宽，从而提升请求响应速度，但对服务端内存的优化没有太大的作用。kube-apiserver已经支持基于gzip的数据压缩，只需要设置 Accept-Encoding 为gzip即可，详情可以参考官网[1]介绍。当然缓存序列化的结果适用于客户端请求较多的场景，尤其是服务
k8s强制删除pod、svc、namespace（Terminating）一：强制删除pod1、命令加参方法：二：强制删除pv、pvc三、强制删除ns,以namespace：kubesphere-system为例1、以下强制删除也不好使：2、最终解决方法：1）查看处于“Terminating”状态的namespace：2、查看Terminatingnamespace中的finalizer。3、导出json格式到文件4、编辑tmp.josn，删除finalizers字段的值5、开启proxy：8001端口5注：(按顺序无需注意这一步)6、新开窗口、调用8001--api7、确认namespace
每当删除namespace或pod等一些Kubernetes资源时，有时资源状态会卡在Terminating，很长时间无法删除，甚至有时增加--forcegrace-period=0之后还是无法正常删除。这时就需要edit该资源，或者将该资源导出为json（通过调用原生接口进行删除）,将finalizers字段设置为[]，之后Kubernetes资源就正常删除了。root@1nd1009:~/kubesphere#kubectgetnamespaceNAMESTATUSAGEkubesphere-controls-systemActive5m43skubesphere-logging-sys
文章目录一、前言二、APIServer概要三、APIServer中的接口3.1kubectl与APIServer之间是REST调用3.2查看yaml文件中的apiVersion3.3APIServer中的Restful风格接口3.4APIServer中的API路径3.5kube-apiserver的insecure-port端口3.6操作k8s的开源工具3.7APIServer资源查看四、APIServer中的接口属性4.1APIServer中的API版本(Alpha/Beta/GA)4.2APIServer请求格式(JSON编码/YAML编码/协议缓冲区编码)4.3APIServer常见响应
1.准备工作（所有节点执行）1.1.准备虚拟机本地部署，仅供参考。三个节点：名字为k8s-node1、k8s-node2、k8s-master设置系统主机名及Host文件sudocatEOF>>/etc/hosts192.168.255.141k8s-node1192.168.255.142k8s-node2192.168.255.140k8s-masterEOF#对应的节点执行sudohostnamectlset-hostnamek8s-node1sudohostnamectlset-hostnamek8s-node2sudohostnamectlset-hostnamek8s-master
1、问题一使用搭建好了K8S集群，先是node节点加入k8s集群时，用的内网IP，导致master节点无法操作node节点中的pod（这里的不能操作，指定是无法查看node节点中pod的日志、启动描述、无法进入pod内部，即kubectllogs、kubectl describe、kubectlexec-it等等的命令都不能）解决办法：解决公网下，k8scalicomaster节点无法访问node节点创建的pod-CSDN博客2、问题二master节点能正常访问node节点创建的pod，即问题一所产生的问题但是master节点无法ping通node节点创建pod所属的Service的IP注意：
k8s部署prometheus版本说明：k8s：1.24.4prometheus：release-0.12（https://github.com/prometheus-operator/kube-prometheus.git）本次部署采用operator的方式将prometheus部署到k8s中，需对k8s和prometheus有一定的了解一、下载对应版本代码到服务器gitclone-brelease-0.12https://github.com/prometheus-operator/kube-prometheus.git二、修改几个配置的镜像（国内无法访问registry.k8s.io）v
上篇文章详细介绍了弹性云混部的落地历程，弹性云是滴滴内部提供给网约车等核心服务的容器平台，其基于k8s实现了对海量node的管理和pod的调度。本文重点介绍弹性云的调度能力，分为以下部分：调度链路图：介绍当前弹性云调度体系链路，对架构体系有一个初步的认知k8s调度能力的运用：整体介绍弹性云现在用到的k8s调度能力和对其的增强k8s版本的升级：介绍到从k8s1.12到1.20跨版本升级的方案服务画像/真实使用率调度：原生的request调度存在着和真实使用率之间的gap等缺陷，尝试通过对node上业务做数据画像来让调度做出更符合真实情况的调度重调度：由于调度只能依据当前数据，随着业务的增长、集群
