K8S核心资源的管理方法,三种方法:
陈述式管理,基于kubectl命令
声明式管理,基于k8s资源配置清单,yaml或者json(pod,pod控制器,service对象,ingress对象,都抽象成一个个机构化文件,yaml或者json)
GUI式管理,基于k8s仪表盘(dashboard)
k8s还有4个核心附件,真正要搭建k8s集群,除了2进制方法去交付master组件和node组件以外,还必须有4个核心附件:CNI网络插件,服务发现插件,服务暴露的插件,gui图形管理插件。
只有这4个辅助插件,才能让k8s更好工作
clico这个网络插件,适合大的k8s集群,用flannel集群不大,选择host-gw,因为走的是内核,效率还是比较高的,但是vxlan就不行,要反复在用户空间过滤,效率比较低。
flannel在100台左右就足够用了
现在做个flannel实验,用之前的半成品k8s,并不用实操
没有,需要pull一个镜像下来,放到harbor里
给这个镜像打一个tag,push到自己的harbor仓库
把这个pod删除了
看一下是否有自愈的功能,已经running起来了,两个podip是172.7/22.2/172.7.21.2,k8s有三条网络,节点网络用10段的私有IP,pod用172.0,clusterip用的时候192
ping本机的肯定通,ping对端的,现在没有flannel肯定不通,flannel最简单的host-gw模型就是加路由,其他什么也没做
不仅要加路由,还有优化一条iptables规则,想让10.4.7.21这台主机代理docker的172.7.21.0/24这个网段,要加一条iptables规则,应该在filter表的forward的上去加,目的地址是172.7.21.0/24
现在就ping通了
在21上也加一下
现在就通了
这边日志就进来了
flannel真正要用就取优化snat规则,不能在集群内部pod访问,还要经过snat转换,否则宿主机效率就低了,所以k8s集群如果小,不用装flannel,自己就实现了。
用CNI网络插件就是实现pod和pod之间互相网络通信。
flannel好处就是,本身有监控状态检查接口,2041,委托给supervisor,进程异常退出,supervisor还能拉起来
把之前的环境退出
flannel,三种工作模式,host-gw,vxlan,混合模式
服务发现,3个比较重要的概念,k8s本身抽象出了两种资源(集群网络,不在宿主机上真实存在,只在集群里存在交互使用,用kube-proxy把集群网络和pod网络关联起来。kube-proxy不给pod提供网络承载环境,pod的ip可能宕机,扩容,pod是动态变换的,podip是不能作为服务接口的唯一的接入点,抽象出一种资源,固定的资源去指向对应的pod,也就是service,service借助标签选择器找到对应pod,把流量指到这一组pod上)
服务发现就是把这两个关联起来,使用了coredns软件,go语言写的,就是把集群网络和service名字关联起来,在使用服务的时候就不用记录cluster ip了,只要记录service名字就可以了,自动关联的
服务暴露有非常抽象的概念,ingress资源,专属暴露7层应用到k8s集群外的一种核心资源(http/https,很少用https(把https放到生一层,去卸证书,这样回来也是http))
ingress控制器,简化版的nginx(根据域名和url来调度流量)+go脚(动态识别资源配置清单yaml)
用traefik软件去实现了ingress控制器
去前端域名进来,找到了后端两个real server真实提供服务的pod,起traefik是以daemonset来起的,每一个运算节点上起一份,所以能看到的两个是podip
host是从traefik.od.com进来的,path:/,backend抛给traefik-ingress-service
service又通过标签选择器selector,到k8s-app:traefik-ingress,这一个标签
再看daemonset,daemonset是每一个节点都要起一个pod的,这样才能决定怎么把traefik的流量怎么帮你真正调度到pod里。
traefik软件主要实现两个功能,ingress控制器,有hostport:81这个配置,就是ingress控制器部分是和你宿主机共享网络名称空间。
还有一个pod是admin-web,跑的是8080端口
**docker有4种网络模式,none,NAT,host,combine两个容器用一个网络名称空间,边车模式
**
这个traefik.od.com实际上是一个admin-web的接入点,借助treafik本身的ingress控制器,帮你找到172.7.21/22.4:8080
traefik软件的dashboard,是用了自己的ingress controller实现了自己,这里是用的和宿主机一样的网络名称空间,8080是admin-web
建立一个ingress资源,从traefik。od.com进来是找下面ingress-service的8080端口你。
80是ingress控制器,8080是admin-web,traefik是两个功能
最后一个核心插件,dashboard,仪表盘
先交付1.8.3,再去交付1.10.1,要把dashboard作为一个容器注入到k8s里面去(第一步下载镜像,第二步准备资源 配置清单,依次应用到集群里)
打tag,推到harbor仓库里
名字写错了
现在完成了一个dashboard的镜像,下一步准备dashboard的资源配置清单
资源配置清单也是在官方上找的,到google官方kubernetes仓库
dp.yaml
svc.yaml
ingress.yaml
暴露给集群外面,就要起个名字dashboard.od.com,通过访问这个域名就能访问dashboard容器
放到yaml仓库里
dp.yaml
svc.yaml
ingress.yaml
dashboard里有四个文件,这就是为什么kubelet可以指定网络文件
如果想直接apply -f文件,点击raw
就可以直接复制上面的地址
任选一个运算节点去应用这个dashboard配置清单,把用户权限创建好
容器应用进来
把service资源创建出来
应用ingress.yaml
官方的是用的pod控制器是deployment,默认放在kube-system命名空间
给了个limit,相当于限制容器启动资源,request指的就是容器起来就要吃多少资源,资源不满足,容器起不来,limits,最多容器吃多少资源
这里相当于启动dashboard的运行参数,自动生成证书,挂在两个目录,certs和tmp目录
容器的存活性探针,在k8s里,给容器两个探针,存活性探针,就绪性探针,
存活性探针:判断你的容器在k8s环境下是否正常启动,或是在运行中,是否有异常退出。
就绪性探针:就是容器被k8s拉起来以后,先用就绪性探针去探测直到满足要求,才认为是就绪状态 running,才认为是running状态,
livenssprobe:在容器不断运行的过程中,不断的探测你是否存活,就是存活性探针。
schema协议,去探测容器里的8443端口,只要8443端口活着就认为你是容器活的,如果死了,就启动自愈机制,
volume就是定义的存储卷
containers 的name是给容器起一个名字
dashboard已经起来了
现在浏览器访问直接访问域名即可
需要做dns解析,滚动版本号
前面的nginx其实是7层的总入口,只要符合匹配.od.com这个域名,都要从7层进来,负载均衡抛到ingress controller上*
生产中有点粗鲁直接restart,其实可以用rndc,去reload named里的值,所有区域的数据应该加载内存里,resatrt相当于把内存清空,区域多,这个restart就伤了,所以一般用rncd去指定reload的指定区域
coredns指向forward的上一级dns是非常有必要的,自建的coredns和上一级dns有forward关系
dashboard页面现在是,1.8.3
kube-system下实例了两个deployment,核心资源,一个是coredns,一个是dashboard
traefik在daemonset里,两个pod控制器需要掌握,daemonset,deployment
这里使用json格式来展示的yaml
spec就是真正定义pod控制器的属性,selector就是标签选择器,
下面就是定义一个template模版,实际上是pod的模版,pod的一些特性就被定义到了pod控制器里,pod资源本身是一组对象,启动参数,内容,挂载,存活性探针都可以定义到pod控制器里
里面有一堆启动参数
一个是暴露81端口,一个是用nat的网络8080
resource是限制你pod的资源的
从spec到这都是pod特性,可以用explain来看显示的意思
serviceaccount服务账号,牵扯到了k8s的核心理念,rbac
基于角色的访问控制,RBAC(role basic access control)
对一些资源有一些权限(读get,写wirte,更新update,列出list,监视watch),用户就有用户账户,在k8s里有两种账户(用户账户user accoun UA,服务账户 service account SA)。
之前启动kubelet的时候做了一个kubeconfig配置文件,这个kubeconfig配置文件就是用户的配置文件
这个名字就是k8s集群里的一个用户账户,用户账户的名字就叫k8s的node
什么样的账户什么样的权限,这个就是授权的过程,k8s基于角色的访问控制下,无法直接给账户赋予权限,只能通过中间的一个角色,先给用户账户和服务账号先去绑定响应的角色,然后给相应的角色赋予相应的权限,也就是等于中间收个过路费
角色就完美充当了,账户要想获得集群里相应权限的中间人,无法给账户赋予直接的权限。
**
在k8s里有两种角色(role普通角色(只能应用在某一个特定的名称空间下,比如kube-system名称空间,就可以给kube-system里创建相应的角色,如果create一个role资源指定了-n namespace=kube-system,name这个角色只对本名称空间有效),clusterRole集群角色,对集群整个有效)
**
所以绑定角色操作就有2种,role binding,clusterrolebinding,把账户绑定角色,就称为绑定角色,也是一种资源,也有对应的yaml文件
服务账户是所有在k8s里面运行的pod,是k8s最小的运行单元,所有的pod都必须有一个服务用户service account
default名称空间,有两个起来的pod
对应的镜像是nginx;curl
只要运行在k8s集群里的pod,就一定有一个服务账户,如果没有显示指定的服务账户,就给你一个默认的服务账户
traefik的rbac的yaml文件最好看
第一段配置声明了一个叫service account的服务用户,这个服务用户的名字叫traefik-ingress-controller。名称空间在kube-system。
实际上这段就创建了服务用户
这一段其实在做clusterRole,相当于去声明一个集群角色,名字叫traefik-ingress-controller。然后定义了一组规则rules:定义角色的同时赋予权限
clusterRolebinding集群角色绑定,说白了就是把之前定义的角色和traefik-ingress-controller服务账号关联起来
metadata是name是集群角色绑定的名字,roleref是参考哪个集群角色是traefik-ingress-controller。
subjects就是集群角色给哪个用户使用,类型是服务用户,和集群角色通过clusterrolebinding这种资源,关联起来了
所有的rbac文件,无外乎这几步,创建账户,比如traefik是以pod身份在k8s集群工作,所以只能用服务账号。kubelet就不是工作在k8s里的,是在宿主机上二进制部署的,就不能用服务账户,而是用户账户,只能给kubelete做kubeconfig,kubecetl 4部,setuser,set creditals,seyt context ,use context,创建用户账户就需要这四步,实际上就是去创建一个用户账户的配置文件
traefik是通过pod的方式,交付在k8s里,pod要去取得一定的权限,必须给它创建一个服务账户,第二步就是定义角色去赋予角色相应的权限,就是创建一个clusterRole,就是traefike-ingress-clusterRole。
第三步是绑定角色(账户和角色绑定起来)
这就是RBAC的本质
traefik里的daemonset一定就指定你的service accountname就是你刚才创建的serviceaccount。既然有RBAC,就是让pod具有能够调度k8s里相应资源的能力,相当于创建一个serviceaccount账户,然后给这个账户赋予相应的权限,然后要对这个账户做角色绑定。
在声明traefik控制器 的时候,要显示的指令,serviceaccountname就是traefik-ingress-controller
dashboard比traefik稍微复杂点
声明了一个服务账户,叫做kubernetes-dashboard-admin
下面做了角色绑定,没有做定义角色并赋予权限。做了一个clutserRolbinding的name是kubernetes-dashboard-admin。
roleRef是参考哪个角色,这里参考了默认集群里带有的集群角色cluster-admin,集群管理员
默认带有一堆集群角色,有一个默认的集群角色叫cluster-admin
这个yaml就是定义角色并赋予权限
名字是cluster-admin
权限是对所有api组,所有资源,所有权限,也就是具有k8s集群的最高权限
在dashboard的rbac.yaml里,只做了两件事情,
1.创建了一个新的服务账户service account
2.把创建好的账号和集群中默认的clsuterRole角色,绑定起来
默认的集群角色,名字是system:node
对api组里的哪些资源有哪些权限,对哪个资源组里的什么资源有什么权限
这个用户是k8s-node,给这个用户账户,去绑定一个集群角色,叫system:node(集群角色)。
真正绑定的时候cluter-node和user之间 关系
这个dashboard的pod,它的用户账户就是k8s的最高权限
看一下官方的rbac文件
声明了一种role资源,这个role资源称为kubernetes-dashboard。名字是kubernetes-dashboard-minimal,说明我们要给dashboard最小化权限
给了一堆角色的权限
做了一个roleBinding
官方的service account写在deployment里了
官方也是三步,1.定义service account,2.定义一个普通角色并授予最小化权限,3.把普通角色和最小化权限做了绑定
其实告诉我们dashboard,可以不用集群管理员的形式运行
kubenetes dashboard可以接受两种配置文件,kubeconfig是普通用户的配置文件(把普通用户做出来,然后把普通用户绑定一个集群角色,这个集群角色可以是自定义的具有某些权限的角色或者集群角色,也可能是用默认的集群角色)
dashboard就要看你登录上来 人具有什么权限
第二种方法就是用token方式,一个服务账户service account默认会产生一个资源serect
在default名称空间里可以看secrect
这就是默认service account的secret
这就是默认default service的令牌
如果到kube-system名称空间去,serect其实有很多,有default,有coredns(也声明了serviceaccount,对应一个secret,这个serect里有自己的一个令牌)
在dashboard-admin这个serviceaccount用户里也有令牌
把令牌拷贝就可以进来的,现在还不行,因为是不安全的链接,所以需要去手撕证书
现在去创建证书,要去运维主机
cfssl可能更加简单些,现在用openssl试试,先去创建dashboard网站的私钥,权限是600,私钥弄出来,加密算法用2048位
第二步用openssl做证书签发的请求文件csr,-subj主题,要给这个域签发,cn就必须对应域名,之前对k8s签发的时候,都是对于k8s组件的名字,或者是对应集群角色
创建了证书签发的请求文件csr
用openssl去签发证书,,-CA 指定ca,-out是真正要配置在nginx里的证书,days时间给个10年
一个证书一个私钥
用cfssl查一下证书
这些证书和私钥只需要拷贝到nginx里
这里把所有od.com的域全都引到了traefik的ingress控制器
现在有特殊需求,dashboard.od.com域,要走443,走https,直接抛到ingress,必须在上层负载均衡里把证书里卸载
监听了server_name dashboard.od.com,把所有请求直接rewrite给了https,监听了443端口,server_name依然是dashboard.od.com。
证书地址,在path给 traefike-ingress-controller,就是把证书卸载了,还是用http去请求dashboard
在kube-system里有若干 secret
这就是dashboard令牌
令牌就出来了
如果不成功,可以换成1.10.1的dashboard
换镜像就比较简单了
打标签,push到harbor仓库
改一下版本
到22节点上启动应用也可以直接在dashboard改
就会自己去更新镜像,新的已经起来了
1。10就强制你去登陆
拷贝令牌
这就是1.10的dashboard
dashboard可以用令牌的方式进行登陆
用令牌登陆就需要kubectl describe secret,获得这个令牌
实际上是kubernetes-dashboard-admin这个service account 服务账号产生的
一个服务账号一定是对应唯一的服务账号的secret,secret秘密配置
kubernetes-dashboard-admin这个service account 服务账号产生的,这个服务账号里就有令牌复制出来
令牌复制到这里来登陆
就获得了kubernetes-dashboard-admin这个service account对应的角色,角色是cluster admin,cluster-admin所绑定的权限是集群管理员
官方给了role和rolebinding,拷贝一下
在运维主机上
还有一个service account
复制到最上面
先去执行rbac-minimal.yaml
里面其实创建了一个service account ,名字是 kubernetes-dashboard
定义了一个role,叫做kubernetes-dashboard-minimal,给了一堆比较小的权限rules
最后做了角色绑定,这个权限相对比较小
先创建出来
修改使用的服务账户
再去apply dp.yaml,相当于重新配置一下了
滚动升级,先拉起一个正常了,再把原来的干掉
现在有两个service account,两个令牌一个 kubernetes-dashboard account, kubernetes-dashboard-admin的account
这张令牌
权限不够就各种报错,也就是官方给的dashboard-minimal权限是非常小的
去拿admin的令牌,试试能否登陆进去
能够登陆进来,你有令牌就调整根据这个service进来的account的角色,默认给的是最小minimal的角色
换成1.8.3可能更加清楚
1.8.3的镜像也在harbor仓库里,等它起来就行
skip就是用dashboard的pod默认的服务账户(现在用的是minimal)
所以skip进去以后没有权限
dashboard这样 规定权限,可以开发使用,测试使用,也就是不光运维可以用
这个是集群管理员的权限
这张令牌就需要你好好保管,说白了就是集群管理员
如果要限制权限,就需要做一个service account clusterRole或者role都行,用service account和cluster role做一个绑定。K8S控制权限就是基于访问控制来控制的
一个pod起来只能对应一个service account,但是这个service account可以对应不同的权限。
pod实际上是承载了service account,service account可以对应不同的角色(既可以是集群管理员,又可以是观察者的角色)rbac就是账户和权限不产生直接关系,而是角色和权限产生关系。通过角色这个中间层,把账户和权限隔离开了
这里改回admin,后面方便做集群管理
生产中建议把skip按钮去掉
】重新configure、
现在直接skip进去就是用的集群管理员admin,什么权限都有,这样非常不好
dashboard 也有小插件,dashboard本身是k8s的插件,但是dashboard本身也有个插件,现在heapster地位比较尴尬,只能称为菜单
是dashboard下面的一个小插件
quay.io和dockerhub都是仓库
打镜像,push到harbor里
deployment就是用heapster起来的pod控制器
serivce
创建一个service account,名字叫heapster,在kube-system名称空间里,rolebinding到一个默认的集群角色,system:heapstr
command 就是cmd指令,后面的source,省略了svc.cluster,kubernetes在内部使用可以用service名字来调用,因为coredns指向了192.169.0.1 443集群地址
把8082整到80端口
正在创建中
不保存数据,只是提供一个可以参考的监控指标
仅供参考,真正去监控资源的还是普罗米修斯
进入到某个pod里,由scheduler帮你决定一个节点,7-22.host.com
拉了一个镜像
启动镜像
logs还可以看容器日志
这里是针对名称空间的,traefik现在消耗比较多
现在版本是1.15.4,,太高了可以回退版本
两个节点都是1.15.4,升级k8s的时候,要在流量低谷的时候做
现在集群了有不少pod,因为scheduler帮你去做平衡,先去升级21
先把node从k8s集群里摘出来
就剩一个节点了
原来在21上的coredns就跑到22节点上了
coredns完全没受影响,尽管从一个节点到了另外一个节点,这就是容器编排的特性
做的好一点,就把11上的nginx,把21的upstream注释掉
7层的负载均衡也注释掉
现在上1.15.4回退到1.15.2
生产中解压,还是需要慎重一点
这时候就有两个版本,1.15.2和1.15.4
原来kubernetes是一个软连接
要把源码包先删除
把这些都删除了
把所有的.sh拷贝一下
现在只要把软连接删除,指向1.15.2,启动即可
把软连接重建
重启这个进程就是新的软连接
只要kubelet一重启,就帮你加到集群里了
现在的版本就升级到2了
要换成1.15.4就把这个软连接继续删除
生产上不建议 kill -9
再启动一下
生产上平滑升级就这么做,把集群流量先断掉,node节点摘掉,新的软件包准备好,软连接也准备好,挨个重启服务
treafik只是daemonset,再21上起了一个
现在把nginx的流量调度恢复
4层的也进行恢复
两台nginx上跑了一个keepalive,把另外一台也配置上
把配置黏贴过来
这样nginx也都好了
完全是用traefik-ingress控制器来对流量进行分发,也就是ingress的资源就是一个可视化的nginx
把容器删了,自己会钻到21上了
dashboard现在就一个副本,想要2个
就会给你起来一个,这样就很方便对容器横向扩容
小人输入dashboard.od.com,流量是从笔记本浏览器经过dns解析到vip 10.4.7.10上(也就是10.4.7.11/12),进入到11节点上的7层负载均衡nginx里,nginx看到你请求的域名是dashboard.od.com,于是匹配到了自定义的dashboard.od.com,rewrite 443,卸载到了证书,然后帮你抛到了ingress上,ingress监听在了每个宿主机运算节点的81端口,把dashboard.od.com抛到了ingress,ingress控制器就会根据你的ingress资源配置找到host:dashboard.od.com,路径 /给你抛到dashboard的service上,相当于kubelet 把service和pod链接起来了,帮你找到了pod,pod在不同的节点,由kube-proxy的轮询算法,ipvs
这里就是dashboard,kube-proxy找到了192.168.40.188:443,用永不排队的NQ,lvs的轮询算法,轮询到172.7.21.5:8443,让两个dashboard能够交替给你服务。
跨宿主机能够通信,是因为装了CNI网络插件
Dubbo是一个阿里开源的微服务框架,基于java开发
Dubbo的架构,最主要的组件是registry(注册中心,服务发现就依赖这个注册中心,不管是消费者还是提供者都需要去链接注册中心,提供者provider到注册中心是注册地过程,消费者consumer到registry是订阅subscribe)
consumer 调用invoke provider提供者,是通过rpc协议去调用的,也就是远程过程调用,就好像在调用本地方法一样
这样就可以一些服务拆开了,consumer是web工程(各种页面调用的方法是后台不同的provider)
consumer是web工程(各种页面调用的方法是后台不同的provider),以前是调用本地方法,消耗本地资源 ,服务器就需要升级,不利于横向扩容,调用这些服务的时候,都可以让他们独立的一个个写成单独的服务,web服务区调用服务的时候,就好像在调用本地方法一样,实际上是资源不重叠的
真正交付Dubbo,要交付registry,provider,然后monitor和consumer
实验架构图,右上角是注册中心,Dubbo微服务的注册中心是依赖于zookeeper来做的,中间段是k8s集群,有DUbbo微服务提供者集群和Dubbo微服务消费者集群,都是封装pod,交付到k8s里,把能够动态扩容的服务都放到k8s里,把微服务的消费者和提供者交付到k8s集群里,同时把Dubbo-monitor交付到k8s集群里。
开发会把代码放到版本控制中心,运维使用恰当工具持续集成部署
编译代码,打包成docker镜像,放到harbor仓库里,ops服务器就是hdss7-200,做一个k8s的资源配置清单,应用到k8s里,就把代码变成了pod
用户访问找ingress,ingress配置好规则daemon.od.com,然后到消费者集群,消费者集群是一个web服务
这里需要把zk放在k8s外面,原因是zk是典型的有状态服务,不适宜放到k8s里进行管理
k8s具有很强的动态性,pod是可以漂移的,所以pod管理的一定是不能有状态的,无状态的意思就是这个容器死了就死了,无所谓,随便扩容,随便死。
有状态服务,是要有数据持久化下来,很不适合放在k8s里管理,k8s也有专门管理有状态服务的,叫是StatefulSet,这个pod控制器来管理有状态服务