Kubernetes基础

Kubernetes基础

K8s介绍

首先，他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关 键特征：

• 拥有一个唯一指定的名字

• 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号

• 能够体统某种远程服务能力

• 被映射到了提供这种服务能力的一组容器应用上

Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程，虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内奸的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响我们队服务的正常调用，更重要的是这个Service本身一旦创建就不会发生变化，意味着在Kubernetes集群中，我们不用为了服务的IP地址的变化问题而头疼了。

容器提供了强大的隔离功能，所有有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label，比如运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器Label Selector，这样就能巧妙的解决了Service于Pod的关联问题。

在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

在Kubernetes集群中，它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个Replication Controller简称（RC），则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。

• 目标Pod的定义

• 目标Pod需要运行的副本数量（Replicas）

• 要监控的目标Pod标签（Label）

在创建好RC后，Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据RC中定义的Pod模板来创建一个新的Pod，然后将新Pod调度到合适的Node上启动运行，知道Pod实例的数量达到预定目标，这个过程完全是自动化。

Kubernetes优势:

• 容器编排

• 轻量级

• 开源

• 弹性伸缩

• 负载均衡

K8s特性

• 自我修复
  在节点故障时，重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

• 弹性伸缩
  使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用实例，保证应用业务高峰并发时的高可用性；业务低谷时回收资源，以最小成本运行服务。

• 自动部署与回滚
  K8S采用滚动更新应用，一次更新一个Pod，而不是同时删除所有的Pod，如果更新过程中出现问题，将回滚更改，确保升级不影响业务。

• 服务发现和负载均衡
  K8S为多个容器提供一个统一访问入口，并且负载均衡关联的所有容器，使得用户无需考虑容器IP网络问题。

• 机密和配置管理
  管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高安全性。并且可以将一些常用的配置存储在K8S当中，方便应用程序使用。
  容器化应用程序的最大问题在于我们配置容器内的应用程序比较困难。基于镜像启动一个容器后，如果期望容器中的应用程序换一个配置该怎么办呢?如果我们定义一个entrypoint的脚本，而这个脚本可以接受用户传入的变量参数，把变量的值转换为容器内的应用程序可读取的配置,从而能完成容器化应用程序的配置。

  之所以这么麻烦是因为早期的应用程序不是面向云原生而开发的，所以那些应用程序要通过读取配置文件来获取配置，而云原生开发的应用程序可以基于环境变量来获取配置。
  这种配置方式使得一个镜像能满足用户在不同环境下运行同一个镜像为不同配置的容器的需求。但是在编排工具当中，这种配置方式会存在一些问题,比如配置信息保存到哪里?如果我们用编排平台让容器启动自动化了，但每次启动容器时我们还要手工去传递环境变量的值,这是一个很麻烦的事,所以我们需要一个外部的组件保存这些配置信息于外部，当镜像启动为容器时，只需要让镜像去加载外部的配置中心中的配置信息，就能完成应用程序的配置。

• 存储编排
  挂载外部存储系统，无论是来自本地存储、公有云(AWS)、还是网络存储(NFS,Ceph,GFS)都作为集群资源的一部分使用，极大提高存储使用的灵活性。把存储卷实现动态供给，当容器需要存储卷时，根据容器自身的需求创建能够满足其需要的存储卷。

• 批处理
  提供一次性任务，定时任务，满足批量处理数据和分析场景。

K8s架构和组件

K8s就是一个组合多台主机的资源整合成一个大的资源池，并同意对外进行计算、存储等能力的集群。

架构示意图：

1.Master

k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程，关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程；Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心；Kubernetes Schedule是负责资源调度（Pod调度）的进程

• API Server ：负责接收并处理请求
• Scheduler： 调度容器创建的请求
• Controller： 确保已创建的容器处于健康状态
• Controller Manager： 确保后端节点上的控制器处于健康状态

2.Node

Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.

每个Node节点都运行着以下一组关键进程

kubelet：负责对Pod对于的容器的创建、启停等任务

kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件

Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作

Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会想master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，冰实现高效均衡的资源调度策略。、

kubelet

kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载Secret、获取容器节点状态工作。kubelet将每个Pod转换成一组容器。

kube-proxy

在node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作

docker或rocket

容器引擎，运行容器。

K8s专业术语

pod

pod是K8s的最小调度逻辑单元，pod可以理解为是容器的外壳,它为容器做了一层抽象的封装。pod内部主要是用来放容器的，pod的特点是可以将多个容器加入到同一个网络名称空间中，一个pod中可以包含多个容器，同一个pod中的不同容器可以共享存储卷。一个pod上无论是有一个容器还是有多个容器，一旦将此pod调度到某node上运行时，这一个pod内的所有容器只能运行在同一个node上。

运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

Pod其实有两种类型：普通Pod和静态Pod，后者比较特殊，它并不存在Kubernetes的etcd存储中，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动。普通Pod一旦被创建，就会被放入etcd存储中，随后会被Kubernetes Master调度到摸个具体的Node上进行绑定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器冰启动起来，在。在默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问起并且重启这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。

node

node是k8s集群中的工作节点,负责运行由master指派的各种任务。而最核心的任务就是以pod形式运行容器。

node可以是任何形式的计算设备，只要此设备上能够有传统意义上的CPU、内存、存储空间,并且能装上k8s的集群代理程序，它都可以作为整个k8s集群一个成员。

标签选择器

当大量的pod运行在一个集群当中时，如何实现分类管理?比如想删除某一类pod，比如想让控制器去管理一部分pod，它怎么进行管理?如何挑选、检测出来这些pod呢?值得肯定的是，这么多的pod，我们不能通过pod的名称来识别容器，因为pod随时都会被创建和删除，当一个pod发生故障被删除后，重新生成的pod的名称与被删除的pod名称肯定是不一样的,只不过其内部运行的程序是一样的，所以我们不能靠pod的名称来识别。同时我们有可能要将一类pod归组，比如创建4个nginx的pod,期望使用一个控制器对其进行统一管理，删除一个控制器就把这4个pod都删了，控制器还要保证这4个pod都处于运行状态，缺—个要补一个，多一个要多杀一个，精确符合我们期望的4个pod才行。

为了能够实现pod识别，需要在pod之上附加一些元数据，类似dockerfle中的label标签的方式，比如在创建pod时为其附加一个名为app的key，然后将其值设为nginx，那么当我们在批量进行pod调度管理时，可以检查pod中是否有app这个key，且其值是否为nginx，通过此种方法来识别pod是否是我们想要控制的pod。

标签是在k8s上管理大规模pod资源并且能够分类识别和管理的一个非常重要的途径。

那么怎么从众多的pod中筛选出我们想要的pod呢?

通过标签选择器组件我们可以实现这个功能标签选择器就是一种根据标签来过滤符合条件的资源对象的机制。