kubernetes简介

kubernetes简介

Kubernetes基础

Pod是什么？

Pod是Kubernetes中能够创建和部署（运行）的最小逻辑单元（原子单元），是Kubernetes集群中的一个应用实例，总是部署在同一个节点Node上。Pod中包含了一个或多个容器，还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境，Docker则是最流行的容器环境。

• 单容器Pod，最常见的应用方式。
• 多容器Pod，对于多容器Pod，Kubernetes会保证所有的容器都在同一台物理主机或虚拟主机中运行。多容器Pod是相对高阶的使用方式，除非应用耦合特别严重，一般不推荐使用这种方式。一个Pod内的容器共享IP地址和端口范围，容器之间可以通过 localhost 互相访问。
  

Pod并不提供保证正常运行的能力，因为可能遭受Node节点的物理故障、网络分区等等的影响，整体的高可用是Kubernetes集群通过在集群内调度Node来实现的。通常情况下我们不要直接创建Pod，一般都是通过Controller来进行管理，但是了解Pod对于我们熟悉控制器非常有好处。

Pod的作用

• Pod做为一个可以独立运行的服务单元，简化了应用部署的难度，以更高的抽象层次为应用部署管提供了极大的方便。
• Pod做为最小的应用实例可以独立运行，因此可以方便的进行部署、水平扩展和收缩、方便进行调度管理与资源的分配。
• Pod中的容器共享相同的数据和网络地址空间，Pod之间也进行了统一的资源管理与分配。

Pod控制器

Pod控制器是Pod启动的一种模板，用来保证在k8s里启动的Pod应始终按照人们的预期运行（副本数、生命周期、健康状态检查…）

k8s内提供了众多的Pod控制器，常用的有：

• Deployment
• DaemonSet
• ReplicaSet
• StatefulSet
• Job
• Cronjob

Label

标签（Label）是附加在Kubernetes对象上的一组名值对，其意图是按照对用户有意义的方式来标识Kubernetes对象，同时，又不对Kubernetes的核心逻辑产生影响。标签可以用来组织和选择一组Kubernetes对象。您可以在创建Kubernetes对象时为其添加标签，也可以在创建以后再为其添加标签。每个Kubernetes对象可以有多个标签，同一个对象的标签的 Key 必须唯一

• 标签是k8s特色的管理方式，便于分类管理资源对象。
• 一个标签可以对应多个资源，一个资源也可以有多个标签，他们是多对多的关系。
• 一个资源拥有多个标签，可以实现不同维度的管理
• 标签的组成：key=value
• 与标签类似的还有一种“注解”（annotations）

为什么要用Label

使用标签，用户可以按照自己期望的形式组织 Kubernetes 对象之间的结构，而无需对 Kubernetes 有任何修改。

应用程序的部署或者批处理程序的部署通常都是多维度的（例如，多个高可用分区、多个程序版本、多个微服务分层）。管理这些对象时，很多时候要针对某一个维度的条件做整体操作，例如，将某个版本的程序整体删除，这种情况下，如果用户能够事先规划好标签的使用，再通过标签进行选择，就会非常地便捷。

Label选择器

与 name 和 UID 不同，标签不一定是唯一的。通常来讲，会有多个Kubernetes对象包含相同的标签。通过使用标签选择器（label selector），用户/客户端可以选择一组对象。标签选择器（label selector）是 Kubernetes 中最主要的分类和筛选手段。

Kubernetes api server支持两种形式的标签选择器，equality-based 基于等式的 和 set-based 基于集合的。标签选择器可以包含多个条件，并使用逗号分隔，此时只有满足所有条件的 Kubernetes 对象才会被选中。

如果使用空的标签选择器或者不指定选择器，其含义由具体的 API 接口决定。

• 给资源打上标签后，可以使用标签选择器过滤指定的标签
• 标签选择器目前有两个：基于等值关系（等于、不等于）和基于集合关系（属于、不属于、存在）

Node

Node（节点）是k8s集群中相对于Master而言的工作主机。Node可以是一台物理主机，也可以是一台虚拟机（VM）。
在每个Node上运行用于启动和管理Pid的服务Kubelet，并能够被Master管理。
在Node上运行的服务进行包括Kubelet、kube-proxy和docker daemon。

Kubernetes集群架构

一个k8s集群包含两个部分：

• master：主控节点
• node：worker节点（工作节点）

master

master本身是不做任何事情的，只提供一些调度等做用，负责管理Node, 控制Node 具体运行什么容器, 同时还承担外部数据访问的角色

master分为三个组件：

• API server：提供认证，授权，访问控制，API注册，发现等机制

• controller-manager：做集群中后台的统一的管理，处理集群中常规的任务，比如：故障检测、自动扩展、滚动更新。

