参考链接：
https://blog.csdn.net/zkkzpp258/article/details/86541362
https://blog.csdn.net/Bubbler_726/article/details/85596418
https://blog.csdn.net/wx_15323880413/article/details/100516698

Kubernetes（k8s）学习笔记

在这里插入图片描述

发展经历

云计算交互标准（云服务分类）：

比如：

Infrastructure as a Service( IaaS 基础设施服务) 例如：阿里云、AWS
Platform as a Service( PaaS 平台服务) 例如：新浪云
Softwate as a Service( SaaS 软件设施服务) 例如：office365

区别：

在这里插入图片描述

请设想你是一个餐饮业者，打算做披萨生意。

方案1：IaaS：
他人提供厨房、炉子、煤气，你使用这些基础设施，来烤你的披萨。
IaaS 是云服务的最底层，主要提供一些基础资源。它与 PaaS 的区别是，用户需要自己控制底层，实现基础设施的使用逻辑。

方案2：PaaS
除了基础设施，他人还提供披萨饼皮。
你只要把自己的配料洒在饼皮上，让他帮你烤出来就行了。也就是说，你要做的就是设计披萨的味道（海鲜披萨或者鸡肉披萨），他人提供平台服务，让你把自己的设计实现。
PaaS 提供软件部署平台（runtime），抽象掉了硬件和操作系统细节，可以无缝地扩展（scaling）。开发者只需要关注自己的业务逻辑，不需要关注底层。

方案3：SaaS
他人直接做好了披萨，不用你的介入，到手的就是一个成品。你要做的就是把它卖出去，最多再包装一下，印上你自己的 Logo。
SaaS 是软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。

所以，对于自己的工作量(下图蓝色)：IaaS>PaaS>SaaS

在这里插入图片描述

公有云、私有云、混合云

公有云：
什么是公有云呢？设想一个场面，如果你制作了一个网站（代理+应用服务器+数据库），一般来说，都是只可以在本机装个tomcat,mysql等等进行调试，你使用的ip就是localhost，这种Web，一般称之为单机的服务。如果你想让别人也访问你的网页，当然是要把机器接入到Internet上。但是目前你完全不具备购买一台Web服务器的能力，这时候怎么办呢？没关系，你可以购买一台虚拟的云服务器。这台云服务器本身已经具备了一个公网的ip，如果你把服务部署在这台服务器上，那么它的localhost就是这个公网的ip了，你和你的朋友可以在随时随地访问了。因此，公有云的概念简单理解就是申请一台接入Internet的云主机，你可以对其随便搞（装系统、装应用、开关机），你只需要购买一个使用的类似租赁的费用，而并不需要购买它。

这里，你申请的“机器”，可能是一台虚拟机，也可能是一些容器，对于这些容器，一般称它们为“实例”。当代的互联网公司，在进行服务部署的时候，往往会选择部署实例而非虚拟机，至于为什么，可以参考虚拟机和容器的区别的文章。选用实例，是因为实例的部署是秒级的（虚拟机是分钟级别的），而且实例是APP层面的封装，更小更轻便，是对硬件的更有效地利用。

私有云：
私有云是为了解决安全问题的一种云计算方案。虽然公有云很方便，但是毕竟是把数据和资源都交给其它人了，这对于企业管理来说，是一个很大的隐患。毕竟，很多数据是无价的，很多企业把用户数据作为他们的灵魂支柱。因此，当今的企业常常不希望把数据和资源部署到公有云上，他们往往会自己出资搭建机房，这时的解决方案，就是私有云方案。私有云比起公有云，更加安全，但是，成本也更高。

混合云：
混合云是在成本和安全方面的一种折中方案。顾名思义，就是公有云和私有云的结合。数据依然是存到本地的机器上，但是一旦出现大规模的访问或者计算时，就会把这部分计算的需求转移到公有云平台上，实现不同场景的切换。与此同时，在混合云方案中，私有云还常常把公有云作为灾难恢复和灾难转移的平台。混合云在使用起来具有更高的灵活性，是企业在考虑成本效益下的首选方案。

如前文所述，混合云客户一般已经具备了私有云，希望通过对接公有云解决几方面的典型需求：

