Posted at 2021-05-25Updated at 2021-05-15 面筋面筋

k8s基本常识

# 基本概念

https://segmentfault.com/a/1190000039334395

https://www.kubernetes.org.cn/5578.html

https://www.qikqiak.com/k8s-book/docs/15.基本概念与组件.html

# 资源隔离

Linux CGROUP

# CPU

绑核

# Memory

# Device

# Disk IO

https://blog.kelu.org/tech/2019/10/11/kubernetes-Limit-iops-per-container.html

Docker中有修改dockershim，和kuberuntime的labels

1 2	`annotations: BlkioDeviceWriteBps: '/dev/sda:31457280'`

# Network IO

kubectl apply -f http://acs-public.oss-cn-hangzhou.aliyuncs.com/kubernetes/network/kube-tc.yml

https://developer.aliyun.com/article/388097

部署之前，请先在集群下所有Kubernetes节点上执行modprobe sch_htb ，确保每个节点都要执行
如果您用的网络插件不是flannel，请将编排文件的 args: ["-interface", “eth0”, “-network”, “flannel”]改成 args: ["-interface", “eth0”]

annotations:
  kubernetes.io/ingress-bandwidth: 5M  #进入到容器的最大带宽
  kubernetes.io/egress-bandwidth: 10M   #容器向外访问的最大带宽

# 架构

apiserver、controller、kubelet、scheduler

Kubernetes 主要由以下几个核心组件组成:

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

插件：

kube-dns 负责为整个集群提供 DNS 服务
Ingress Controller 为服务提供外网入口
Heapster 提供资源监控
Dashboard 提供 GUI

# Pod

https://draveness.me/kubernetes-pod/

https://kubernetes.io/zh/docs/concepts/workloads/pods/

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起的。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

Pod共享网络、存储以及 CPU、内存、进程命名空间等资源。

1	`shareProcessNamespace: true`

Pod生命周期：

Create
Probe
Running
Shutdown
Restart

当 Pod 被创建之后，就会进入健康检查状态，当 Kubernetes 确定当前 Pod 已经能够接受外部的请求时，才会将流量打到新的 Pod 上并继续对外提供服务，在这期间如果发生了错误就可能会触发重启机制，在 Pod 被删除之前都会触发一个 PreStop 的钩子，其中的方法完成之后 Pod 才会被删除。

LivenessProbe ReadinessProbe

exec
httpGet
tcpSocket

# 服务

https://kubernetes.io/zh/docs/concepts/services-networking/service/

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。
使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，并且可以在它们之间进行负载均衡。

在 Kubernetes 中创建一个新的 Service 对象需要两大模块同时协作，其中一个模块是控制器，它需要在每次客户端创建新的 Service 对象时，生成其他用于暴露一组 Pod 的 Kubernetes 对象，也就是 Endpoint 对象；另一个模块是 kube-proxy，它运行在 Kubernetes 集群中的每一个节点上，会根据 Service 和 Endpoint 的变动改变节点上 iptables 或者 ipvs 中保存的规则。

# ServiceController

每当有服务被创建或者销毁时，Informer 都会通知 ServiceController，它会将这些任务投入工作队列中并由其本身启动的 Worker 协程消费。ServiceController 主要处理的还是与 LoadBalancer 相关的逻辑。

# EndpointController

EndpointController 本身并没有通过 Informer 监听 Endpoint 资源的变动，但是它却同时订阅了 Service 和 Pod 资源的增删事件。

对于每一个 Pod 都会生成一个新的 EndpointSubset，其中包含了 Pod 的 IP 地址和端口和 Service 的规格中指定的输入端口和目标端口，在最后 EndpointSubset 的数据会被重新打包并通过客户端创建一个新的 Endpoint 资源。

# Kube-Proxy

在整个集群中另一个订阅 Service 对象变动的组件就是 kube-proxy 了，每当 kube-proxy 在新的节点上启动时都会初始化一个 ServiceConfig 对象，就像介绍 iptables 代理模式时提到的，这个对象会接受 Service 的变更事件。
这些变更事件都会被订阅了集群中对象变动的 ServiceConfig 和 EndpointConfig 对象推送给启动的 Proxier 实例。
收到事件变动的 Proxier 实例随后会根据启动时的配置更新 iptables 或者 ipvs 中的规则，这些应用最终会负责对进出的流量进行转发并完成一些负载均衡相关的任务。

userspace 用户空间

在用户空间模式中，如果一个连接被目标服务拒绝，我们的代理服务能够重新尝试连接其他的服务，除此之外用户空间模式并没有太多的优势。

iptable 内核

虽然相比于用户空间来说，直接运行在内核态的 iptables 能够增加代理的吞吐量，但是当集群中的节点数量非常多时，iptables 并不能达到生产级别的可用性要求，每次对规则进行匹配时都会遍历 iptables 中的所有 Service 链。

