2020/05/11 集群2

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规则单拉一个特例*