K8S基础：概念知识

K8S基础：概念知识

一、什么是K8S？

1.是什么？

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

2.历史由来

在Docker 作为高级容器引擎快速发展的同时，Google也开始将自身在容器技术及集群方面的积累贡献出来。在Google内部，容器技术已经应用了很多年，Borg系统运行管理着成千上万的容器应用，在它的支持下，无论是谷歌搜索、Gmail还是谷歌地图，可以轻而易举地从庞大的数据中心中获取技术资源来支撑服务运行。

Borg是集群的管理器，在它的系统中，运行着众多集群，而每个集群可由成千上万的服务器联接组成，Borg每时每刻都在处理来自众多应用程序所提交的成百上千的Job, 对这些Job进行接收、调度、启动、停止、重启和监控。正如Borg论文中所说，Borg提供了3大好处:

1）隐藏资源管理和错误处理，用户仅需要关注应用的开发。

2) 服务高可用、高可靠。

3) 可将负载运行在由成千上万的机器联合而成的集群中。

2014年6月，谷歌云计算专家埃里克·布鲁尔（Eric Brewer）在旧金山的发布会为这款新的开源工具揭牌，它的名字Kubernetes在希腊语中意思是船长或领航员，这也恰好与它在容器集群管理中的作用吻合，即作为装载了集装箱（Container）的众多货船的指挥者，负担着全局调度和运行监控的职责。

Kubernetes项目来源于Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的经验和教训。

二、K8S集群组成

Kubernetes, 一般由Master和Worker Node组成，Master主要集群信息调度（人的脑），WorkerNode主要负责运行容器实例的运行（人的手脚）。

三、K8S集群基础服务组件

kubectl：用来与集群通信的命令行工具。

API Server：服务器为API对象验证和配置数据，这些对象包含Pod，Service，ReplicationController等等，API Server提供REST操作以及前端到集群的共享状态，所有其它组件可以通过这些共享状态交互。

kubelet：在集群中的每个节点上用来启动 Pod 和容器等。

kube-proxy：是管理 service 的访问入口，包括集群内 pod 到 service 的访问，以及集群外访问service。

四、名词解释：Node

Node是Pod真正运行的主机，可以物理机，也可以是虚拟机。为了管理Pod，每个Node节点上至少要运行container runtime（比如docker或者rkt）、kubelet和kube-proxy服务。

五、名词解释：Pod

在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod,Pod是最小的，管理，创建，计划的最小单元.

Pod: 是k8s集群的最小单元，一个pod可以包含一个或者多个container。

六、名词解释：Namespace

Namespace: 命名空间，用于将一个k8s集群隔离成不同的空间，pod, service, rc, volume 都可以在创建的时候指定其namespace。

七、名词解释：存储（PV/PVC/StorageClass）

Volume: 存储卷，pod对外暴露的共享目录，它可以挂载在宿主机上，这样就能让同node上多个pod共享一个目录。

Persistent Volume: 持久存储卷。之前说的volume是挂载在一个pod上的，多个pod(非同node)要共享一个网络存储，就需要使用持久存储卷，简称为pv。

八、名词解释：services

Service: 多个相同的pod组成一个服务，统一对外提供服务。

九、名词解释：网络（Ingress/Nodeport/LoadBalancer）

NodePort：服务是引导外部流量到你的服务的最原始方式。NodePort，正如这个名字所示，在所有节点（虚拟机）上开放一个特定端口，任何发送到该端口的流量都被转发到对应服务。

LoadBalancer：服务是暴露服务到 Internet 的标准方式。所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎可以发送任何种类的流量到该服务，像 HTTP，TCP，UDP，WebSocket，gRPC 或其它任意种类。

Ingress：可以给 Service 提供集群外部访问的 URL、负载均衡、SSL 终止、HTTP 路由等。为了配置这些 Ingress 规则，集群管理员需要部署一个 Ingress Controller，它监听 Ingress 和 Service 的变化，并根据规则配置负载均衡并提供访问入口。

十、K8S服务组件架构

Kubernetes主要由以下核心组件组成：

etcd保存了整个集群的状态；

apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；

Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；

kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

核心组件之外，推荐的Add-ons：