• scheduler：选择合适的node节点来部署，起到节点调度的作用。

• etcd：算不上是组件，算是一个数据库，用来存储集群当中各种的资源，可以部署在任何能够访问到的地方

node（worker节点）

node分为两个组件：

kubelet：master派到node节点的代表，管理本机容器的各种操作

kube-proxy：实现Pod的网络代理，用来做服务发现、负载均衡。

Docker Engin：docker引擎, 负责Node于和容器有关的操作, K8S原生支持Docker作为容器引擎, 如果要使用其他容器引擎则需要使用对应接口集成

Pod：K8S不是直接运行的容器,而是操作Pod, 把Pod作为原子单元管理,一个Pod里面可能会运行多个容器, Pod里面运行的多个容器被捆绑在一起被统一调度不可分割. 一个Pod的所有容器只能同时运行在一个Node 上

Kubernetes的特性

Kubernetes的特性主要有以下几种：

• 自动化
  kubernetes有一套自动化机制。可以降低整个集群的运维成本和运维难度
  通过K8s我们可以实现自动扩容、自动更新、自动部署、自动化管理资源等等。
• 以服务为中心
  kubernetes以服务为中心，可以让我们抛开系统环境和运行细节，有更多精力去处理逻辑业务。
  构建在kubernetes上的系统，可以独立运行在物理机、虚拟机、私有云以及公有云。
• 高可用
  kubernetes会定期进行检查应用实例，这包括对这些实例的数量检查，实例健康状态检查等等。
  kubernetes如果发现有新的应用实例启动，会自动加入负载均衡中。
  kubernetes如果发现有应用实例状态不可用。kubernetes会自动干掉这个问题实例，并重新调度一个新实例。
• 滚动更新
  kubernetes可以使整个集群平滑升级（rolling-update），就是说，kubernetes可以在不停止对外服务的前提下完成应用的更新。在规模比较大的集群中，kubernetes这一特性会非常实用。

pod分类

自主式pod

（由kubelet（服务）启动来管理，控制pod）
（就是在本机自己创建一个pod，这个pod有kubelet服务来控制，如果这个pod发生了故障，这个pod就会消失，自给自足，所以不推荐这种pod）

控制器管理的pod

常见的pod控制器

• ReplicationContriller（副本控制器） 当启动一个pod时，这个pod如果不够用可以再启一个副本，而后由控制器来管理同一类pod的各种副本与对象。一旦副本少了就会自动增加。采取多退少补的规则，精确符合我们所定义的期望。支持滚动更新
  （例如我们定义一个需求，5个 多了就干掉，少了就补上，精确匹配5个）

• ReplicaSet 由一个名叫Deployment的声明式更新的控制器来管理
  声明式就是我先声明启动一个什么pod再去启动，需要写入一个文件

• Deployment（部署）只能管理无状态(无数据)的应用

• StateFulSet 有状态副本集，可以管理有状态的应用

• DaemonSet 如果需要在每个node运行一个副本的时候可以用DaemonSet
  使每个node上运行pod（比如有三个节点，每个节点上需要运行一个一模一样的pod，可以保证每个都有）

• Job （定义一个任务类型）

• Cronjob（定时任务）

• 以上每种控制器都是来实现一种特定的应用管理的。

核心组件

HPA

HAP （水平pod自动伸缩控制器）
（一般情况下我们可以确保一个node上有2个pod在运行，万一用户访问流量正价，2个pod不足以承载这么多访问量怎么办，此时我们就应该要增加pod资源，那么要怎加几个呢？）
HPA控制器可以执行的监控pod，自动进行扩展（过程不需要人为干预）

service

pod挂掉之后,主机名和IP地址都会发生改变,但是service没有发生改变,他们是通过service来进行通讯的,pod创建出来后会在service上通报一声,并告诉他自己的ip和主机名

​ pod是有生命周期的，一个pod随时都有可能离去，随时都有可能会有其他pod加进来，假如它提供的是同一种服务，客户端是无法通过固定的手段来访问这些pod的，因为pod本身是不固定的，它们随时可能被替换掉， 无论使用主机名还是IP地址，都随时会被替换掉。

为了尽可能的降低客户端与pod间协调的复杂度，k8s为每一组提供同类服务的pod和其客户端之间添加了一个中间层，这个中间层是固定的，这个中间层就叫service

service只要不被删除，其地址与名称皆是固定的，当客户端需要在其配置文件中写上访问某个服务时，它不再需要自动发现，只需要在配置文件中写明service的名称即可，而这个service是个调度器，其不但能够提供一个稳定的访问入口，还可以做反向代理，当service接收到客户端的请求后，会将其代理到后端的pod之上，一旦pod宕机了会立即新建一个pod,这个新建的pod会立即被service关联上，作为service后端的可用pod之一

