K8s概念入门

概述

        什么是k8s？

        Kubernetes（源于希腊语，意为“舵手”或“飞行员”）由Joe Beda、Brendan Burns和Craig McLuckie创立，并由其他谷歌工程师，包括Brian Grant和Tim Hockin等进行加盟创作，并由谷歌在2014年首次对外宣布 。该系统的开发和设计都深受谷歌的Borg系统的影响，其许多顶级贡献者之前也是Borg系统的开发者。在谷歌内部，Kubernetes的原始代号曾经是Seven，即星际迷航中的Borg（博格人）。Kubernetes标识中舵轮有七个轮辐就是对该项目代号的致意。由于K到s之间有8个字母，所以简称为K8s。

        Kubernetes是一个用于自动部署、扩展和管理“容器化应用程序”的开源系统，翻译成大白话就是“k8s是负责自动化运维管理多个Docker程序的集群”。

        k8s怎么做到？

        我们已经知道k8s的核心功能：自动化运维管理多个容器化程序，那么它是如何做到的呢，我们看下图

       k8s属于主从设备模型（Master-Slave架构），即有Master节点负责核心的调度、管理和运维，Slave节点则在执行用户的程序。但是在主节点一般被称为Master Node，而从节点则被称为Worker Node。

         Master Node和Worker Node是分别安装了K8S的Master和Woker组件的实体服务器，每个Node都对应了一台实体服务器，所有Master Node和Worker Node组成了K8S集群，同一个集群可能存在多个Master Node和Worker Node。

        k8s组件

        Master Node组件

        API Server：k8s的请求入口服务。API Server负责接受k8s所有请求（来自UI界面或者CLI命令行工具），然后API Server根据用户的具体请求，去通知其他组件干活。API Server可以部署多个实例，以增大请求吞吐

        Scheduler：k8s中的调度服务。当用户要部署服务时，Scheduler会选择最合适的Worker Node来部署。Scheduler也可以部署多个实例，增大处理能力。

        Controller Manager：k8s的控制服务。Controller Manager本身就是总称，实际上具有很多的Controller，Node Controller、Service Controller、Volume Controller等，分别负责不同k8s对象。例如：用户要求A服务部署2个副本，那么当其中一个服务挂了之后，Controller会马上调整，让Scheuler再选择一个Worker Node重新部署服务。

        etcd：k8s的存储服务。etcd存储了k8s的关键配置和用户配置，k8s中仅API Server才具备读写权限，其他组件必须通过API Server的接口才能读写数据。

        Worker Node组件

        Kubelet：Worker Node的监视器，以及与Master Node的通讯器。Kubelet是Master Node安插在Worker Node上的“眼线”，它会定期向Master Node汇报自己Node上运行的服务的状态，并接受来自Mater Node的命令，并执行。

        Kube-Proxy：k8s的网络代理。负责Node在k8s的网络通讯、以及对外部网络流量的负载均衡。

        Container Runtime：Worker Node的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如Docker Engine。其实就是帮忙装好了Docker运行环境。

        Logging Layer：k8s的监控状态收集器。负责采集Node上所有服务的CPU、内存、磁盘、网络等监控项信息。

k8s的重要概念

        Pod

        官方对于Pod的解释是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。

那么Pod究竟是什么呢？Pod英文意为豆荚，它实际确实跟豆荚相似，在一个Pod中可以部署多个容器，具体看下图。

        在同一个Pod中的几个Docker服务/程序就像是被部署在同一台机器，可以通过localhost互相访问，并且可以共用Pod里的存储资源（这里指的是Docker可以挂载Pod内的数据卷），但是不同Pod之间的controller不能用localhost访问，也不能挂载其他Pod的数据卷。因此我们可以理解为一群可以共享网络、存储和计算资源的容器化服务的集合。

        Deployment和ReplicaSet（简称RS）

        Deployment的作用是管理和控制Pod和ReplicaSet，管控它们运行在用户期望的状态中。

        ReplicaSet的作用是管理和控制Pod，但是受控于Deployment

        在这里，也许就有人有疑问了，既然都是管理Pod的，为什么还要设置两个层级呢？这是为了实现前后两个版本平滑升级、平滑回滚等高级功能。如下图所示

        当Deployment被部署的时候，k8s会自动生成要求的ReplicaSet和Pod。用户只需要关心Deployment而不用操心ReplicaSet。

        Service

        Service、Ingress负责管控Pod网络服务。k8s中的服务（Service）并不是我们常说的“服务”的含义，而更像是网关层，是若干的Pod的流量入口、流量均衡器。

        那么为什么要Service呢?Pod是有生命周期的，它们可以被创建和销毁，而且销毁后不会再启动。每个Pod都有自己的IP地址，但是在Deployment中，在同一时刻运行的Pod集合可能与稍后运行该应用程序的Pod集合不同。这就导致了一个问题：如果一组Pod（后端）为群集内的其他Pod（前端）提供功能，那么要如何找出并跟踪要连接的IP地址？

        Service是k8s服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。例如：我们的服务A，部署了3个副本也就是3个Pod，对于用户来说，只需要关注一个Service的入口就可以，而不用操心应该请求哪一个Pod。优势很明显：一方面外部用户不需要感知因为Pod上服务的意外崩溃、k8s重新拉起Pod而造成的IP变更，外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化，另一方面，Service还可以做流量负载均衡。

        Service的三种类型：

        ClusterIP：只提供k8s集群内可以访问的IP和Port。（默认类型）

        NodePort：在ClusterIP基础上，每个节点开放固定端口，允许外部通过<NodeIP>:<NodePort>访问。

        LoadBalancer：依赖云厂商的负载均衡器（如AWS WLB、阿里云SLB），自动分配外部IP并暴露服务。

        ExternalName：通过DNS CNAME将服务映射到外部域名。

        总结

        k8s的概念还有很多很多，有兴趣的可以去了解一下