kubernetes基础概念

基础篇

Pod

封装单个或多个容器

=

spec.containers.ports.hostPort

暴露端口，使Pod应用能够被其他节点之上的容器客户端访问

=

spec.hostNetwork

暴露端口，直接共享节点的网络

=

Service

提供外部流量访问入口（ClusterIP），并将流量进行负载均衡调度
'【每个节点】的kube-proxy都会将其所在节点上的【每个Service】的定义转换为ipvs或iptables规则

服务发现

​ 在 K8 集群中，客户端需要访问的服务就是 Service 对象
​ 每个 Service 会对应一个集群内部的有效的虚拟 IP，集群内部通过虚拟 IP 访问一个确定的服务

负载均衡

​ Kube-proxy 是 Kubernetes 集群内部的负载均衡器
​ 需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy 就越多

Service@ClusterIP

通过集群内部IP地址暴露服务，但该地址仅在集群内部可见、可达，它无法被集群外部的客户端访问

=

Service@NodePort

NodePort是ClusterIP的增强类型
它会于ClusterIP的功能之外，在每个节点上使用一个相同的端口号将外部流量引入到该Service上

=

Service@LoadBalancer

LB是NodePort的增强类型，要借助于底层IaaS云服务上的LBaaS产品来按需管理

=

Service@ExternalName

借助集群上KubeDNS来实现，服务的名称会被解析为一个CNAME记录，而CNAME名称会被DNS解析为集群外部的服务的IP地址
这种Service既不会有ClusterIP，也不会有NodePort

---

=

CoreDNS

外部流量访问的是 svc-name，因此需要解析成ClusterIP
又因为Pod是动态消亡的，因此传统DNS不行，需要使用 CoreDNS 实现动态解析

=

Headless Service

使用 CoreDNS时，将 svc-name解析为ClusterIP，再去调度给Pod
使用 Headless Service时没有ClusterIP，解析结果直接到达Pod。。。主要用于有状态服务！！！

=

Service（NodePort）

ClusterIP：通过集群内部IP地址暴露服务，但该地址仅在集群内部可见可达，无法被外部的客户端访问
NodePort：在ClusterIP的功能之外，在每个节点上使用一个相同的端口号将’外部流量’引入到该Service上来

=

Endpoint

由于标签选择器无法选择到集群外部节点，因此需要使用Endpoint引入’外部服务’
在集群内手动创建Endpoint资源，为此资源指定一个端点，指定为集群外部的IP地址，然后在此Endpoint资源上再创建一个Service资源，于是即可使外部客户端通过两道桥连接到业务Pod

=

Ingress

实现七层流量转发
基于某Ingress资源定义的规则将客户端的请求流量【直接转发】至与Service对应的后端Pod资源之上

=

flannal

是实现CNI的插件之一
让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址，从而每个Pod都能有自己的IP

=

init 容器

在应用容器启动之前运行，包含一些应用镜像中不存在的实用工具或安装脚本
有一个或多个，是串行运行的
必须等所有的init 容器全部成功启动完毕，才会启动后续容器（主容器、辅助容器、postStart 都同时启动）
默认情况：如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init容器成功为止

=

pause 容器

实现Pod的基础设施

1.给这个Pod内部的所有容器提供 可以被加入和共享的三种Namespace（网络、IPC、UTS）
2.当向一个Pod上加入Volume的时候，也是附加在 pause 容器之上，从而可以被共享给所有容器

=

Sidecar 容器

是一种辅助容器，让外部请求更好地接入到主容器
所有外部请求首先达到Sidecar，然后转发给主容器；主容器的响应也先经由Sidecar
优势：将Pod内容器共同的高级功能单独放在一个容器中，应用程序中只存放核心业务代码

=

hook 钩子

1.postStart：init容器刚刚启动完成后执行。只有postStart成功执行完毕，主容器才会被设为Running 状态
2.只有preStop成功执行完毕，主容器才能正常终止

=

probe 探针

Pod状态为Running未必就是健康的，因此需要更精确的探测机制
三种探针：ExecAction、TCPSocketAction、HTTPGetAction
三种检测用途：liveness probe、readiness probe、startup probe

=

Volume 存储卷

是独立于容器文件系统之外的存储空间，常用于扩展容器的存储空间并实现持久存储

PV & PVC

声明式配置实现职能分离：PVC让用户只需要提出需求即可，剩下的由PV实现

• 持久存储卷申请：Persistent Volume Claim

  1. 是标准资源类型
  2. 由用户定义
  3. 是namespace级别的资源（不会因Pod的消失而受到影响）

• 持久存储卷：Persistent Volume

  1. 可被PVC申请绑定，自己必须与真正存储空间关联才能实现存储功能（一般是网络存储空间）
  2. PV由集群管理员进行管理
  3. 是集群级别的资源（因此可被任何一个namespace中的PVC所请求）

实现逻辑：Pod (pvc plugin) ——> PVC (同一名称空间) ——> PV

存储的 PV 和 PVC 的这种关系，跟计算的 Node 和 Pod 的关系是非常类似的：

• PV 和 Node 是资源的提供者，根据集群的基础设施变化而变化，由集群管理员来配置；
• 而 PVC 和 Pod 是资源的消费者，根据业务服务的需求变化而变化，由集群的使用者即服务的管理员来配置

=

StorageClass 存储类

• 用于将存储资源定义为**具有显著特性的类别 (Class）**而不是具体的PV
• 用户通过PVC申请想要的存储类型，去匹配管理员事先创建的PV，或者直接为用户动态生成PV
• StorageClass是按用户需求动态生成PV的模板

---

控制器

RC ReplicationController

通过监控运行中的Pod来确保维持期望状态 '（已淘汰的技术）

=

RS ReplicaSet

通过标签选择器匹配一组Pod，对其进行管理
RS对象一般不单独使用，而是作为 Deployment 的理想状态参数使用，这样就无需担心跟其他机制的不兼容问题
（比如 ReplicaSet不支持rolling-update，但 Deployment支持)

=

Deployment

构建于ReplicaSet控制器之上，可为 Pod和 ReplicaSet资源提供声明式更新
主要功能：通过标签选择器关联Pod，确保Pod数量维持在spec设定的期望值

=

DaemonSet

用于指定每个节点具体分配几个Pod （默认均摊）

=

StatefulSet

对于无状态应用，Pod名和启动在哪儿都不重要，唯一关注的是副本数量
而有状态应用中，‘每个Pod都有自己的唯一标识’，故障时，它只能被拥有同一标识的新实例取代
如果有必要，可以为每个Pod配置专用的存储卷，且只能使用PVC模板

=

Awesome

由于StatefulSet功能有限且使用复杂，实际生产使用 Awesome 管理有状态应用

=

Job

对于只需要偶尔运行一次的任务，需要使用Job
是有终止期限的一次性作业式任务，任务终止之后不会重启

=

CronJob

有终止期限的周期性作业式任务。。。需要使用Job模板