kube-dns负责为整个集群提供DNS服务

Ingress Controller为服务提供外网入口

Heapster提供资源监控

Dashboard提供GUI

Federation提供跨可用区的集群

Fluentd-elasticsearch提供集群日志采集、存储与查询

十一、K8S部署方式

Minikube：这是一个工具，可以在本地快速运行一个单点的Kubernetes，尝试Kubernetes或日常开发的用户使用。不能用于生产环境。

Kubeadm：也是一个工具，提供kubeadm init和kubeadm join，用于快速部署Kubernetes集群，可用于生产环境。

二进制：从官方下载发行版的二进制包，手动部署每个组件，组成Kubernetes集群，可用于生产环境。

二进制部署组件

Master：kube-apiserver，kube-controller-manager，kube-scheduler，kubelet，kube-proxy，docker，etcd，nginx，keepalived

Node：kubelet，kube-proxy，docker，etcd

十二、K8S Federation V2

1、好处

Kubernetes Federation(联邦)一直是很有趣的议题，并被重视的功能，Federation目的是希望实现单一集群统一管理多个Kubernetes集群的机制，这些集群可能是跨地区(Region)，也可能是在不同公有云供应商(Cloud Provider)上，亦或者是公司内部自行建立的集群。一但集群进行联邦后，就可以利用Federation API资源来统一管理多个集群的Kubernetes API资源，如定义Deployment如何部署到不同集群上，其集群所需的副本数等。

而Kubernetes Federation 的诞生正是希望利用联邦机制来解决一些问题，并达到一些好处，如以下：

l 简化管理多个集群的Kubernetes 组件(如Deployment, Service 等)。

l 在多个集群之间分散工作负载(容器)，以提升应用(服务)的可靠性。

l 跨集群的资源编排，依据编排策略在多个集群进行应用(服务)部署。

l 在不同集群中，能更快速更容易地迁移应用(服务)。

l 跨集群的服务发现，服务可以提供给当地存取，以降低延迟。

l 实践多云(Multi-cloud)或混合云(Hybird Cloud)的部署。

2、为什么V1会被弃用？

Federation v1在Kubernetes v1.3左右时，就已经着手设计( Design Proposal )，并在后面几个版本中发布了相关的组件与命令行工具(kubefed)，用于帮助使用者快速建立联邦集群，并在Kubernetes v1.6时，进入了Beta阶段。

但Federation v1 在进入Beta 后，就没有更进一步的发展，一直到Kubernetes v1.11 左右正式被弃用。至于为什么被弃用呢？这是因为开发团队认为集群联邦的实践比想象中还要困难，有许多问题是v1 架构没被考虑进去的，比如说：

l 控制平面组件会因为发生问题，而影响整体集群效率。

l 无法兼容新的Kubernetes API 资源。

l 无法有效的在多个集群管理权限，如不支持RBAC。

l 联邦层级的设定与策略依赖API 资源的Annotations 内容，这使得弹性不佳。

3、V2优势

Kubernetes Cluster Federation又名KubeFed或Federation v2，是Kubernetes SIG Multi-Cluster团队新提出的集群联邦架构( Architecture Doc与Brainstorming Doc )，新架构在Federation v1基础之上，简化扩展Federated API过程，并加强跨集群服务发现与编排的功能。另外KubeFed在设计之初，有两个最重要核心理念是KubeFed希望实现的，分别为Modularization（模块化）与Customizable(定制化)，这两个理念大概是希望KubeFed能够跟随着Kubernetes生态发展，并持续保持相容性与扩展性。

KubeFed在组件上最大改变是将API Server移除，并通过CRD机制来完成Federated Resources的扩充。而KubeFed Controller则管理这些CRD，并实现同步Resources、跨集群编排等功能。从架构图中看到，KubeFed提出了一些新概念来加强功能的扩展。

目前KubeFed 通过CRD 方式新增了四种API 群组来实现联邦机制的核心功能：

在Federation 中，会区分Host 与Member 两种类型集群。

l Host :用于提供KubeFed API与控制平面的集群。

l Member :通过KubeFed API注册的集群，并提供相关身份凭证来让KubeFed Controller能够存取集群。Host集群也可以作为Member被加入。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。