kubectl 用法概述kubectl 命令行的语法如下：kubectl [command] [TYPE] [NAME] [flags]command：子命令，用于操作 Kubernetes 集群资源对象的命令，如 create、delete、describe、get、apply 等TYPE：资源对象的类型，区分大小写，能以单数。复数或简写形式表示，如，以下三种 TYPE 是等价的：kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1NAME：资源对象的名称，区分大小写，如果不指定名称，系统则将返回属于 TYPE 的全部对象的列表flags：kubectl 子命令的可选参数，如使用 -s 指定 API Server 的 URL 地址而不用默认值kubectl 可操作的资源对象类型 及其缩写资源对象类型缩写资源对象类型缩写cluster statefulsets componentstatusescspersistentvolumeclaimspvcconfigmapscmpersistentvolumespvdae
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 副本数很可能不足以支撑接
Luckyxyz
我们谈论生活，讨论技术，借由文字，抵达心灵。
