一、K8S能做什么？为什么需要学习K8S？
1、服务发现和负载均衡
k8s的pod是有生命周期的，当pod重启其ip很有可能发生变化；如果把服务的ip写死，pod重启时后端服务将不可用；为避免这种情况，k8s使用service概念和服务自发现确保服务的可用性
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
2、存储编排
Kubernetes 允许自动挂载你选择的存储系统，如本地存储、云存储
3、自动部署和回滚
使用yaml文件自动部署，或根据容器版本删除、重新部署容器以回滚
4、自动二进制打包
Kubernetes 允许指定每个容器所需 CPU 和内存（RAM）
5、自我修复
Kubernetes可通过各种控制器重启失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器以达到用户期望的状态
6、密钥与配置管理
Kubernetes 允许您存储和管理密码、令牌和 ssh 密钥等。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥
二、K8S组件
控制平面组件
1、kube-apiserver/api接口
需部署在 master 节点上；是 Kubernetes 控制面的前端。kube-apiserver 在设计上考虑了水平扩展的需要，如果我们需要搭建集群，可以安装基数节点的kube-apiserver，然后可通过负载均衡器做集群
2、etcd/k8s后台数据库
etcd 是兼具一致性和高可用性的键值数据库，官方建议作为 Kubernetes 所有集群数据的后台数据库
3、kube-scheduler/k8s pod调度器
需部署在 master 节点上，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
4、kube-controller-manager/k8s管理器
需部署在 master 节点上。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
这些控制器包括：
节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod
端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
5、cloud-controller-manager/云控制器管理器
运行与基础云提供商交互的控制器，从k8s1.6之后出现的新功能
也包括了多个控制器：节点控制器、路由控制器、服务控制器、数据卷控制器
Node节点组件
kubelet/节点管理工具
kubelet负责管理节点的pod，可以理解为当在master上执行创建、删除对象时，kubelet负责执行从kube-apiserver下达的指令
kube-proxy/网络管理器
kube-proxy运行在每个node节点上，管理维护node上的网络规则
Container Runtime/容器运行环境
简而言之，就是容器。我们需要在node节点安装runtime作为k8s部署容器的运行环境，目前主流当然是docker
集群插件
域名解析服务：如CoreDNS、Cluster DNS
资源监控服务：Prometheus、Metrics-Server
用户的ui管理界面：Dashboard、Kubesphere
集群日志：ELK
镜像仓库：Harbor
三、K8S概念补充
1、pod
pod是K8S的最小管理单元，一个pod中可运行一个或者一组容器。pod内的容器共享使用pod的唯一ip地址和一组存储卷。同一pod内的容器使用localhost进行通信；而与pod外的容器通信时，需要pod内的容器协调使用pod的端口进行通信
pod有生命周期，当一个pod生命周期结束后，该pod将不复存在，k8s会重新部署一个新的pod提供和该pod一样的服务。这样就用到service概念用于标记k8s集群提供一组服务的pod。
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - args: - /server image: k8s.gcr.io/liveness livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 15 timeoutSeconds: 1 name: liveness2、service
假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 app=MyApp 标签，我们就可以部署一个service，将TCP：9376的请求代理到这组pod上，上述就是service的作用。所以可以大致理解为service是pod的代理层，根据用户请求的端口和服务，service找到对应标签的pod，将请求代理到这些pod去处理。如果您想要在应用程序中使用 Kubernetes 接口进行服务发现，则可以查询 API Server 的 endpoint 资源，只要服务中的Pod集合发生更改，endpoint 就会更新。
官方说：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过selector实现的
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 93763、volume
Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同，但是卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。Kubernetes支持多种类型的卷，如nfs、iscsi、cinder、azureDisk等
以下是cinder volume示例配置：
apiVersion: v1 kind: Pod metadata: name: test-cinder spec: containers: - image: k8s.gcr.io/test-webserver name: test-cinder-container volumeMounts: - mountPath: /test-cinder name: test-volume volumes: - name: test-volume # This OpenStack volume must already exist. cinder: volumeID: <volume-id> fsType: ext44、Deployment
顾名思义，Deployment是一个部署，作用主要是创建、更新、回滚ReplicaSet以控制pod
如下是k8s官方的Deployment示例：
5、namespace（命名空间）
命名空间为名称提供了一个范围。资源的名称需要在命名空间内是唯一的，但不能跨命名空间。命名空间不能相互嵌套，每个 Kubernetes 资源只能在一个命名空间中。
kubernetes存在三个初始的命名空间：
default/没有指定命名空间的容器默认的
kube-system/kubernetes系统创建的
kube-public/公共的，对于所有用户都可读
kubectl get namespaceNAME STATUS AGE default Active 1d kube-public Active 1d kube-system Active 1d6、Job
可创建一个或者多个pod，job在指定次数、指定个数的pod创建后job的工作就完成了
删除一个job，会将其创建的pod一并清除
7、endpoint
endpoint是kubernetes的一个资源对象，存储于etcd数据库中，用以记录service的所有pod的访问地址
8、object（对象）
object是持久化的实体，用以表示整个集群的状态：
哪些容器化应用在运行
可以被应用使用的资源
应用运行时重启策略、升级策略，以及容错策略
一个object一旦创建，kubernetes会持续工作以保证对象存在；也就是通过对象棵设置kubernetes集群的期望状态
object的操作依赖于Kubernetes API，如果使用kubectl也是通过调用Kubernetes API完成的操作（使用yaml文件操作会将文件的内容从yaml转换为json格式）
9、Object Name 和 UID（对象名和UID）
集群中的每一个对象都一个名称 来标识在同类资源中的唯一性。
每个 Kubernetes 对象也有一个UID 来标识在整个集群中的唯一性。
10、label（标签）
label是附加到对象的键/值对；label可以在创建时附加到对象，然后可以随时添加和修改。每个对象可以定义一组键/值标签。每个键对于给定的对象必须是唯一的。label不是唯一的，也就是说多个对象可以拥有同一个label，如我们可以创建多个label为nginx的pod用于统一管理。
11、label selector（标签选择器）
与名称和UID不同，标签不提供唯一性。通常，我们希望许多对象携带相同的标签。通过标签选择器，客户端/用户就可以识别一组同标签的对象。
12、ReplicaSet
ReplicaSet 是Replication Controller（RC）的下一代，区别在于支持基于集合的选择器。
官方说：ReplicaSet 确保任何时间都有指定数量的Pod副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能， 因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet。
13、ReplicationController（RC）
是kubernetes的pod数量控制器，RC同时跨多个节点（node）控制多个pod的数量而不是仅限于单机。工作的内容主要是当pod数量跟预期不一样了，RC会将该数量维持为预期的数量
以下是配置运行 nginx web 服务器的三个副本的RC的示例（会控制pod数量始终为3个）：
apiVersion: v1 kind: ReplicationController metadata: name: nginx spec: replicas: 3 selector: app: nginx template: metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 8014、StatefulSets
StatefulSets用来管理 Deployment 和扩展一组 Pod
StatefulSet 和 Deployment 相同的是管理了基于相同容器定义的一组 Pod；但是StatefulSet 为它的每个 Pod 维护了一个固定的 ID，并且该ID是基于声明创建的，无论pod如何调度，ID永久不变
StatefulSet多用于满足以下一个或多个条件的应用程序：
稳定的、唯一的网络标识符。
稳定的、持久的存储。
有序的、优雅的部署和缩放。
有序的、自动的滚动更新。
--- apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx # has to match .spec.template.metadata.labels serviceName: "nginx" replicas: 3 # by default is 1 template: metadata: labels: app: nginx # has to match .spec.selector.matchLabels spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: k8s.gcr.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "my-storage-class" resources: requests: storage: 1Gi15、DaemonSet
DaemonSet管理节点上的各个守护的pod，例如集存储群、日志收集器、监控客户端，通俗来讲就是K8S集群状态的控制器
插一脚：本文章是作者对k8s官网文挡拜读后的总结，作为笔记分享和使用