本系列连载文章主要分享云时代中的佼佼者k8s的系列高质量干货文章，其中包含基础概念、组件原理、基本使用、生态工具、以及生产中的最佳实践。如果觉得文章对你有一些帮助那就点个赞、关注、转发分享下。有什么问题也可以私信我一起探讨下。

本篇前言

本篇主要介绍kubernetes中涉及到的基本概念和术语，通过本篇的学习可帮助您了解Kubernetes系统的各个部分以及Kubernetes用于表示您的集群的抽象，并帮助您更深入地了解Kubernetes的工作原理。

集群节点




k8s中的pause容器_负载均衡

集群节点



Kubernetes Master

kubernetes master是指集群中主节点机器，每个kubernetes集群中都必须有一个或者多个master节点来负责整个集群的管理。其中主节点上主要包含的进程有：

  1. kube-apiserver: 主要提供api接口服务，是kubernetes里所有资源的增删改查等操作的入口。
  2. kube-controller-manager: 主要负责kubernetes集群中所有对象资源的自动化管理与控制，俗称kubernetes集群“总司令”。
  3. kube-scheduler： 主要负责集群中pod的调度，相当于军队的“作战指挥部”。
  4. etcd-server: 整个集群中所有资源对象的数据都存储在etcd中。

Kubernetes Node

kubernetes node是指集群中业务应用程序运行节点，每个node节点都会被master节点分配一些应用程序容器。该节点主要运行如下关键进程：

  1. kubelet: 保持与Master节点的保持沟通，同时负责pod具体生成与管理等任务。
  2. kube-proxy: 主要提供kubernetes service的通信与负载均衡机制的重要组件。
  3. docker Or rkt: 容器引擎，负责node节点上的容器创建与管理任务。

资源对象

Pod资源

在Kubernetes中，最小的管理单元不是一个个独立的容器，Pod才是Kubernetes创建或部署的最小的基本单位，一个Pod代表集群上正在运行的一个进程。一个Pod只能运行在一个Node节点上。一个Pod是一个kubernetes集群环境下的应用运行的“逻辑主机”。




k8s中的pause容器_Pod_02

pod基本结构



Pod资源对象基本构成：

  • 被称为“根容器”的Pause容器
  • 包含一个或多个的用户业务应用程序容器



k8s中的pause容器_Pod_03

资源共享



Pod中容器共享名称空间：

  • PID 命名空间(同一个Pod中应用容器可以看到其它进程)
  • 网络 命名空间(同一个Pod的中的应用容器对相同的IP地址和端口有权限)
  • IPC 命名空间(同一个Pod中的应用容器可以通过VPC或者POSIX进行通信)
  • UTS 命名空间(同一个Pod中的应用容器共享一个主机名称)

Replica Sets 资源

ReplicaSet(RS)是Replication Controller(RC)的升级版本。ReplicaSet 和 Replication Controller之间的唯一区别是对选择器的支持。ReplicaSet支持labels user guide中描述的set-based选择器要求， 而Replication Controller仅支持equality-based的选择器要求。

虽然ReplicaSets可以独立使用，但它主要被 Deployments用作pod 机制的创建、删除和更新。当使用Deployment时，你不必担心创建pod的ReplicaSets，因为可以通过Deployment实现管理ReplicaSets。

Deployment 资源

部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用Deployment来描述。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。

Service 资源

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。

Job 资源

Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

DaemonSet 资源

可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；而后台支撑型服务的核心关注点在K8s集群中的节点(物理机或虚拟机)，要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的DaemonSet型服务包括，存储，日志和监控等在每个节点上支持K8s集群运行的服务。

StatefulSets 资源

RS是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数；而StatefulSets是用来控制有状态服务，StatefulSets中的每个Pod的名字都是事先确定的，不能更改。RS中的Pod，一般不挂载存储或者挂载共享存储，保存的是所有Pod共享的状态，Pod之间像克隆人一样没有分别；对于StatefulSets中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。StatefulSets型服务主要包含有状态的应用，比如数据库等。

Volume 资源

K8s集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。K8s支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术(例如AWS，Google或GlusterFS和Ceph)，而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。

PV 和 PVC 资源

PV和PVC使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，有K8s集群的使用者即服务的管理员来配置。

Namespace 概念

名字空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以可以创建新的名字空间满足需要。

User Account 和Service Account 概念

顾名思义，用户帐户为人提供账户标识，而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的namespace无关，所以用户账户是跨namespace的；而服务帐户对应的是一个运行中程序的身份，与特定namespace是相关的。

Secret 和 configmap资源

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用Secret的好处是可以避免把敏感信息明文写在配置文件里。在K8s集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能，例如访问AWS存储的用户名密码。为了避免将类似的敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个Secret对象，而在配置文件中通过Secret对象引用这些敏感信息。这种方式的好处包括：意图明确，避免重复，减少暴漏机会。configmap 主要存储应用的配置文件，两者之间最大的区别，在于secret对内容做了base64的编码。

以上介绍的概念是比较常用到资源。当然还包括很多其他的东西比如: Ingress,CronJob等等没有介绍。一方面因为有些比较容易理解或者有些资源需要单独拿出讲讲原理所以在这里拘泥于篇幅不能过长没有赘述了。

喜欢的朋友可以关注下，会持续更新文章哦。