【k8s】浅谈kubernetes基本概念

前面环境已经搭建完了，接下来谈谈我对k8s各种概念的简单理解

k8s是干什么的？一句话：是跨主机管理容器的。

Kubernetes 的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。它的目的就是实现资源管理的自动化，主要提供了如下的功能：

• 自我修复：一旦某一个容器崩溃，能够在1秒左右迅速启动新的容器。
• 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整。
• 服务发现：服务可以通过自动发现的形式找到它所依赖的服务。
• 负载均衡：如果一个服务启动了多个容器，能够自动实现请求的负载均衡。
• 版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本。
• 存储编排：可以根据容器自身的需求自动创建存储卷。

有人说，我还是理解不了，那我建议看一篇大佬文章（很绝）：【大话云原生】煮饺子与docker、kubernetes之间的关系

看完之后，回过来说k8s的一些基本概念

前面我们在vmware搭建了一套k8s集群环境，其内部大体的架构上是这个样子的

节点： 分布式集群中可理解为一台服务器就是一个节点

节点包括：master 和 node， 控制节点 和 工作节点

master： 集群的控制节点，负责整个集群的管理和控制。简单理解就是领导班子。
node: 集群中的工作节点，Node 上的工作负载由 Master 节点分配，工作负载主要是运行容器应用。简单理解就是具体承接任务的打工群体。

搭建完成的k8s集群

• master节点中包含组件

  • apiserver： 集群控制的入口，提供 http rest 服务。
  • controller-manager： 集群中所有资源对象的自动化控制中心。
  • scheduler： 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上。
  • etcd： 保存了整个集群的状态，就是一个数据库。

• node节点中包含组件

  • kubelet： 负责 Pod 的创建、启动、监控、重启、销毁等工作，处理Master节点下发到本节点的任务
  • kube-proxy： 实现 Kubernetes Service 的通信和负载均衡
  • Docker Engine： 负责节点容器的管理工作，最终创建出来的是一个Docker容器。

如上这些组件只要搭建起k8s集群，就会存在系统中。

对于这些概念现在可能有点懵，不过没关系，可以先有个大概认知，随着学习深入慢慢感知。上边我们提到了一个名词：Pod。那么什么是Pod呢？

翻译过来就是“豆荚”，就这玩意

生动形象的概括了pod的含义，其实它就是容器的壳，一个豆荚内可以包含一个或多个豆子。

Pod: Pod 是 Kubernetes 最基本的部署调度单元。每个 Pod 可以由一个或多个业务容器和一个根容器(Pause 容器)组成。一个 Pod 表示某个应用的一个实例。

• 在kubernetes中，按照Pod的创建方式可以将其分为两类：
  • 自主式Pod：kubernetes直接创建出来的Pod，这种Pod删除后就没有了，也不会重建。
  • 控制器创建Pod：通过Pod控制器创建的Pod，这种Pod删除之后还会自动重建。

Pod控制器： Pod控制器是管理Pod的中间层，使用了Pod控制器之后，我们只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它就会创建出满足条件的Pod并确保每一个Pod处于用户期望的状态，如果Pod在运行中出现故障，控制器会基于指定的策略重启或重建Pod。

其实就是给pod再加一个壳，通过加不同的壳，让它有不同的能力。

• 在kubernetes中，有很多类型的Pod控制器，每种都有自己的适合的场景，常见的有下面这些：
  • ReplicationController： 比较原始的Pod控制器，已经被废弃，由replicaset替代。
  • replicaset： 保证指定数量的Pod运行，并支持Pod数量变更，镜像版本变更。
  • Deployment： 通过控制replicaset来控制Pod，并支持滚动升级、版本回退。
  • Horizontal Pod Autoscaler： 可以根据集群负载自动调整Pod的数量，实现削峰填谷。
  • DaemonSet： 在集群中的指定Node上都运行一个副本，一般用于守护进程类的任务。
  • Job： 它创建出来的Pod只要完成任务就立即退出，用于执行一次性任务。
  • CronJob： 它创建的Pod会周期性的执行，用于执行周期性的任务。
  • StatefulSet： 管理有状态的应用。

流量负载组件： Service 和 Ingress

• Service

在kubernetes中，Pod是应用程序的载体，我们可以通过Pod的IP来访问应用程序，但是Pod的IP地址不是固定的（存在销毁和重新创建），这就意味着不方便直接采用Pod的IP对服务进行访问。

为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个Pod进行聚合，并且提供一个统一的入口地址，通过访问Service的入口地址就能访问到后面的Pod服务。

Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行了一个kube-proxy的服务进程。当创建Service的时候会通过API Server向etcd写入创建的Service的信息，而kube-proxy会基于监听的机制发现这种Service的变化，然后它会将最新的Service信息转换为对应的访问规则。

这样看下来似乎有点懵懵的。大致意思是说：我们在集群外部是不能用pod的ip地址访问pod内的应用程序的，需要搭一个桥，这个service就是这个桥。它生成一个ip，映射了内部和外部的端口号，你拿着ip和端口号，就可以访问内部应用了。

• Ingress

service使得可以通过ip和端口号了进行访问了，但是拿着ip和端口号天天访问，是不是太low了，而且项目多了，你端口号也记不住对不对。所以kubernetes提供了一种类似Nginx的东西，叫做ingress。
实现的结果大概是如下图的样子。

数据存储

容器的生命周期可能很短，会被频繁的创建和销毁。那么容器在销毁的时候，保存在容器中的数据也会被清除。为了持久化保存容器中的数据，kubernetes引入了Volume。和docker的Volume类似，但是比它更强大。

• kubernetes的Volume支持多种类型，比较常见的有下面的几个：
  • 简单存储：EmptyDir（临时空间）、HostPath（node中实际目录挂载到Pod中）、NFS（网络文件存储系统）。
  • 高级存储：PV（持久化卷）、PVC（持久化卷声明）。pv : 相当于磁盘分区 。pvc: 相当于磁盘请求。
  • 配置存储：ConfigMap（特殊的存储卷，存储配置信息）、Secret（存储敏感配置信息，密码，秘钥，证书等）。

概念很多，通过看各种文档学习，慢慢就会有所理解。

前路漫漫，半程风雨半程春