规则的更新也不是增量式的，当集群中的 Service 达到 5,000 个，每增加一条规则都需要耗时 11min，当集群中的 Service 达到 20,000 个时，每增加一条规则都需要消耗 5h 的时间，这也就是告诉我们在大规模集群中使用 iptables 作为代理模式是完全不可用的。

ipvs 内核，更快，更复杂

ipvs 就是用于解决在大量 Service 时，iptables 规则同步变得不可用的性能问题。与 iptables 比较像的是，ipvs 的实现虽然也基于 netfilter 的钩子函数，但是它却使用哈希表作为底层的数据结构并且工作在内核态，这也就是说 ipvs 在重定向流量和同步代理规则有着更好的性能。

除了能够提升性能之外，ipvs 也提供了多种类型的负载均衡算法，除了最常见的 Round-Robin 之外，还支持最小连接、目标哈希、最小延迟等算法，能够很好地提升负载均衡的效率。

# Volume

https://draveness.me/kubernetes-volume/

Volume
Persistent Volume
Dynamic Volume Provisioning

集群中的每一个卷在被 Pod 使用时都会经历四个操作，也就是附着（Attach）、挂载（Mount）、卸载（Unmount）和分离（Detach）。

如果 Pod 中使用的是 EmptyDir、HostPath 这种类型的卷，那么这些卷并不会经历附着和分离的操作，它们只会被挂载和卸载到某一个的 Pod 中，不过如果使用的云服务商提供的存储服务，这些持久卷只有附着到某一个节点之后才可以被挂在到相应的目录下，不过在其他节点使用这些卷时，该存储资源也需要先与当前的节点分离。

# 模式

ReadWriteOnce 表示当前卷可以被一个节点使用读写模式挂载；
ReadOnlyMany 表示当前卷可以被多个节点使用只读模式挂载；
ReadWriteMany 表示当前卷可以被多个节点使用读写模式挂载；

# 回收

Retain
Delete
Dynamic Provisioning

# StatefulSet

https://kubernetes.io/zh/docs/concepts/workloads/controllers/statefulset/

StatefulSet 用来管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。

和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。

# 滚动更新

RollingUpdate 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明 .spec.updateStrategy 时，RollingUpdate 是默认配置。当 StatefulSet 的 .spec.updateStrategy.type 被设置为 RollingUpdate 时， StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。

# 分区

通过声明 .spec.updateStrategy.rollingUpdate.partition 的方式，RollingUpdate 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 .spec.template 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 .spec.updateStrategy.rollingUpdate.partition 大于它的 .spec.replicas，对它的 .spec.template 的更新将不会传递到它的 Pod。在大多数情况下，你不需要使用分区，但如果你希望进行阶段更新、执行金丝雀或执行分阶段上线，则这些分区会非常有用。

# DaemonSet

https://kubernetes.io/zh/docs/concepts/workloads/controllers/daemonset/

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的一些典型用法：

在每个节点上运行集群守护进程
在每个节点上运行日志收集守护进程
在每个节点上运行监控守护进程

# Job/CronJob

# Informer

https://www.kubernetes.org.cn/6905.html

https://segmentfault.com/a/1190000022643082

# 扩展

# CRD

operator

# Container Plugin

# Storage Plugin

# Device Plugin

# 版本号

高内聚、低耦合。
无缝的 API 集成。
为每一项服务分配唯一的资源标识。
实时流量管理。
最小化数据表，以优化加载。
通过内/外部 API，执行持续监控。
为每个微服务隔离数据的存储。这对于限制数据的访问和避免“服务的耦合”是非常有用的。例如：基于用户的分类数据，我们可以实施命令查询的责任分离（Command Query Responsibility Segregation，CQRS）。
去中心化。设计微服务架构的首要原则是：将单体结构分解成独立的多个实体，而这些实体就被称为微服务。这些微服务能够独立于其他的系统功能提供服务，用户对它们采取的所有编辑、删除、或在其他地方的使用，都不会影响到本系统的整体性能。
可扩展性。微服务的设计目标是：性能与效率。在现实世界中，解决大型系统的可扩展性问题，是任何微服务生态系统的性能体现。虽然丰富的技术功能给大量的数据工作带来了多种数据片段，但是如果能恰当地实施、并使用各种应用程序控制器（Application Controllers），则会让微服务架构更具可扩展性。
通过与 DevOps 的集成，实现持续交付。DevOps 的多技术互通与融合，比较适合于微服务架构。在设计微服务架构时，我们需要关注性能和系统效率的提升，这正好契合了 DevOps 的更快交付出方案的理念。相对于传统的单体式设计，它更适合于部署性、可靠的和可扩展性的方案管理。

https://kubernetes.io/zh/docs/setup/release/version-skew-policy/

# Tensorflow

#

Previous post: 烤面筋 - Dart Next post: 烤面筋 - Python

吹拉弹唱