这个技术一定会成为以后企业技术的标准
尙硅谷的王阳这个部分这个讲的特别好,可以自己去看
1,发展经历
阿里云iaas Infrastructure as a Service
平台及服务paas新浪云 platform as a service(号称免运维)(docker是下一代的标准)
容器化以后组件集群不好管理,映射关系比较困难。效率低下。端口乱七八糟。
saas软件设施及服务 software as a Service
容器集群化有什么好方法
用资源管理器。
Apache Mesos分布式资源管理的框架(之后使用k8s)
docker SWARM出现了(功能太少,优点是特别小)没有滚动更新回滚
他们退出历史舞台
k8s靠山是谷歌
容器化基础架构 borg Go语言(现代c语言) Borg
k8s特点:
轻量级。消耗的资源小,开源,弹性伸缩。负载均衡。IPVS
适合人群:软件工程师,测试工程师,运维工程师,软件架构师,项目经理
2,知识图谱
介绍说明:
前世今生 Kubernetes框架 Kuberetes关键字含义
基础概念
什么是POD 控制器类型k8s中的网络通讯模式
构建k8s集群
资源清单:
资源,掌握资源清单的语法。编写pod。掌握pod的生命周期
pod控制器
掌握各种控制器的特点以及使用定义方式
服务发现
掌握svc原理及其构建方式。
存储
掌握多种存储类型的特点,并且能够在不同环境中选择合适的存储方案(有自己的见解很重要)
服务的分类:
有状态服务:跟项目DBMS缺失了东西
无状态服务:流水线工人LVS APACHE(数据可以通过数据共享去完成)
调度器
掌握调度器原理 能够根据要求把Pod定义到想要的节点运行
集群安全机制
安全:集群的认证,鉴权,访问控制,原理及其流程
HELM
Linux的yum包管理工具RPM包 掌握HELM原理 HELM模版自定义 HELM
运维
Kubeadm认证只有一年。也就是需要每年更新一次,内网的话会有问题。所以会修改源码为10年。能够构建高可用的kubernetes集群
3,组件说明
etcd:
官方将他定位成一个可信赖的分布式键值存储服务。它能够为整个分布式集群存储一些关键数据。协助分布式集群的正常运转。
推荐在Kubernetes集群中使用Etcd v3 v2版本已在Kubernetes v1。11 中弃用。
APISERVER:所有服务访问统一入口
CrontrollerManager:维持副本期望数目。
Scheduler:负责接受任务,选择合适的节点进行分配任务。
ETCD:键值对数据库。储存K8S集群所有重要信息。(持久化)
Kubelet:直接跟容器引擎交互实现容器的生命周期管理。
Kube-proxy:负责写入规则至IPTABLES,IPVS,实现服务映射访问的
COREDNS:可以为集群中的SVC创建一个域名IP的对应关系解析。
DASHBOARD:给K8S集群提供一个B/S结构访问体系。
INGRESS CONTROLLER:官方只能实现四层代理。INGRESS 可以实现七层代理。
FEDETATION:提供一个跨集群中心多K8S统一管理功能
PROMETEUS:提供K8S集群的监控能力
ELK:提供K8S集群日志统一分析介入平台。
高可用集群副本数据最好是>=3 奇数个。
POD概念
自主式Pod
死了就没人管。
控制器管理的Pod
只要有pod就会启动pause,容器>=1.公用pause的网络栈,html的存储
ReplicationController
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出。会自动创建新的Pod来代替。而如果异常多出来的容器也会自动回收。
在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationControlle
ReplicaSet(官方使用)
ReplicaSet跟ReplicationController没有本质的不同,只是名字不一样,并且ReplicaSet支持集合式的selector。
Deployment(有一个滚动更新)
虽然ReplicaSet可以独立使用。但一般还是建议使用Deployment来自动管理ReplicaSet,这样就无须担心跟其他机制的不兼容问题。(比如ReplicaSet不支持rolling-update但 Deployment支持)
滚动更新:建一个删一个,
RS不会删除,会停用
HPA
Horizontal Pod Autoscaling 仅适用于Deployment和ReplicaSet,在V1版本中仅支持根据Pod的CPU利用率扩缩容。在vlalpha版本中,支持根据内存和用户自定义的metric扩缩容
StatefulSet
StatefulSet是为了解决有状态服务的问题。(对应Deployments和ReplicaSets是为了无状态服务而设计),其应用场景包括:
稳定的持久化储存,即Pod重新调度后还是能访问到相同的持久化数据。基于PVC来实现
稳定的网络标志,即Pod重新调度后其PodName不变。基于Headless Service(即没有Cluster IP 的Service)来实现
有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现。
有序收缩:有序删除。(即从N-1到0)
DeamonSet
DeamonSet确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时。这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
使用DaemonSet的一些典型用法。
运行集群存储deamon,例如在每个Node上运行glusterd、ceph。
在每个Node上运行日志收集daemon,例如fluentd。logstash。
在每个Node上运行监控daemon,例如Prometheus Node Exporter
Job Cronjob
Job 负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。
Cron Job管理基于时间的Job,即:
在给定时间点只运行一次。
周期性地在给定时间点运行。
服务发现
网络通讯方式
1.kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中,这在GCE(Google Compute Engine)里面是现成的网络模型,Kubernetes假定这个网络已经存在。而在私有云里搭建Kubernetes集群。就不能假定这个网络已经存在了。我们需要自己实现这个网络假设。将不同节点上的Docker容器之间的互相访问先打通。然后运行Kubernetes。
2。同一个Pod内的多个容器之间:lo
各Pod之间的通讯:Overlay Network
Pod与Service之间的通讯:各节点的Iptables规则。
Flannel 是 CoreOS 团队针对Kubernetes设计的一个网络规划服务,简单来说。他的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络。将数据原封不动地传递到目标容器内。
ETCD之Flannel提供说明:
存储管理Flannel可分配的IP地址段资源
监控ETCD中每个Pod的实际地址。并在内存中建立Pod节点路由表。
不同情况下网络通信方式
同一个Pod内部通讯。同一个Pod共享同一个网络命名空间。共享同一个Linux协议栈。
Pod1至Pod2
Pod1与Pod2不在同一台主机,Pod的地址是与docker0在同一个网段的,但docker0网段与宿主机网卡是两个完全不同的IP网段。并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP关联起来。通过这个关联让Pod可以互相访问。
Pod1与Pod2在同一台机器。由Docker0 网桥直接转发请求至Pod2,不需要经过Flannel
Pod至Service的网络。目前基于性能考虑。全部为iptables维护和转发。
Pod到外网。Pod向外网发送请求。查找路由表。转发数据包到宿主机的网卡,宿主网卡完全完成路由选择后。iptables执行Masquerade,把源IP更改为宿主网卡的IP,然后向外网服务器发送请求。
外网访问Pod: Service
前期准备
Harbor是一个私有镜像仓库
1。安装k8s的节点必须是大于1核心的CPU
2。安装节点的网络信息 192.168.66.0/24 10 20 21
3。koolshare软路由的默认密码是koolshare
集群安装
如图
调整内核参数
关闭ipv6
都是优化方案
调整系统时区
设置rsyslogd和systemd journald
升级系统内核为4.44
kube-proxy开启ipvs的前置条件,安装docker
安装kubeadm
初始化主节点