K8s-存储系统
K8s-存储系统Config Map1234567891011121314151617181920212223242526272829303132333435363738394041424344454647apiVersion: v1kind: ConfigMapmetadata: name: game-demodata: # 类属性键;每一个键都映射到一个简单的值 player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # 类文件键 game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true---apiVersion: v1kind: Podmetad...
K8s-DNS-CoreDNS
K8s-DNS-CoreDNS修改Node上的kubelet的DNS启动参数 –cluster-dns=169.169.10.10:DNS的CLusterIP地址 –cluster-domain=cluster.local:为DNS服务中设置的域名 CoreDNS的配置说明CoreDNS的主要功能是通过插件系统实现的。CoreDNS实现了一种 链式插件结构,将DNS的逻辑抽象成了一个个插件,能够灵活组合使 用。 常用的插件如下。 loadbalance:提供基于DNS的负载均衡功能。 loop:检测在DNS解析过程中出现的简单循环问题。 cache:提供前端缓存功能。 health:对Endpoint进行健康检查。 kubernetes:从Kubernetes中读取zone数据。 etcd:从etcd中读取zone数据,可用于自定义域名记录。 file:从RFC1035格式文件中读取zone数据。 hosts:使用/etc/hosts文件或者其他文件读取zone数据,可用于 自定义域名记录。 auto:从磁盘中自动加载区域...
K8s-CNI网络模型
K8s-CNI网络模型背景跨主机容器间的网络互通已经成为基本要求,更 高的要求包括容器固定IP地址、一个容器多个IP地址、多个子网隔离、 ACL控制策略、与SDN集成等。所以提出了Container Network Interface(CNI) CNM网络模型 主要组件功能: Network Sandbox:容器内的网络栈,包括网络接口、路由表、DNS等配置 Endpoint:用于容器内的Sandbox与外部的网络相连。一个Endpoint只能加入一个Network Network:可以直接互连的Endpoint的集合。可以通过Linux网 桥、VLAN等技术进行实现。一个Network包含多个Endpoint CNI网络模型 在CNI模型中,只有俩个概念:容器和网络。 容器:拥有独立Linux网络命名空间的环境 网络:一组可以互连的一组实体,这些实体拥有各自独立、唯 一的IP地址,可以是容器、物理机或者其他网络设备(比如路由器) 等。可以将容器添加到一个或多个网络中,也可以从一个或多个网络中 删除。 对容器网络的设置和操作都通过插件(Plugin)进行具体实现, CNI...
K8s-集群安装认证
K8s-集群安装认证API Server认证三大K8s API访问模式: 以Service Account方式访问K8s的内部服务进程 以匿名方式访问的进程 以证书方式访问的普通用户或进程,包括运维人员及kubectl、 kubelets等进程 K8s的用户认证方式: HTTPS证书认证:基于CA根证书前面的双向数字证书认证方式 HTTP Bearer Token认证:通过一个Bearer Token识别合法用户 OpenID Connect Token第三方认证:通过第三方OIDC协议进行认证 Webhook Token认证:通过外部Webhook服务进行认证 Authenticating Proxy认证:通过认证代理程序进行认证 HTTPS证书认证这里需要有一个CA证书,CA是PKI系统中通信双方都信任的实 体,被称为可信第三方(Trusted Third Party,TTP)。CA作为可信第三 方的重要条件之一,就是其行为具有非否认性。作为第三方而不是简单 的上级,就必须让信任者有追究自己责任的能力。CA通过证书证实他 人的公钥信息,在证书上有CA的签名。如果用户因...
K8s-使用swagger-ui可视化K8s API文档
使用swagger-ui可视化K8s API文档背景需要进行K8s API开发的时候,不方便查看 具体实现1234567891011121314151617# 启动代理kubectl proxy --port=8080# 获取到swagger.jsoncurl localhost:8080/openapi/v2 > k8s-swagger.json# docker启动swaggerdocker run \ --rm \ -d \ -p 8087:8080 \ -e SWAGGER_JSON=/k8s-swagger.json \ -v $(pwd)/k8s-swagger.json:/k8s-swagger.json \ swaggerapi/swagger-ui # 通过http://ip:8087
K8s-三大核心数据结构
K8s-三大核心数据结构构成 Group:资源组,在K8s API Server称之为APIGroup Version:资源版本,在K8s API Server称为APIVersion Resource:资源,在K8s API Server称为APIResource Kind:资源种类,描述K8s种类,与Resource统一级别 K8s支持多Group,每个Group支持多Version,每个Version支持多Resource,部分资源还有自己的子资源(Sub Resource),比如Deployment的status 一般的,具体表示///,比如Deployment就是apps/v1/deploymets/status 不常见的deletecollection资源在支持delete的情况下,如果支持删除多个字眼,比如删除命名空间所有的Pod,那就算啥给予deletecollection 12# 查看所有kubectl api -resources --sort-by name -o wide 资源组Group资...
K8s-Service的服务发现机制
K8s-Service的服务发现机制服务发现机制主要是K8s集群如何获取后端服务的访问地址。 K8s主要提供了俩种模式,环境变量方式和DNS方式 环境变量1234567891011apiVersion: v1kind: Servicemetadata: name: kubiaspec: selector: app: kubia-service ports: - protocol: TCP port: 8080 targetPort: 8080 这个对应的Pod就会出现以下环境变量: 1234567KUBIA_SERVICE_HOST=10.10.122.234KUBIA_SERVICEPORT=8080KUBIA_PORT=tcp://10.10.122.234:8080KUBIA_PORT_8080_TCP=tcp://10.10.122.234:8080KUBIA_PORT_8080_TCP_PRORO=tcpKUBIA_PORT_8080_TCP_PORT=8080KUBIA_PORT_8080_TCP_ADDR=10.10.122....
K8s的五种代码生成器
K8s的五种代码生成器概述 代码生成器 说明 Conversion-gen 自动生成convert函数的代码是生成器,用于资源对象的版本转换函数 deepcopy-gen 自动生成deepcopy的函数代码生成器,用于资源对象的深复制函数 defaulter-gen 自动生成defaulter的函数代码生成器,用于资源对象的默认值函数 prerelese- lifecycle-gen 自动生成api-status.csv文件的工具 openapi-gen 自动生成openapi定义文件的代码生成器 除了上述之外,其实还支持很多,比如client-gen、lister-gen、informer-gen Conversion-gen自动生成convert函数的代码是生成器,用于资源对象的版本转换函数 常规引入tag1+k8s:conversion-gen=<peer-pkg> 生成规则https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/code-ge...
K8s-Service的负载均衡机制
K8s-Service的负载均衡机制Service对象通过关联转发到PodI实现负载均衡,每个Node的kube-proxy负责实现。 kube-proxy的代理模式通过启动参数–proxy-mode设 置 userspace模式(x)用户空间模式,由kube-proxy完成的代理模式,效率低,不再推荐 iptables模式kube-proxy通过设置Linux Kernel的iptables规则, 实现从Service到后端Endpoint列表的负载分发规则,效率很高。但是, 如果某个后端Endpoint在转发时不可用,此次客户端请求就会得到失败 的响应,相对于userspace模式来说更不可靠。 此时应该通过为Pod设置 readinessprobe(服务可用性健康检查)来保证只有达到ready状态的 Endpoint才会被设置为Service的后端Endpoint。 ipvs模式在Kubernetes 1.11版本中达到Stable阶段,kubeproxy通过设置Linux Kernel的netlink接口设置IPVS规则,转发效率和支 持的吞吐率都是最高的。ipvs模式要...
K8s-Pod的扩容
K8s-Pod的扩容背景在实际生产系统中,我们经常会遇到某个服务需要扩容的场景,也 可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的 场景。此时可以利用Deployment/RC的Scale机制来完成这些工作。 手动扩容 通过kubectl scale deployment $nginx-deploymenr --replicas 5 本质上是通过修改replicas 实现的 自动扩容HPAPod的HPA 从K8s1.1版本,添加了HPA(Horizontal Pod Autoscaler),其基于Master的的kube-controller-manager服务启动 参数–horizontal-pod-autoscaler-sync-period定义的探测周期(默认值为 15s),周期性地监测目标Pod的资源性能指标,并与HPA资源对象中的 扩缩容条件进行对比,在满足条件时对Pod副本数量进行调整。 工作原理HPA控制器给予Metrics Server的API指标,基于扩容规则实现进行计算,得到Pod副本数量。 然后HPA—>给副本控制器发起s...




