目录
3、各节点IPtables及Firewalled服务被disable
5、安装kubelet、kubeadm(初始化集群指令)、 kubectl(api service的命令号客户端,Node不执行命令也可以不安装)
6、通过docker直接获取到的镜像文件,处于某种原因是直接获取不到的【通过docker save 保存;推到自己的私有仓库】
7、docker随后会生成大量的iptables规则,会对我们内部的iptables nf-call-iptables或者nf-call-ip6tables,会需要打开内生的桥接功能
8、初始化kubelet 【不能启动,只能设置开机自启;初始化工作还没有完成】
kubernetes集群在安装的时候要求有三种网络
Pod(Pod网络):每个Pod运行在同一个网段中,可以Ping通
Service(集群网络):和Pod不在同一个网段,Service地址是虚拟的假的,存在IP tables或IPVS中
Node(节点网络):节点的网段又是独立的一个,Node节点的IP地址,即物理机(宿主机)的网卡地址
这种网络Kubernetes不提供,需要于第三方依赖插件来解决,都可以托管在Kubermetes上,单Pod,或者守护进程来启动
提供网络服务: 提供IP
- Flannel (叠加网络):网络配置
提供网络策略(IPtables规则):去定义来同一个名称空间内,容器内不能访问,各容器之间访问
- Calico(三层隧道网络):网络配置,网络策略
- Cannel:用Flannel提供网络,用Calico提供策略
kubernetes中各Pod的通信方式
1、同一个Pod内的多个容器间:通过lo(localhost)通信
在Kubernetes中是允许可个Pod直接通信的:
2、物理机桥接:二次通信在ARP的时候是进行广播的,Node在到达一定规模的时候,没有网络空间可以用了,不建议使用
3、叠加网络(Overlay Network):docker0桥固定使用一个子网方式,在docker0桥运行的容器也不会在冲突的了
kubernetes中Pod的与Service的通信
Service只是IP tables或IPVS规则,Node节点物理机只需要把目标地址不是自己的指向网关(docker0桥的地址),当容器一个容器试图访问一个Service是,送给网关(docker0桥的地址),Docker0桥只需要去检查下iptables或IPVS就可以发现Service的地址了
Service也是会改变的,创建,删除;Pod发生变化通过Label Select来发现,但是Service怎么来该表所有节点的Iptables或IPVS规则尼?这里就需要Kube-proxy组件来进行管理
kubernetes中Etcd通信
Etcd通信,一个端口向内部(集群内部)通信,一个端口向外部(客户端)通信;
基于敏感信息使用https通信,在内部通信的时候需要使用点对点的通信,需要一套私有CA证书;
Etcd于客户端(API service)通信提供服务,而服务端的证书于客户端验证是靠同一CA签署来实现,也就是说Etcd和API Service的通信是要双向认证的,需要需要一套专用CA证书,;
API Service于客户但通信的时候也需要一套私有的CA证书,同Etcd和API Service原理;
API Service于可Node的Kube-Proxy通信也是需要一套私有的CA证书,同Etcd和API Service原理;
API Service于可Node的Kubelet通信也是需要一套私有的CA证书,同Etcd和API Service原理;
因此自己搭建的化需要5套私有的CA
kubernetes通过CNI来接入外部网络
CNI:容器网络接口
这些网络可以已Pod的方式运行为其他Pod提供网络服务,这个Pod是个特殊Pod虽然托管在集群中间,但他们需要共享他们的网络名称空间(看到的是物理机的IP)
部署前环境的梳理
Kubernetes架构简易图
环境部署图
部署的方式
部署的方式有两种
第一种部署形式
用传统的形式部署Kubernetes的Master的4个组件和Node节点上3个组件为系统级守护进程,自己去配置证书、配置文件、安装、等等,配置过程繁琐而复杂,一般首次搭建不建议常用
第二种部署形式
使用工具搭建,在github有人把用Playbook,只需要告诉Ansible谁是Master,谁是Node就可以,这种方式也是把把各组件部署为系统级的守护进程,这种方式Control-Manager宕机了,还需要自己去启动,没有办法保证了宕机后在启动
第三种部署方式
使用Kubeabm工具来安装,
每个主机上都会安装Kubelet,docker&