3.10 安装部署coredns
先理解什么是服务发现,服务之间相互定位的过程
服务发现需要一定机制,以不变应万变,变化的地方,想办法以一个不变的东西来帮你定位到变的量
在k8s集群里,pod的ip是不断变化的,抽象出了一个service资源,通过标签选择器,关联一组pod(也就是接入service的cluster ip,就把你关联了一组pod)
抽象出了集群网络,通过相对固定的“集群ip”,使服务的接入点固定。
抽象出了一个service资源,也就是抽象出了name,还有clusterip。可以用传统dns模型,给一个主机域,一个ip地址。
试试在k8s里也建立这样的关系,找一个服务把service和clusterip进行绑定
实现k8s里dns功能的插件有两个kube-dns 和coredns,dns插件就是为了实现服务发现,就是把service的名字和cluterip自动的关联起来
flannel,master,node组件都是二进制方式部署,现在通过往K8S里交付容器的方式交付软件
nginx配置文件
自建的域名,需要解出来
别忘记序列号前滚
浏览器就可以访问了
这里下载的是二进制包
dockerhub上有1.6.5的镜像
要用容器的方式往k8s里交付软件
打一个tag,放到自己的harbor里
这样就来了
准备资源配置清单,管理k8s集群,核心资源的管理就是核心资源的管理
cm.yaml
dp.yaml
svc.yaml
’
forward就是指向你的上级dns
顶行写
coredns有yaml
分类4个文件其实把分类弄清楚了,rbac就是权限,要把授权弄明白
configmag就是对coredns的配置
forward就是指向上层dns
deployment就是coredns的pod控制器
service也是通过资源配置的方式定义出来
先去创建rbca.yaml,用陈述式管理方法去声明式一个apply,create三个资源
真正把cordns容器放到了kube-system的名称空间,已经running起来
3.11 coredns原理解析
现在coredns运行起来了
-o wide看一下,service的ip是192.168.0.2
这里规定了集群的地址
集群的dns已经在kubelet启动的时候定死了,也就是coredns无论如何都要跑192.168.0.2
dig命令验证下coredns,我们在cm里指定了forward是10.4.7.21,自建dns是coredns的上一级dns,所以没道理查不到,但是coredns本意不是做这个事情 的
coredns实际上就是关联了这个事情
nginx-dp还有,现在想去nginx-dp创建serivce,两种方法,陈述式,声明式(创建service的yaml文件,apply)
service名字现在叫nginx-dp,cluster-ip是192.168.238.250
使用coredns查询nginx-dp的service name,需要用fqdn
是跑在了172.7.22.3
通了
curl一下域名
集群里试试curl
之前可以用短域名因为search里有host.cm短域名,所以把前三个都加到search里了,才能用短域名
黄导的推荐看看
这里是默认查询5层才可以找打解析,效率比较低
把coredns安装到k8s集群里,最重要的就是,要把service的名字和clusterip做一个自动关联,做了一个自动关联,就实现了服务发现,只需要记service名字,管后面的pod,更新频繁,换门牌号,还是找孪生兄弟
3.12 k8s服务暴露之nodePort型Service
现在需要考虑k8s的服务暴露
k8s的dns实现了在服务在集群内被自动发现,找集群内部的服务肯定是通过service的名字
这个fqdn只在k8s集群内部生效
**怎么把k8s服务暴露,让外部也能访问nginx-dp,两种方式。
使用nodeport型的service(无法使用kube-proxy的ipvs模型,只能使用iptables模型)
使用ingress资源:ingress只能调度并暴露7层应用,特指http和https协议
**
这个node port只是演示,不做要求
把proxy-node改成iptables,iptables的scheduler只能用rr
生产中不建议这么做,要优雅的启动服务,supervisor会自动帮你拉起来
已经改变工作模式了
现在已经有了一些iptables规则
-t指的是tcp规则,-D删除
在22上也执行一遍,dns默认走udp,coredns默认走udp53端口
现在就没有规则了
这个node port只是演示
以daemonset的nginx,以它为例
也就是service的80端口,映射成了宿主机的8000端口
只有一个kubernetes
已经把8000端口映射出来了
这样在宿主机上就可以直接访问了
在22上也监听了8000端口
用node-port型的service,事实上是通过kube-proxy去写iptables规则,让你去访问呢cluster-ip的时候,帮你把流量怎么从宿主机上监听8000端口,把流量引入到容器里
node-port的ipvs是一种服务暴露的方法
把svc ,delete了
再次修改kube-proxy的工作模式
工作模式切换成了ipvs了
自己发现自己加上了
用ipvs相当于在k8s里内嵌了一套lvs
3.13 k8s服务暴露之ingress
建议只http,因为https涉及到证书
有直接在前面的l7层反代上配置证书
ingress的本质就是基于域名和url路径,把用户的请求转发至指定service资源的规则,ingres可以根据域名指定不同的service,实际的流量调度,请求到达ingress,ingress根据域名匹配到不同的service,service根据label找pod,真正提供服务的是pod
真正流量是这么走的,一个用户想要请求到www.od.com/abc,显示由dns,把www.od.com解析到vip10.4.7.10,经由L7层的负载均衡器,随机指派到两个ingress,ingress会加上监听www.od.com的规则,有abc路径的规则帮你去找到kube-proxy实现的service,service再去找pod
通过ingress暴露服务本质上是,可以将集群外部的请求流量,转发到集群 内部,从而实现“”服务暴露
ingress类似一个简化版的nginx+go语言的脚本
可以以traefik为例,来部署ingress
资源配置清单目录
部署traefik,ingress控制器
其实1.7.2版本足够了
首先找traefik镜像
push到harbor仓库里
顺序就是,准备镜像,配置资源配置清单,依次执行创建,检查
准备dashboard,准备镜像,准备资源配置清单,依次执行创建
真正交付到k8s的软件,比二进制部署还要简单
第一步创建rbac.yaml
第二部创建daemonset,traefik作为ingress的controller,有两种部署方式要么用traefik-deployment,要么用traefik-daemonset。
traefik工作模式要么一个宿主上跑一个,要么一个宿主机上跑多份
这些yaml其实有example
现在准备一个宿主机上跑一个副本
修改下
配置service
用ds方式启动的时候,暴露了两个端口,ingress controller,就是帮助ingress资源实现功能的组件,
ingress controller把docker的81端口放到宿主机上的80端口,admin-web是traefik管理界面
service是申明了两个端口
ingress资源里有spec,一组由域名和url组成一组规则的组。
host的就是域名,treafik.od.com(所以之前做了bind9的dns)
为什么能找到百度就是因为它有一个上一级的dns,10.4.7.11,找不到就去找网络运营商的
paths下面有路径
paths下有个列表,列表第一个对象是key是path,value是/,第二个也是对象,key是backend,然后里面还有value
从这里看就是nginx,ingress所以就是简化版的nginx+go脚本
修改下ingress规则
现在就开始应用
可能有错的
还没起来肯定有问题,先删除
把kubelet重启一下,可能是之前换了kube-proxy规则,也就是iptables规则
running起来了
还是重启kubelet才可以
81端口实际上是在宿主机被监听的
每个宿主机都监听了一个81端口
现在给了一个统一的入口81,所有http走7层流量,都需要从81进去,用ingress规则找特定的service
弄一个神操作,配置反代
7层反代,定义一个upstream,81 是ingress controller端口,现在起的是daemonset控制器,每一个宿主机都要起一个pod,现在有两个宿主机,有两个server
下面做了一个泛域名匹配
location /无差别的 proxy path给了ingress controller。
nginx就这点配置,不会再多了,如果要调度7层流量规则,只需要申明ingress资源配置清单
把这个7层流量没有差别的反代给ingress controller,申明了ingress类型的资源,真正要到traefik.od.com域名path :/的时候,找这个service
也就是在前面分发代理的时候不需要动
7层调度完全交给traefik来做了,交给ingress来做了
转发给ingress之后,如何转发给pod就全部交给ingress了
所以现在上线新业务的时候,前滚序列号,下面加个域名解析记录
traefik.od.com,为什么能走到10.4.7.10上,是做了bind域名解析,10。4.7.10这个vip附着在了10.4.7.11宿主机上,所以要找10.4.7.11的反向代理规则。
之前在nginx配置的配置就是把.od.com这个业务域的流量,无差别抛给ingress,真正在ingress里应用了一个ingress类型的资源配置清单,有一个配置清单叫host名字是traefike.od.com,有一个path规则:/ 也就是location /,无差别抛给一个service,这个service的名字就叫ingress traefik service*
无差别抛给了service
这个service是如何找到这个pod的,可以通过node selector
小人是如何访问集群里pod的,通过域名解析,10.4.7.10附着到 10.4.7.11,无差别抛给ingress,ingress导入到serivce(service是由kube-proxy组件实现的,把流量无差别的找到service名字,匹配域名找到service),service找到指定的pod。
这是pod对外暴露给小人的一套流程
**前面为什么要顶一个L7层代理,ingress controller本身就是个简化版的nginx(简单的流量调度功能,没办法实现复杂的,比如rewrite)+go语言脚本,自动发现service名字,其实是指定service的名字靠coredns指向cluster ip,clusterip用ipvs规则就找到真实 的pod。
**
ingress找到pod,是因为ingress只做流量调度,流量分发,但是是简化版的nginx,里面没有办法实现一些复杂的流量调度功能,比如rewrite
如果有rewrite应该在nginx上做
rewrite有一个卸载证书的需求,遇到指定情况,可以走指定的server name,直接找dashboard.od.com而不是找.od.com,也就是rewrite规则单拉一个特例*