Job批处理任务通常并行（或者串行）启动多个计算机进程去处理一批工作项（work item），在处理完成后，整个批处理任务结束。Kubernetes 支持批处理类型的应用，可以通过 Kubernetes Job 这种新的资源对象定义并启动一个 批处理任务 Job。与 RC、Deployment、RS、DaemonSet 类似，Job 也控制一组 Pod 容器。Job 也是一种特殊的 Pod 副本自动控制器，同时 Job 控制 Pod 副本与 RC 等控制器工作机制有以下差别Job 控制的 Pod 副本是短暂运行的可以将 Job 视为一组 Docker 容器，其中的每个 Docker 容器都仅仅运行一次，当 Job 控制的所有 Pod 副本都运行结束时，对应的Job 也就结束了。Job 生成的 Pod 副本是不能自动重启的，对应 Pod 副本的 RestartPoliy 都被设置为 Never当对应 Pod 副本都执行完时，相应的 Job 也就完成了控制使命，即 Job 生成的 Pod 在 Kubernetes 中是短暂存在的。定时任务 CronJob在 1.5 版本之后，提供了类似 c
概述Service 服务是 Kubernetes 里的核心资源对象之一，Kubernetes 里的每个 Service 其实就是我们经常提到的 微服务架构 中的一个 微服务。如上图所示：Kubernetes 的 Service 定义了一个服务的访问入口地址前端的应用（Pod）通过这个入口地址访问其背后的一组由 Pod 副本组成的集群实例Service 与其后端 Pod 副本集群之间是通过 Label Selector 来实现无缝对接的RC 的作用是保证 Service 的服务能力 和 服务质量始终符合预期标准简单来说Service 是一个联通，一个 Pod 通过 Service 来找到应该对应的另一个 Pod网络通信通过分析、识别并建模系统中的所有服务为微服务 -- Kubernetes Service，系统最终由多个提供不同业务能力而又彼此独立的微服务单元组成，服务之间通过 TCP/IP 进行通信，从而形成了强大而又灵活的弹性网格，拥有强大的分布式能力、弹性伸缩能力、容错能力，程序架构也变得简单和直观既然每个 Pod 都会被分一个单独的 IP 地址，而且每个 Pod 都提供了一个独立
在 Kubernetes 系统中， Pod 的管理对象 RC、Deployment、DaemonSet 和 Job 都面向 无状态的服务。但现实中很多服务是有状态的，特别是一些复杂的中间件集群，例如 MySQL 集群、MongoDB 集群、Akka 集群、ZooKeeper 集群等，这些 应用集群 有 4 个共同点：每个节点都有固定的身份 ID，通过这个 ID，集群中的成员可以相互发现并通信；集群的规模是比较固定的，集群规模不能随意变动集群中的每个节点都是有状态的，通常会持久化数据到永久存储中如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损。Pod 命名规则注意，通过 RC 或者 Deployment 创建的 Pod 不是完全固定的：通过 RC 创建的 Pod命名为：<rc-name>-xxxxRC 名称是固定部分xxxx 是随机生成的字符串当 Pod 被删除重建时，随机字符串会改变通过 Deployment 创建的 Pod命名为：<deployment-name>-<replicaset-hash>-xxxxdeployment-name
分布式系统要能够根据当前负载的变化 自动 触发水平扩容或缩容，因为这一过程可能是频繁发生的、不可预料的，所以手动控制的方式是不现实的。HPA 与 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。HPA 实现原理通过追踪分析指定 RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要有针对性地调整目标 Pod 的副本数量。HPA 有以下两种方式作为 Pod 负载的度量指标：CPUUtilizationPercentage一个算术平均值，即 目标 Pod 所有副本自身的 CPU 利用率的平均值。一个 Pod 自身的 CPU 利用率是该 Pod 当前 CPU 的使用量 除以 它的 Pod Request 的值eg. 定义一个 Pod 的 Pod Request = 0.4，当前 Pod 的 CPU 使用量为 0.2，那么它的 CPU 使用率是 50%这样可以算出一个 RC 控制的所有 Pod 副本的 CPU 利用率的算术平均值了如果某一时刻 CPUUtilizationPercentage 的值超过 80%，则意味着 当前 Pod 副本数很可能不足以支撑接
Deployment 配置定义文件内容spec 是 Kubernetes YAML 文件中最重要的字段之一，它定义了资源的期望状态（desired state）。对于 Deployment 来说，spec 包含了以下关键配置：apiVersion: apps/v1 # 更新到当前推荐的 API 版本 kind: Deployment metadata: name: frontend spec: # 定义了资源的期望状态 replicas: 1 # Pod 副本数量 selector: # 选择器，用于识别哪些 Pod 是属于这个 Deployment 的 matchLabels: # 简化选择器配置 tier: frontend template: # Pod 模板，定义 Pod 的配置 metadata: labels: # Pod 的标签 app: app-demo tier: frontend spec: # Pod 的详细规格 containers: #
糖呀糖 xyz
我们谈论生活，讨论技术，借由文字，抵达心灵。
