k8s学习 — 第一章核心概念命名空间

k8s学习 --- 第一章核心概念命名空间级

[1 工作负载型 Pod](#1 工作负载型 Pod)
- [1.1 副本（replicas）](#1.1 副本（replicas）)
- [1.2 控制器](#1.2 控制器)
- - [1.2.1 适用无状态服务](#1.2.1 适用无状态服务)
  - - [1.2.1.1 ReplicationController（RC）](#1.2.1.1 ReplicationController（RC）)
    - [1.2.1.2 ReplicaSet（RS）](#1.2.1.2 ReplicaSet（RS）)
    - [1.2.1.3 Deployment](#1.2.1.3 Deployment)
  - [1.2.2 适用有状态服务 StatefulSet](#1.2.2 适用有状态服务 StatefulSet)
  - - [1.2.2.1 主要特点](#1.2.2.1 主要特点)
    - [1.2.2.2 组成](#1.2.2.2 组成)
    - [1.2.2.3 注意事项](#1.2.2.3 注意事项)
- [1.3 守护进程 DaemonSet](#1.3 守护进程 DaemonSet)
- [1.4 任务/定时任务](#1.4 任务/定时任务)
[2 服务发现](#2 服务发现)
- [2.1 Service](#2.1 Service)
- [2.2 Ingress](#2.2 Ingress)
[3 存储](#3 存储)
- [3.1 Volume](#3.1 Volume)
- [3.2 CSI](#3.2 CSI)
[4 特殊类型配置](#4 特殊类型配置)
- [4.1 ConfigMap](#4.1 ConfigMap)
- [4.2 Secret](#4.2 Secret)
- [4.3 DownwardAPI](#4.3 DownwardAPI)
[5 其他](#5 其他)
- [5.1 Role（命名空间级别）](#5.1 Role（命名空间级别）)
- [5.2 RoleBinding（命名空间级别）](#5.2 RoleBinding（命名空间级别）)

1 工作负载型 Pod

Pod结构：

Pod（容器组）是 Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。

Docker 是 Kubernetes Pod 中使用最广泛的容器引擎；Kubernetes Pod 同时也支持其他类型的容器引擎。

Kubernetes 集群中的 Pod 存在如下两种使用途径：

一个 Pod 中只运行一个容器。"one-container-per-pod" 是 Kubernetes 中最常见的使用方式。此时，您可以认为 Pod 容器组是该容器的 wrapper，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
一个 Pod 中运行多个需要互相协作的容器。您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个 Pod 中。

1.1 副本（replicas）

先引入"副本"的概念------一个 Pod可以被复制成多份，每一份可被称之为一个"副本"，这些"副本"除了一些描述性的信息（Pod的名字、uid等）不一样以外，其它信息都是一样的，譬如Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。

Pod的"控制器"通常包含一个名为"replicas"的属性。"replicas"属性则指定了特定Pod的副本的数量，当当前集群中该Pod的数量与该属性指定的值不一致时，k8s会采取一些策略去使得当前状态满足配置的要求。

1.2 控制器

1.2.1 适用无状态服务

1.2.1.1 ReplicationController（RC）

Replication Controller简称 RC，RC是Kubernetes系统中的核心概念之一，简单来说，RC可以保证在任意时间运行Pod的副本数量，能够保证Pod总是可用的。如果实际Pod数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当Pod失败、被删除或者挂掉后，RC都会去自动创建新的Pod来保证副本数量，所以即使只有一个Pod，我们也应该使用 RC来管理我们的Pod。可以说，通过Replication Controller，Kubernetes实现了Pod的高可用性。

1.2.1.2 ReplicaSet（RS）

RC（ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收（已经成为过去时），在v1.11版本废弃。

Kubernetes官方建议使用RS（ReplicaSet ）替代RC （ReplicationController ）进行部署，RS跟RC没有本质的不同，只是名字不一样，并且RS支持集合式的selector。

Label :

label（标签）是附加到Kubernetes对象（比如 Pods）上的键值对，用于区分对象（比如Pod、Service）。 label旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 label可以用于组织和选择对象的子集。label可以在创建时附加到对象，随后可以随时添加和修改。可以像namespace一样，使用label来获取某类对象，但label可以与selector一起配合使用，用表达式对条件加以限制，实现更精确、更灵活的资源查找。

Selector ：

label与selector配合，可以实现对象的"关联"，"Pod控制器"与Pod是相关联的 ------ "Pod控制器"依赖于Pod，可以给Pod设置label，然后给"控制器"设置对应的selector，这就实现了对象的关联。

RS的作用是帮助动态更新Pod副本数，因为每个Pod上都有唯一的标签，RS可以通过selector来选择对哪些标签的Pod生效配置。

1.2.1.3 Deployment

针对RS的更高层级的封装，提供了更丰富的部署相关功能。

Deployment 为 Pod 和 Replica Set 提供声明式更新。

你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。

自动创建 Replica Set / Pod
滚动升级/回滚
平滑扩容和缩容
暂停与恢复 Deployment：便于一次性更改多个配置后再升级。

1.2.2 适用有状态服务 StatefulSet

可以实现的功能：网络域名可以固定，对应的数据不会丢失，启动的顺序不变。

StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0...N-1}.serviceName.namespace.svc.cluster.local

serviceName 为 Headless Service 的名字
0...N-1 为 Pod 所在的序号，从 0 开始到 N-1
statefulSetName 为 StatefulSet 的名字
namespace 为服务所在的 namespace，Headless Servic 和 StatefulSet 必须在相同的 namespace
.cluster.local 为 Cluster Domain

1.2.2.1 主要特点

稳定的持久化存储：即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。
稳定的网络标志：稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现。
有序部署，有序扩展：有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现。
有序收缩，有序删除：有序收缩，有序删除（即从 N-1 到 0）。

1.2.2.2 组成

Headless Service ：有状态服务的网络管理。

用于定义网络标志（DNS domain）

Domain Name Server：域名服务

将域名与ip绑定映射关系

服务名 => 访问路径（域名） => ip

volumeClaimTemplate：用于创建持久化卷的模板PersistentVolumes。

1.2.2.3 注意事项

kubernetes v1.5版本以上才支持。
所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好。
为了保证数据安全，删除StatefulSet时不会删除Volume。
StatefulSet需要一个Headless Service来定义DNS domain，需要在StatefulSet之前创建好。

1.3 守护进程 DaemonSet

是基于选择器（selector）将所有匹配到的Pod都部署成守护进程的程序。

DaemonSet保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

日志收集，比如 fluentd，logstash 等
系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

1.4 任务/定时任务

Job：一次性任务（Pod），运行完成后Pod销毁，不再重新启动新容器。

CronJob：CronJob是在Job基础上加上了定时功能。

2 服务发现

2.1 Service

实现k8s集群内部网络调用，负载均衡（四层负载）。

"Service" 简写 "svc"。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的"服务"，它的中文名就叫"服务"。

可以说 Service 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。

2.2 Ingress

将k8s内部服务暴露给外网访问的服务。里面有Ingree-nginx反向代理、负载均衡（七层负载）

Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。

ingress 需要配合 ingress controller 一起使用才能发挥作用，ingress 只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller，ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行。

3 存储

3.1 Volume

数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。

3.2 CSI

Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。

CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。

4 特殊类型配置

4.1 ConfigMap

用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。

4.2 Secret

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

Secret 有三种类型：

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

4.3 DownwardAPI

downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。

downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部：

环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

5 其他

5.1 Role（命名空间级别）

Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。

5.2 RoleBinding（命名空间级别）

RoleBinding ：将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。

k8s学习 — 第一章 核心概念 命名空间

k8s学习 --- 第一章 核心概念 命名空间级