[toc]

学习K8S参考网站

官网：TP

官方文档：TP

官方介绍：TP

kubeadm官方文档：TP

docker官方文档：TP

prometheus官方文档：TP

ansible安装k8s项目：TP

阿里云K8S产品ACK：TP

aws亚马逊云K8S产品EKS：TP

腾讯云K8S产品TKE：TP

什么是k8s

多机编排工具
- borg(最早期)
- swarm(docker官方)
- mesos
- k8s(最强大)

声明式管理

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上，结合了社区中最优秀的想法和实践。

时光回溯

传统部署时代：

早期，各个组织是在物理服务器上运行应用程序。由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。例如，如果在同一台物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。一种解决方案是将每个应用程序都运行在不同的物理服务器上，但是当某个应用程式资源利用率不高时，剩余资源无法被分配给其他应用程式，而且维护许多物理服务器的成本很高。

虚拟化部署时代：

因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性，因为一个应用程序的信息不能被另一应用程序随意访问。

虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序，而因此可以具有更高的可扩缩性，以及降低硬件成本等等的好处。通过虚拟化，你可以将一组物理资源呈现为可丢弃的虚拟机集群。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代：

容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。因此，容器比起 VM 被认为是更轻量级的。且与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。

308状态码：容器切换

K8S组件介绍（7个）

Master ，已改名为：Control Plane Components（控制平面组件）

apiserver：
- 所有组件的入口（接口），所有组件，想要调用其他组件，都需要APIserver
ETCD：
- 存储所有组件产生的数据（爸爸）
scheduler：
- 资源计算，资源调度
controller：
- 控制组件,控制客户端创建容器

Node

kubelet：
- 控制”容器运行时”的组件
proxy：
- 网络组件（管理端口映射网络模式）
容器运行时（Container Runtime）：
- 运行容器的软件，如：docker 、containerd、 CRI-O

K8S架构

单机节点

k8s高可用集群

master + nginx + keepalived

master + haproxy + keepalived

POD创建流程

K8S的核心资源

POD

什么是POD?

K8S中的最小单位
POD的IP地址是随机的，删除POD会改变IP
POD都会有一个根容器pause
一个Pod内可以由一个容器或多个容器组成
一个Pod内的容器共享根容器的网络、名称空间、和文件系统卷
一个Pod内的网络地址由根容器提供

POD运行状态

状态	描述
Pending（等待）	Pod已经被K8S系统接受，但是有一个或多个容器，尚未创建，亦未运行。此阶段包括等待Pod被调度的时间和通过网络下载镜像的时间
Running（运行）	Pod已经绑定到某个节点(node)，Pod中所有容器都已被创建，至少有一个容器仍在运行，或者处于启动或重启状态
Succeeded（成功）	Pod中所有容器都已成功终止，并且不会再重启
Failed（失败）	Pod中所有容器都已成功终止，并且有一个容器是因为失败而终止
Unknown（未知）	因为某些原因无法获取Pod状态，这种情况，通常是因为与Pod所在主机通信失败

Namespace名称空间资源

Namespace（名称空间）是K8S中非常重要的一个概念，Namespace将集群内部的资源进行隔离划分。
在Namespace中，形成逻辑上的不同项目组或用户组。

Controller控制器资源

RC Replication Controller
- 控制Pod起多个副本
RS ReplicaSet
- RC控制器的升级版
- 服务挂了自动启动，以满足指定数量服务
Deployment
- 推荐使用,功能强大,包含了RS控制器
- 支持版本更新
DaemonSet
- 保证所有的Node节点上，有且只有一个Pod运行
- 每台只起一个客户端软件
StatefulSet
- 有状态的应用，为Pod提供唯一标识，它可以保证部署和scale的顺序

Service网络资源

三种网络资源
- NodePort：宿主机上启动端口（端口映射），宿主机IP不变，固定一个映射的端口
- ClusterIP：类似于负载均衡，帮我们找到每一个POD(ClusterIP也会变动)
- POD IP：每一个POD都会有自己的IP地址(会变动)

Label标签

因为在K8S中，起的任何只要带IP的资源，那么IP地址都不是固定的，都会发生变化
所以各个资源之间进行通信，是不可能靠IP地址进行通信的
这就是Label出现的原因，有了标签，就可以给POD、ClusterIP等一系列有IP地址的资源，打标签，通过标签名称进行通信即可
Label标签是K8S中非常重要的一个属性，Label标签就像身份证一样，可以用来识别K8S的对象。
传统架构中，不同的服务应用之间通讯，都是通过IP和端口，但是在K8S中很多匹配关系都是通过标签来找。

POD和控制器（Controller）的关系

K8s网络插件

三种常用的网络插件

Flannel（https://github.com/flannel-io/flannel/）
- 由 CoreOS 公司（已被 Redhat 收购）开发，最早是一种 Overlay 模式的网络插件，使用 UDP 和 VXLAN 技术，后来又用 Host-Gateway 技术支持了 Route 模式。Flannel 简单易用，是 Kubernetes 里最流行的 CNI 插件，但它在性能方面表现不是太好，所以一般不建议在生产环境里使用。
Calico（https://github.com/projectcalico/calico）
- 是一种 Route 模式的网络插件，使用 BGP 协议（Border Gateway Protocol）来维护路由信息，性能要比 Flannel 好，而且支持多种网络策略，具备数据加密、安全隔离、流量整形等功能。
Cilium（https://github.com/cilium/cilium）
- 是一个比较新的网络插件，同时支持 Overlay 模式和 Route 模式，它的特点是深度使用了 Linux eBPF 技术，在内核层次操作网络数据，所以性能很高，可以灵活实现各种功能。在 2021 年它加入了 CNCF，成为了孵化项目，是非常有前途的 CNI 插件。

Flannel实现原理

集群中的不同节点上，创建的Pod具有全集群唯一的虚拟IP地址。
建立一个覆盖网络（overlay network），通过这个覆盖网络，将数据包原封不动的传递到目标容器。覆盖网络通过将一个分组封装在另一个分组内来将网络服务与底层基础设施分离。在将封装的数据包转发到端点后，将其解封装。
创建一个新的虚拟网卡flannel0接收docker网桥的数据，通过维护路由表，对接收到的数据进行封包和转发（vxlan）。
etcd保证了所有node上flanned所看到的配置是一致的。同时每个node上的flanned监听etcd上的数据变化，实时感知集群中node的变化。