客户端程序访问服务都是通过IP+端口或者主机名+端口的方式来实现的。而service关联后端的pod不是靠它的IP和主机名，而是靠pod的标签选择器。只要创建的pod的labe是统-的，无论IP地址和主机如何改变，其都能被service所识别。如此来，只要pod属于标签选择器，只要其在service的管理范围之内，则其就会被关联到service中，当这个动态的pod关联到service中之后，再进行动态的探测此pod的IP地址、端口，再将其作为自己后端可调度的可用服务器主机对象。因此，客户端的请求发送到service,然后由service代理到后端真实的pod中的容器进行响应。

service不是一个程序，也不是一个组件，它只是一个iptables的dnat(目标ip的)规则

service作为k8s的对象，有其自身的名称，而service的名称相当于服务的名称，而这个名称可以被解析。

AddOns附件

dnf pod

装完k8s后第一件事就需要在k8s集群上部署一个dns pod,以确保各service的名称能够被解析，可以动态改变，包括动态创建、动态删除、动态修改

比如把service的名称改了，dnspod会自动触发，将dns解析记录中的名称也给改掉;假如我们手动把service的ip地址给改了，改完以后会自动触发，将dns服务中的解析记录给改掉。
如此来，客户端去访问pod资源的时候可以直接访问service的名称，然后由集群中专用的dns服务来负责解析。

这种pod是k8s自身的服务就需要用到的pod,所以我们把它称为基础性的系统架构级的pod对象，而且它们也被称为集群附件

k8s网络模型

节点网络
service集群网络
pod网络

同节点Pod之间的通信

在容器启动前，会为容器创建一个虚拟Ethernet接口对，这个接口对类似于管道的两端，其中一端在主机命名空间中，另外一端在容器命名空间中，并命名为eth0。在主机命名空间的接口会绑定到网桥。网桥的地址段会取IP赋值给容器的eth0接口。

不同节点上的Pod通信

我们已经知道一个节点上的容器都会连接到同一网桥，因此要让运行在不同节点上的容器之间能够通信，这些节点的网桥就需要以某种方式连接起来。
跨整个集群的Pod的IP地址必须是唯一的，所有跨节点的网桥必须使用不重叠的网络地址段，以防止不同节点上的Pod拿到同一IP地址，即确保没有IP地址冲突。

Pod与Service

在不同节点上的Pod通信中，我们知道了Pod是以IP地址进行通信，但Kubernetes 的集群中， Pod 可能会频繁的销毁和创建，也就是说 Pod 的 IP 不是固定的。
为了解决这个问题，Service 提供了访问 Pod 的抽象层，即为一组功能相同的Pod提供单一不变的接入点资源。
无论后端的 Pod 如何变化，Service 都作为稳定的前端对外提供服务。
同时，Service 还提供了高可用和负载均衡功能，Service 负责将请求转发给正确的 Pod。

Calico

Calico是Kubernetes生态系统中另一种流行的网络选择，它提供收费的技术支持。虽然Flannel被公认为是最简单的选择，但Calico以其性能、灵活性而闻名。Calico的功能更为全面，更为复杂。它不仅提供主机和pod之间的网络连接，还涉及网络安全和管理。Calico CNI插件在CNI框架内封装了Calico的功能。
在一个新配置的Kubernetes集群上，用户可以通过应用单个manifest文件快速部署Calico。与Flannel不同，Calico不使用overlay网络。相反，Calico配置第3层网络，该网络使用BGP路由协议（边界网关协议，用于管理边缘路由器之间数据包的路由方式）在主机之间路由数据包。这意味着在主机之间移动时，不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包，而无需额外在流量层中打包流量。
在Calico插件中，用户可以自定义网络规则，提高安全性并控制网络环境。因此，如果在你的应用场景中，对于网络的控制要求严格，那Calico应该会是你的首选。
https://github.com/projectcalico/cni-plugin

Flannel

Flannel是由CoreOS开发的项目，是容器编排系统中最成熟的网络结构示例之一，旨在实现更好的容器间和主机间网络。

与其他方案相比，Flannel相对容易安装和配置。它被打包为单个二进制文件flanneld，许多常见的Kubernetes集群部署工具和许多Kubernetes发行版都可以默认安装Flannel。Flannel可以使用Kubernetes集群的现有etcd集群来使用API存储其状态信息，因此不需要专用的数据存储。

总的来说，Flannel是大多数用户的不错选择。从管理角度来看，它提供了一个简单的网络模型，用户只需要一些基础知识，就可以设置适合大多数用例的环境。一般来说，在初期使用Flannel是一个稳妥安全的选择，直到你开始需要一些它无法提供的东西。

详细参考 https://github.com/coreos/flannel