K8S-基本介绍和集群安装

介绍

基本介绍

Kubernetes 是一个轻便的和可扩展的开源平台， 用于管理容器化应用和服务。 通过Kubernetes 能够进行应用的自动化部署和扩缩容。

谷歌用Go语言重写了borg组件成为我们的kubernetes。

发展经历

基础设施级服务 iaas :阿里云

平台设施级服务 paas :新浪云

软件设施级服务 saas :Office365

资源管理器：

前生：

Apache：MESOS - 分布式系统内核 、分布式资源管理框架 2019-05 Twitter>k8s

docker：SWARM 集群，轻量 2019-07 阿里云宣布 Docker Swarm集群框架从阿里云选择框架剔除

今世：

google：kubernetes，10年google容器基础框架borg ，容器火了以后，Google使用GO语言参考Borg设计思路开发出K8s

特点：轻量级，基于GO语言，消耗资源小

开源

弹性伸缩

负载均衡：LVS(IPVS)

功能

1. 自动装箱

   基于容器对应用运行环境的资源配置要求自动部署应用容器

2. 自我修复(自愈能力)
   当容器失败时， 会对容器进行重启
   当所部署的 Node 节点有问题时， 会对容器进行重新部署和重新调度
   当容器未通过监控检查时， 会关闭此容器直到容器正常运行时， 才会对外提供服务

3. 水平扩展
   通过简单的命令、 用户 UI 界面或基于 CPU 等资源使用情况， 对应用容器进行规模扩大或规模剪裁

4. 服务发现
   用户不需使用额外的服务发现机制， 就能够基于 Kubernetes 自身能力实现服务发现和负载均衡

5. 滚动更新
   可以根据应用的变化， 对应用容器运行的应用， 进行一次性或批量式更新

6. 版本回退
   可以根据应用部署情况， 对应用容器运行的应用， 进行历史版本即时回退

7. 密钥和配置管理
   在不需要重新构建镜像的情况下， 可以部署和更新密钥和应用配置， 类似热部署。

8. 存储编排
   自动实现存储系统挂载及应用， 特别对有状态应用实现数据持久化非常重要，存储系统可以来自于本地目录、 网络存储(NFS、 Gluster、 Ceph 等)、 公共云存储服务

9. 批处理
   提供一次性任务， 定时任务； 满足批量数据处理和分析的场景

架构图

主要组件：

1. api server：所有服务访问统一入口，所有的组件都只和APIServer交互，除此之外并不两两交互。提供认证、授权、访问控制、API注册和发现等机制
2. Scheduler: 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
3. controller manager(replication controller 等)：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
4. etcd：储存K8S集群所有重要信息(持久化)。比如：①apiserver接收到pod的创建命令后，会将构建的完整pod信息存储到etcd中；②etcd存储了每一个svc的endpoint对象，用来记录一个svc对应的所有pod的访问地址；
5. Kubelet：直接跟容器引擎交互实现容器的生命周期管理；
6. Kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡，负责写入规则至 IPTABLES、IPVS 实现服务映射访问的。

master节点的主要主组件就是apiserver、etcd、controller、scheduler。每一个执行节点node中都有一个kubelet，kube proxy，和一个或多个pod。 pod是最小部署单位，是一组容器的集合。

master节点是不会被分配Pod的，因为master节点中默认存在一个污点：node-role.kubernetes.io/master:NoSchedule。

重要插件：

1. CoreDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
2. Dashboard：提供一种B/S GUI的方式对集群资源进行管理，可以获取运行在集群中的应用的信息，也可以创建或者修改 Kubernetes 资源 （如 Deployment，Job，DaemonSet 等等）
3. Ingress Controller：为服务提供外网入口，对外提供服务的方式之一
4. Federation：提供一 个可以跨集群中心多K8S统一管理功能
5. Prometheus：提供资源监控
6. elk：提供集群日志采集、存储与查询
7. Flannel：是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP 地址之间建立一个覆盖网络(Overlay Network) ，通过这个覆盖网络，将数据包原封不动地传递到目标容器内

推荐在 Kubernetes 集群中使用 Etcd v3，v2 版本已在 Kubernetes v1.11 中弃用。etcd 的官方将它定位成一个可信赖的分布式键值存储服务,它能够为整个分布式集群存储一些关键数据,协助分布式集群的正常运转：

Pod

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元，一个node可以有多个Pod。

Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器， 这些容器相对紧密地耦合在一起。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。

Pod可以分为：自主式Pod(不是控制器控制的pod, 死了没人拉起来)，控制器管理的Pod。

自主式Pod：（不是被控制器管理的Pod）：死亡后不会被拉起来，也不会有人创建新的Pod：

