k8s~术语解释

文章参考：https://www.kubernetes.org.cn

简介

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

Kubernetes一个核心的特色就是可以自主的管理容器来保证云平台中的容器按照用户的指望状态运行着（好比用户想让apache一直运行，用户不须要关心怎么去作，Kubernetes会自动去监控，而后去重启，新建，总之，让apache一直提供服务），管理员能够加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes也系统提高工具以及人性化方面，让用户可以方便的部署本身的应用（就像canary deployments）。

节点node

• master > 负责调度
• worker > 负责项目运行

Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。
每次个节点上固然都要运行Docker。Docker来负责全部具体的映像下载和容器运行。

Kubernetes主要由如下几个核心组件组成：

1. etcd保存了整个集群的状态；
2. apiserver提供了资源操做的惟一入口，并提供认证、受权、访问控制、API注册和发现等机制；
3. controller manager负责维护集群的状态，好比故障检测、自动扩展、滚动更新等；
4. scheduler负责资源的调度，按照预约的调度策略将Pod调度到相应的机器上；
5. kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
6. Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
7. kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的Add-ons：

1. kube-dns负责为整个集群提供DNS服务
2. Ingress Controller为服务提供外网入口
3. Heapster提供资源监控
4. Dashboard提供GUI
5. Federation提供跨可用区的集群
6. Fluentd-elasticsearch提供集群日志采集、存储与查询

术语解释

• pods

在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod,Pod是最小的，管理，建立，计划的最小单元.一个Pod（就像一群鲸鱼，或者一个豌豆夹）至关于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用多是在同一个物理主机或虚拟机上。

• 同一个Pod中的应用能够共享磁盘
• 因为docker的架构，一个Pod是由多个相关的而且共享磁盘的容器组成

• Labels

标签其实就一对 key/value ，被关联到对象上，好比Pod,标签的使用咱们倾向于可以标示对象的特殊特色，而且对用户而言是有意义的（就是一眼就看出了这个Pod是尼玛数据库），可是标签对内核系统是没有直接意义的。标签能够用来划分特定组的对象（好比，全部女的），标签能够在建立一个对象的时候直接给与，也能够在后期随时修改，每个对象能够拥有多个标签，可是，key值必须是惟一的

• Namespace

Namespace是对一组资源和对象的抽象集合，好比能够用来将系统内部的对象划分为不一样的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default），而node, persistentVolumes等则不属于任何namespace

• Replication Controller

Replication Controller 保证了在全部时间内，都有特定数量的Pod副本正在运行，若是太多了，Replication Controller就杀死几个，若是太少了，Replication Controller会新建几个，和直接建立的pod不一样的是，Replication Controller会替换掉那些删除的或者被终止的pod，无论删除的缘由是什么（维护阿，更新啊，Replication Controller都不关心）。基于这个理由，咱们建议即便是只建立一个pod，咱们也要使用Replication Controller。Replication Controller 就像一个进程管理器，监管着不一样node上的多个pod,而不是单单监控一个node上的pod,Replication Controller 会委派本地容器来启动一些节点上服务（Kubelet ,Docker）。

• Node

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

每一个Node都包括如下状态信息

1. 地址：包括hostname、外网IP和内网IP
2. 条件（Condition）：包括OutOfDisk、Ready、Me* moryPressure和DiskPressure
3. 容量（Capacity）：Node上的可用资源，包括CPU、内存和Pod总数
4. 基本信息（Info）：包括内核版本、容器引擎版本、OS类型等

• ReplicaSets

ReplicaSet是下一代复本控制器。ReplicaSet和 Replication Controller之间的惟一区别是如今的选择器支持。Replication Controller只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。在试用时官方推荐ReplicaSet。

• Services

Kubernetes Pod是平凡的，它门会被建立，也会死掉（生老病死），而且他们是不可复活的。 ReplicationControllers动态的建立和销毁Pods(好比规模扩大或者缩小，或者执行动态更新)。每一个pod都由本身的ip，这些IP也随着时间的变化也不能持续依赖。这样就引起了一个问题：若是一些Pods（让咱们叫它做后台，后端）提供了一些功能供其它的Pod使用（让咱们叫做前台），在kubernete集群中是如何实现让这些前台可以持续的追踪到这些后台的？答案是：Service

Kubernete Service 是一个定义了一组Pod的策略的抽象，咱们也有时候叫作宏观服务。这些被服务标记的Pod都是（通常）经过label Selector决定的（下面咱们会讲到咱们为何须要一个没有label selector的服务）

• Volumes

容器中的磁盘的生命周期是短暂的，这就带来了一系列的问题，第一，当一个容器损坏以后，kubelet 会重启这个容器，可是文件会丢失-这个容器会是一个全新的状态，第二，当不少容器在同一Pod中运行的时候，不少时候须要数据文件的共享。Kubernete Volume解决了这个问题.
一个Kubernetes volume，拥有明确的生命周期，与所在的Pod的生命周期相同。所以，Kubernetes volume独立与任何容器，与Pod相关，因此数据在重启的过程当中还会保留，固然，若是这个Pod被删除了，那么这些数据也会被删除。更重要的是，Kubernetes volume 支持多种类型，任何容器均可以使用多个Kubernetes volume。

• Deployment

Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代之前的ReplicationController来方便的管理应用。典型的应用场景包括：

1. 定义Deployment来建立Pod和ReplicaSet
   2.滚动升级和回滚应用
2. 扩容和缩容
3. 暂停和继续Deployment
   好比一个简单的nginx应用能够定义为

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

• Secret

Secret解决了密码、token、密钥等敏感数据的配置问题，而不须要把这些敏感数据暴露到镜像或者Pod Spec中。Secret能够以Volume或者环境变量的方式使用。
Secret有三种类型：

1. Service Account：用来访问Kubernetes API，由Kubernetes自动建立，而且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中；
2. Opaque：base64编码格式的Secret，用来存储密码、密钥等；
3. kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。

• Ingress

在本篇文章中你将会看到一些在其余地方被交叉使用的术语，为了防止产生歧义，咱们首先来澄清下。

1. 节点：Kubernetes集群中的服务器；
2. 集群：Kubernetes管理的一组服务器集合；
3. 边界路由器：为局域网和Internet路由数据包的路由器，执行防火墙保护局域网络；
4. 集群网络：遵循Kubernetes网络模型实现群集内的通讯的具体实现，好比flannel 和 OVS。
5. 服务：使用标签选择器标识一组pod成为的Kubernetes Service。 除非另有说明，不然服务的虚拟IP仅可在集群内部访问。

什么是Ingress？
一般状况下，service和pod的IP仅可在集群内部访问。集群外部的请求须要经过负载均衡转发到service在Node上暴露的NodePort上，而后再由kube-proxy将其转发给相关的Pod。

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

• ConfigMap

ConfigMap用于保存配置数据的键值对，能够用来保存单个属性，也能够用来保存配置文件。ConfigMap跟secret很相似，但它能够更方便地处理不包含敏感信息的字符串。