k8s第三节 Kubernetes网络

一、前沿，为啥需要统一管理k8s网络的组件

参考：k8s网络之设计与实现

1. 每一个docker主机都是独立的，docker内置网段全部是172.17.0.1，一台主机上的多个容器是可以通信的,因为docker添加了一个docker0的网桥；但是跨主机之间的容器就无法通信了。原因：1）每个主机都是同一个网段，网段重复了、2）docker1主机上面的容器发送到docker2主机上面的容器（咋知道对应容器的ip是那一台机器、如何实现转发）
   
   

解决

• 1、给每个docker主机分配唯一的网段
• 2、做好记录，记录每个docker主机对应的网段
• 3、可以使用iptables或者把宿主机当做一个一个路由器，配置路由表

一句话：引入CNI解决跨主机容器通信

二：容器网络接口CNI来解决以上问题

容器之间通讯有上面的所列的问题，因此就有一个容器网络规范CNI（Contanier Network Interface）,
K8S就使用了CNI
其中比较重要的实现有Calico、Flannel

网络组件的要求或者特点有

1. 一个Pod一个ip
2. 所有的Pod可以与任何其他Pod直接通讯
3. Pod内部获取到IP地址与其他Pod或者节点与其通讯时的ip地址是同一个

2.1 Calico

1. Calico 恺粒go，支持包括Kubernetes、OpenStack等。
2. Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的虚拟路由器（ vRouter） 来负责数据转发，而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播。
3. Calico 项目还实现了 Kubernetes 网络策略，提供ACL功能。
4. 主要解决跨主机网络通信

参见: projectcalico.org quickstart
部署地址：kubeadm; github kubeadm快速搭建K8s集群【v1.19】、[kubeadm快速搭建k8s集群 gitee]

三、service

简介	命令
生成service导出到yaml ; 生成一个service，通过暴露名字叫做nginx-deployment的控制器deployment，对外暴露80端口转发内部8080端口,默认同deployment名称; 也可以通过**–name**指定service名称	kubectl expose deployment nginx-deployment --port=80 --target-port=8080 --dry-run -o yaml > nginx-service.yaml
查看创建service命令01	kubectl expose --help
查看创建service命令02	kubectl expose deployment --help
查看所有命名空间的service	kubectl get service --all-namespaces
生成service示例, --type指定service暴露类型	kubectl expose deployment nginx-deployment --port=80 --target-port=8080 --name nginx-service --type=NodePort
查看pods标签	kubectl get pods --show-labels
过滤标签	kubectl get pods -l app=nginx
查看创建的标签	kubectl get service、kubectl get svc
查看service代理后端的ip和端口	kubectl get endpoint、kubectl get ep
修改了yaml进行执行 或者更新yaml	kubectl apply -f nginx-service.yaml
使用系统默认编辑器打开	kubectl edit service nginx-service

3.1 service的暴露类型type：ClusterIp、NodePort、LoadBalancer

type英文	中文	解释
ClusterIp	集群内部使用	只能在集群内部、pod中进行访问，浏览器无法访问；原因：ip是k8s内部ip,浏览器无法访问集群内部ip
NodePort	对外暴露应用	浏览器可以访问，每个节点上都暴露一个端口进行访问；
LoadBalancer	对外暴露应用，使用公有云	自动配置暴露的端口到LB上；用的少,一般手工就可以了

端口	说明
port	service或者说Lb对外暴露的端口
targetPort	容器内部应用的端口，如：3306、8080
nodePort	service为NodePort类型，对外暴露随机端口的固定值

3.2、网络转发机制 iptables vs ipvs

推荐使用ipvs
一般小集群iptables也没啥问题

名称	命令
查看pods里面kube-proxy	kubectl get pods -n kube-system |grep kube-proxy
查看kube-proxy详情	kubectl describe kube-proxy-wg22f -n kube-system
查看kube-proxy详细日志，可以看到， Unknown proxy mode “”, assuming iptables proxy	kubectl describe kube-proxy-wg22f -n kube-system

四、Ingress 诞生

4.1 为啥有了Service还要Ingress

1：service都是4层的负载均衡，不支持7层（比如 端口、后缀等）
2：service nodeport需要提前规划，一个端口只能被一个服务使用

4.2 ingress 如何配置

4.3 ingress controller

ingress controller有很多实现，我们使用官方的实现。
ingress controller有两个作用：
1：使用nginx实现负载均衡
2：从api中发现service动态的配置列表，更新到nginx里面

kubectl get pods -n ingress-nginx ingress controller在单独一个命名空间
hostNetwork: true,需要和containers同级

4.4 ingress vs ingress controller区别

特点	ingress	ingress controller
定义	定义具体的一个转发规则	动态加载所有转发规则，更新到nginx
作用	单个ingress规则，类似：单个nginx转发规则	整体nginx

4.5 coreDNS

访问的时候，一般不要直接使用ip,ip可能会变；
因此我们使用service名称，这就需要dsn来解析。

nslookup nginx-service 同一个命名空间里面pod访问service
nslookup nginx-service.kube-system跨命名空间调用访问；在pod里面调用service或者其他命名空间service，我们就直接用服务名称，不要用服务ip。

4.4 练习 作业

把ingress controller pod固定到几台机器上面,如何做？
项目访问量少，每个节点都跑一个浪费
1：污点+标签nodeselector
2:  但有可能多个副本都跑到一台机器上了，+ds