每个Pod里运行着一个特殊的被称为Pause容器，其他容器为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交互更为高效。

在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中，同一个Pod里的容器之间仅需通过localhost就能互相通信。

控制器管理的Pod类型：

（1）ReplicationController(RC)

ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。在新版本的Kubernetes 中建议使用RepliicaSet来取代ReplicationControlle。

（2）ReplicaSet(RS)

ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector。虽然ReplicaSet 可以独立使用，但一般还是建议使用Deployment 来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题(比如ReplicaSet不支持rolling update但Deployment 支持)。

(3) Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法,用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括:

• 定义 Deployment 来创建 Pod 和 ReplicaSet
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续 Deployment

滚动更新：

更新V1到V2，新建个RS然后创建1个V2，删除1个V1：

直至：

达到滚动更新，此时RS，停用、保留，可以回滚：

（4）Horizontal Pod Autoscaling(HPA)

HPA根据利用率平滑扩展，仅适用于Deployment 和ReplicaSet ，在V1版本中仅支持根据Pod的CPU利用率扩所容，在vlalpha 版本中，支持根据内存和用户自定义的metric扩缩容。

HPA基于RS定义，并且监控V2Pod的资源利用率：

当符合条件后，会创建Pod：

每次创建后判断条件，符合后继续创建，直到最大值。使用率小就回收，直到最小值，实现水平自动扩展（弹性伸缩）。

（5）StatefulSet

StatefulSet是为了解决有状态服务的问题(对应Deployments 和Repl icaSets是为无状态服务而设计)，其应用场景包括:

• 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
• 稳定的网络标志，即Pod重新调度后其PodName 和HostName 不变，基于Headless Service(即没有Cluster IP的Service )来实现
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候**要依据定义的顺序依次依次进行(**即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running 和Ready状态)，基于init containers来实现
• 有序收缩，有序删除(即从N-1到0)

（6）DaemonSet

DaemonSet确保全部(或者一些) Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet 将会删除它创建的所有Pod。使用DaemonSet的–些典型用法:

• 运行集群存储daemon, 例如在每个Node上运行glusterd、 ceph；
• 在每个Node上运行日志收集daemon, 例如fluentd、 logstash；
• 在每个Node上运行监控daemon, 例如Prometheus Node Exporter。

（7）Job，Cronjob

job负责批处理任务，即仅执行一次的任务，他保证批处理任务的一个或者多个Pod成功结束。（比如要备份数据库，备份代码可以放到统一Pod里，再放到Job里执行，与Linux直接运行不同点是是封装好的Job可以重复利用，并且脚本执行异常退出可以重复执行，并且可以设置正常退出次数才算Job执行成功）

Cronjob管理基于时间的Job，即在给定时间点运行一次或周期性地在给定时间点运行

(8)　服务发现

Client访问service的IP和端口，使用RR（Round ribbon轮训）等算法间接访问到Pod。

网络通讯方式-Flannel

Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE (Google Compute Engine)里面是现成的网络模型，Kubernetes 假定这个网络已经存在。而在私有云里搭建Kubernetes 集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker 容器之间的互相访问先打通，然后运行Kubernetes。

• 同Service下的pod可以直接根据PodIP相互通信
• 不同Service下的pod在集群间pod通信要借助于 cluster ip
• pod和集群外通信，要借助于node ip

Flannel是CoreOS 团队针对Kubernetes 设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP 地址之间建立一个覆盖网络(Overlay Network) ，通过这个覆盖网络，将数据包原封不动地传递到目标容器内。

ETCD之Flannel 提供说明:

• 存储管理Flannel 可分配的IP地址段资源
• 监控ETCD中每个Pod 的实际地址，并在内存中建立维护Pod 节点路由表

网络通讯过程：

• 同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux 协议栈

• Pod1至Pod2，分两种情况：

  • Pod1 与Pod2在同一台机器。由Docker0 网桥直接转发请求至Pod2, 不需要经过Flannel
  • Pod1 与Pod2不在同一台主机。Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且环同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问

• Pod至Service 的网络：

  • 目前基于性能考虑，全部为iptables维护和转发Pod到外网:
  • Pod 向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade,把源IP更改为宿主网卡的IP,然后向外网服务器发送请求
  • 外网访问Pod: Service

只有节点网络是真实网络(只需一张网卡就可实现)。

Flannel细节可以参考： https://www.cnblogs.com/centos-python/articles/10874350.html

集群安装

整体架构如下

👉K8S构建1台master2台node+Harbor - 一代肝帝 - 博客园 (cnblogs.com)

👉 从零开始搭建K8S集群_xybDIY的博客-CSDN博客_如何搭建k8s集群