K8s速览

打印 上一主题 下一主题

主题 641|帖子 641|积分 1923

k8s的焦点本领

● 服务发现与负载均衡
● 服务恢复
● 服务伸缩
● 主动发布与回滚
● 批量实验
架构


server-client两层架构,Master作为中央管控节点,会和每一个Node举行一个连接;
所有UI层,client的操作,只会和Mater举行连接;
API Server:处理API操作,k8s中的所有组件都会和其举行连接,组件之间不举行独立连接,依赖于API Server举行消息通报;
Controller:控制器,负载集群状态的管理,譬如主动恢复,容器伸缩等都由controller完成;
Scheduler:调理器,为容器找到符合的节点举行放置;
etcd:分布式存储体系,API Server需要的原信息都被放置到etcd中;etcd本身是有个高可用体系,通过etcd也保证了k8s master组件的高可用;
工作流程-交互示例:


创建pod的哀求会交给API Server;API Server将数据存入etcd;
Scheduler通过watch机制知道有一个pod需要被调理;根据哀求的资源等信息举行调理决议,选中调理节点;
Scheduler向 API Server报告调理信息
API Server关照相应节点举行pod的实验启动
节点kubelet 就会去调 Container runtime 来真正去启动设置这个容器和这个容器的运行情况,去调理 Storage Plugin 来去设置存储,network Plugin 去设置网络。
Pod和容器设计模式

容器的本质:
● 一个视图隔离、资源受限的进程
○ 容器内PID=1的进程就是应用本身
k8s->相当于云时代的操作体系;
● 类推容器镜像就是这个操作体系的软件安装包
那么pod相当于进程组;一个逻辑单位,k8s中的原子调理单位;
Pod需要办理的问题:
怎样让pod内的多个容器搞笑共享资源和数据;
● 容器之间的是会通过Linux Namespace和cgroups隔离的
应用编排焦点原理

应用编排与管理

思考直接受理pod的问题
● 怎样保证集群中可用pod的数量
● 如作甚所有pod更新镜像版本
● 更新过程中,如作甚保证服务的可用性
● 更新过程中,发现问题怎样及时回滚

● 声明式spec,声明期望的副本数,用控制器去保证status和spec预期一致
● 直接修改控制器中声明的image
● 设置更新策略,可滚动更新大概全量更新,还可以设置最大不可用pod数
● rollout undo一键回滚上一版大概指定版本

设置信息管理

● 可变设置信息
● 敏感信息存储
● pod自我身份认证
● 容器资源设置
● 容器安全管控
● 容器启动前前置条件校验-securityContext

configmap

● 管理情况变量,命令行参数等------解耦容器镜像和可变设置,保障pod的可移植性
● 限定
○ etcd限定巨细1mb
○ pod只可以引用同定名空间下的cm
○ cm要在pod前创建,否则pod无法创建出来
○ cm中定义的key有问题时不会阻碍pod创建
secret

● 存储密码,token等敏感信息
● base-64编码生存
● 限定
○ 文件巨细表现1mb
seviceAccount

pod身份认证
Qos:服务质量

根据request和limit隐式设置

securityContext

● 限定容器的行为
● 容器级别-对指定容器见效
● pod级别-对pod中的所有容器见效
● Pod Security Policies(PSP):对集群内的所有pod见效
InitContainer

● Initcontainer会先于普通的container启动实验,所有InitContainer实验成功后,普通container才会实验
● pod中多个InitContainer是按定义次序一次启动实验,pod中多个普通container是并行启动
● 用途
○ 普通container启动前的初始化-如设置文件准备;前置条件检验-如网络联通检验
持久化信息存储

需要办理的问题
● 容器异常退出,保障之前的数据不丢失
● 同pod中的多个容器共享数据
Pod Volumes范例:
● 本地存储:emptydir、hostpath
● 网络存储
● project volume:secret、configmap、downwardAPI、serviceaccountToken
● PV&VC

csi 是什么?
csi 的全称是 container storage interface,它是K8s社区后面对存储插件实现(out of tree)的官方推荐方式。csi 的实现大体可以分为两部门:
● 第一部门是由k8s社区驱动实现的通用的部门,像我们这张图中的 csi-provisioner和 csi-attacher controller;
● 别的一种是由云存储厂商实践的,对接云存储厂商的 OpenApi,主要是实现真正的 create/delete/mount/unmount 存储的相关操作,对应到上图中的csi-controller-server和csi-node-server。
接下来看一下,当用户提交 yaml 之后,k8s内部的处理流程。用户在提交 PVCyaml 的时间,起首会在集群中天生一个 PVC 对象,然后 PVC 对象会被 csi-provisioner controller watch到,csi-provisioner 会结合 PVC 对象以及 PVC 对象中声明的 storageClass,通过 GRPC 调用 csi-controller-server,然后,到云存储服务这边去创建真正的存储,并最终创建出来 PV 对象。末了,由集群中的 PV controller 将 PVC 和 PV 对象做 bound 之后,这个 PV 就可以被使用了。
用户在提交 pod 之后,起首会被调理器调理选中某一个符合的node,之后该 node 上面的 kubelet 在创建 pod 流程中会通过起首 csi-node-server 将我们之前创建的 PV 挂载到我们 pod 可以使用的路径,然后 kubelet 开始 create && start pod 中的所有 container
总的来说,有三个阶段:第一个 create 阶段,主要是创建存储;第二个 attach 阶段,就是将那块存储挂载到 node 上面(通常为将存储load到node的/dev下面);第三个 mount 阶段,将对应的存储进一步挂载到 pod 可以使用的路径。这就是我们的 PVC、PV、已经通过CSI实现的卷从创建到使用的完备流程。

case:
● 抽象本地存储,只允许本机pod访问
● 云盘只允许同zone的pod访问
延迟绑定
应用健康

就绪探针:ReadinessProbe,存活探针:livenessProbe

k8s网络概念及策略控制

基本法:约法三章+四大目标
约法三章
● 所有pod可以与其他pod直接通信,无需显式使用NAT
● 所有Node可以与所有pod直接通信,无需表现使用NAT
● pod可见的IP地点确为其他pod与其通信是所用,无需表现转换
(NAT :网络地点转换,是将用于本地网络中的私有地点没在连接互联网是转而使用全局ip地点的技能)
四大目标
● 容器越容器之间的通信
● pod与pod之间的通信
● pod与service之间的统建
● 外部世界与service之间的通信
(service指k8s中的服务)
容器网络方案的两大派别
Overlay和Underlay
Overlay网络和Underlay网络

Netns

Netwok Namespace是实现网络假造化的内核基础,创建了隔离的网络空间
● 用于独立的网络设备(假造设备/物理网卡)
● 独立的协议栈,IP地点和路由表
● iptables规则
● ipvc

k8s Service



向集群外袒露Service

Service范例
● clusterIp-内部pod访问Service假造IP
● externalName
● NodePort-外部访问
● LoadBalancer-外部访问
LoadBalancer->NodePort->ClusterIP


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

钜形不锈钢水箱

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表