上一篇介绍了用kubeadm安装k8s集群，能把k8s安装起来是开始学习和实践的第一步。
集群安装好了，今天我们来简单介绍下k8s的基础实践，并在实践中介绍基本概念。
Kubernetes 对象包含哪些？
在 Kubernetes 系统中，Kubernetes 对象是持久化的实体。Kubernetes 使用这些实体去表示整个集群的状态。也许你觉得这句话很抽象，说人话，对象用来描述以下的一些信息：
- 哪些容器化应用在运行（以及在哪个 Node 上）
- 可以被应用使用的资源
- 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略
操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 Kubernetes API。比如，当使用 kubectl 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。
例如用kubectl查看集群所有的节点（节点就是一个k8s对象），执行以下命令：
kubectl get node
Kubernetes对象包含：
-
Node
Node 是 Kubernetes 的工作节点，以前叫做 minion。取决于你的集群，Node 可以是一个虚拟机或者物理机器。每个 node 都有用于运行 pods 的必要服务，并由 master 组件管理。Node 上的服务包括 Docker、kubelet 和 kube-proxy -
Pod
Pod 是 Kubernetes 的基本构建块，它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。 Pod 表示集群上正在运行的进程。 -
Replication Controller
ReplicationController 确保在任何时候都有特定数量的 pod 副本处于运行状态。 换句话说，ReplicationController 确保一个 pod 或一组同类的 pod 总是可用的。现在推荐使用配置 ReplicaSet 的 Deployment 来建立副本管理机制。 -
ReplicaSet
ReplicaSet 是下一代的 Replication Controller。 ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持。ReplicaSet 支持新的基于集合的选择器需求，这在标签用户指南中有描述。而 Replication Controller 仅支持基于相等选择器的需求。 -
Deployments
Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。 -
StatefulSet
StatefulSet 刚开始接触有点不好理解，她用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据
- 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
- 有序部署（比如服务启动需要依赖其他服务已经启动），有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
- 有序收缩，有序删除（即从N-1到0）
-
DaemonSet
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，该控制器会自动部署对应Pod或服务。比如在每个节点上运行监控 daemon： Prometheus Node Exporter -
Job
Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束 -
CronJob
Cron Job 管理基于时间的 Job，如：在给定时间点只运行一次或周期性地在给定时间点运行。 -
Volumes
存储和网络是k8s中比较难的部分。
我们知道docker容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。 首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失——因为容器会以干净的状态重建。 其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件，所以Kubernetes 抽象出 Volume 对象来解决这两个问题。k8s的存储和docker的volumes不是同一个概念，docker的volume仅仅是挂载docker容器所在的主机的磁盘路径。而k8s是一组抽象的定义，volumes由不同的存储class插件来实现。下面是详细介绍
Kubernetes 支持下列类型的卷： -
awsElasticBlockStore
-
azureDisk
-
azureFile
-
cephfs
-
configMap
-
csi
-
downwardAPI
-
emptyDir
-
fc (fibre channel)
-
flocker
-
gcePersistentDisk
-
gitRepo (deprecated)
-
glusterfs
-
hostPath
-
iscsi
-
local
-
nfs
-
persistentVolumeClaim
-
projected
-
portworxVolume
-
quobyte
-
rbd
-
scaleIO
-
secret
-
storageos
-
vsphereVolume
PV & PVC
PersistentVolume 子系统为用户和管理员提供了一个 API，该 API 将如何提供存储的细节抽象了出来。为此，我们引入两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。
PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。
PersistentVolume 子系统为用户和管理员提供了一个 API，该 API 将如何提供存储的细节抽象了出来。为此，我们引入两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。
PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。
PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载）。PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载）。
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的认证信息。
ConfigMap
ConfigMap API资源用来保存key-value pair配置数据，这个数据可以在pods里使用，或者被用来为像controller一样的系统组件存储配置数据。虽然ConfigMap跟Secrets类似，但是ConfigMap更方便的处理不含敏感信息的字符串。 注意：ConfigMaps不是属性配置文件的替代品。
网络、服务和负载均衡
前面已经讲过，网络是比较难的部分。网络部分包含服务、负载均衡等。理解K8S集群服务的概念，是比较不容易的一件事情。这部分我们下篇文章再聊。
网友评论