1.calico网络插件

在做三层解决方案时，calico是行业界的大哥，flannel只负责网络通信，而不提供网络策略，而calico即支持网络通信，也支持网络策略。




calico里有一些镜像，为了方便节点下载，我们先提前下载这些镜像，并上传到私有仓库中。

vim calico.yaml  ##编辑calico文件

这种方式和flannel的host-gw是类似的。
前面我们将ipip给关闭了，这里我们将其打开来测试一下。

vim calico.yaml  ##编辑这个文件

kubectl delete -f calico.yaml
kubectl apply -f calicon.yaml

==结合前面所讲内容，我们介绍了flannel和calico俩种不同的网络插件，还介绍了这俩种插件的一些使用策略如：flannel插件的vxlan模式，host-gw主机网关模式，vxlan+Directrouting模式;calico插件的ipip模式等。结合生产环境，我们选择最适合我们的网络插件及模式。

2.ingress服务

简介：
<1> 一种全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的 Ingress 服务。
<2> Ingress由两部分组成：Ingress controller和Ingress服务。
<3> Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。业界常用的各种 反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维 护了对应的 Ingress Controller。

官网：https://kubernetes.github.io/ingress-nginx/


同理，部署ingress需要一些镜像，为了方便节点下载，我们还是提前下载好，并且上传至私有仓库中去。

vim deploy.yaml

这个访问过程是，ingress的svc是NodePort模式，外界通过访问节点：暴露的端口就可以访问到Ingress的Endpoint即pod节点。








www1.westos.org我们设置的解析是192.168.43.17的，换成192.168.43.18也可以，当访问www1.westos.org:32223时，实际上访问的是ingress-nginx-controller-77b5fc5746-gbw5l这个pod，而这个pod其实就是个nginx服务



我们来修改一下service.yml文件和ingress.yml文件：

vim service.yml  ##编辑service文件

vim deployment.yml  ##编辑deployment文件

kubectl apply -f service.yml
kubectl apply -f deployment.yml

vim ingress.yml  ##编辑一下ingress.yml文件

kubectl delete -f ingress.yml
kubectl apply -f ingress.yml

现在来测试访问一下：

vim /etc/hosts  ##先添加解析

前面使用的是deployment控制器来部署的ingress，我们也可以使用daemonset方式来部署ingress。
用DaemonSet结合nodeselector来部署ingress-controller到特定的node上，然后使用 HostNetwork直接把该pod与宿主机node的网络打通，直接使用宿主机的80/433端口就能访 问服务。
<1> 优点是整个请求链路最简单，性能相对NodePort模式更好。
<2> 缺点是由于直接利用宿主机节点的网络和端口，一个node只能部署一个ingress- controller pod。
<3> 比较适合大并发的生产环境使用

vim deploy.yaml

从上面访问来看，没刷新一次，结果就跟着改变，对客户端来说如果单纯访问静态页面没事，但是访问应用，刚访问上又被调到其他节点了，这样客户端会一直在访问，所以为了解决这个问题，我们需要建立会话保持。

vim ingress.yml

Ingress TLS 配置:

vim tls.yml

kubectl apply -f tls-yml