跨国：某大型公司在美国销售电子类产品，需要在美国连接该企业的销售系统，通过本地私有云加AWS公有云实现；
灾备：将一部分系统或者数据定期备份到公有云上；
性能和高可用：利用公有云的CDN、全局负载均衡等能力提供更好可用性和性能；
爆发：客户业务需要短时爆发（bursting），满足业务需求同时节省成本。

混合云供应商主要包含：公有云提供商提供混合云能力、私有云供应商提供混合云能力、混合云创新企业等。

历程

MESOS Apache下的分布式资源管理框架在2019.5，最大使用者Twitter放弃MESOS，转型Kubernetes。

Docker Swarm Docker母公司为Docker开发的分布式资源管理框架在2019.7，阿里云宣布，将Docker Swarm从阿里云的选择列表中剔除。

Kubernetes Google公司 10年容器化基础架构采用Go语言对自己的borg系统进程翻写 ----> Kubernetes

Kubernetes特点

轻量级：消耗资源小
开源
弹性伸缩
负载均衡: IPVS

组件说明

K8S架构

在这里插入图片描述

scheduler：调度器，负责介绍任务，选择合适的节点进行分配任务。scheduler会将任务交给api server，之后api server将任务请求写入etcd。也就是说scheduler与etcd并不会直接交互。
replication controller：控制器，维护副本数目（维护期望值），比如说如果副本数目不满足我们的期望值，RC需要根据期望值增加或者删除Pod。
api server：服务访问入口
etcd：CoreOS公司用Go语言编写的开源键值对数据库，官网定义为一个可信赖的分布式键值存储服务，作为k8s集群的持久化方案。它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。存储K8S集群所以重要信息（持久化）。
注： ETCD分为V2和V3两个版本，V2是将数据存储在内存，V3增加了数据持久化到磁盘。推荐Kubernetes集群中使用V3，V2已经在Kubernetes v1.11 中弃用。

Node节点：

kubelet： kubelet会与CRI(Container Runtime Interface 容器运行时接口，如果使用Docker，这里就是Docker的表现形式)，kuberlet回和Docker交互，操作Docker去创建对应容器。也就是说，Kubelet直接跟容器引擎交互，维护Pod的生命周期。
kube proxy：负责写入规则至IPTABLES、IPVS，实现服务映射访问。

其他插件

CoreDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
Dashboard：给K8S集群提供一个B/S结构的访问体系
Ingress Controller：官方的Kubernetes只能实现四层代理，Ingress 可以实现七层代理。
Federation：提供一个可以跨集群中心多K8S统一管理的功能。
Prometheus：提供K8S集群的监控能力。
ELK：提供K8S集群日志统一分析介入平台。

Pod

在这里插入图片描述

当启动一个Pod时，pod会启动第一个容器pause，pod中容器之间会共用pause的网络栈和存储卷。也就是说如果nignx想访问php，ip只需要写loaclhost即可。

Pod的类型

自主式Pod
控制器管理的Pod

Pod控制器类型

ReplicationController & ReplicaSet & Deployment
- HPA（HorizontalPodAutoScale）
StatefullSet
DaemonSet
Job，Cronjob

ReplicationController & ReplicaSet & Deployment

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

ReplicaSet 和 ReplicationController 没有本质的不同，只是名字不一样，而且ReplicaSet支持集合式的selector

虽然 ReplicaSet 可以独立使用，但是一般还是建议使用Deployment来自动管理ReplicaSet ，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持rolling-update 但 Deployment支持）

HPA（HorizontalPodAutoScale）

Horizontal Pod AutoScaling 仅适用于 Deployment 和 ReplicaSet ，在v1版本中仅支持根据Pod的CPU利用率扩缩容，在vlalpha版本中，支持根据内存和用户自定义的metric 扩缩容。

StatefullSet

StatefullSet 是为了解决有状态服务的问题（对应Deployments 和 ReplicaSets 视为无状态服务设计），其应用场景包括：

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

DaemonSet

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

是有DaemonSet 的一些典型用法：

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

Job，Cronjob

Job 复制批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。

Cron Job 管理基于时间的Job，即：

在给定时间点只运行一次
周期性地在给定时间点运行

网络通讯模式

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

Pod网络通讯类型

同一个Pod内多个容器之间：pause服务，通过loaclhost即可访问
各Pod之间的通讯：Overlay Network
Pod 与 Service 之间的通讯：各节点的Iptables规则，最新版本中加入了LVS

网络解决方案 Kubernetes+Flannel （常用）

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

在这里插入图片描述