Pod 定义YAML 格式的 Pod 定义文件完整内容如下：apiVersion: v1 # Pod API 版本，v1 是稳定版，String，必选 kind: Pod # 资源类型为 Pod，String，必选 metadata: # 元数据定义，Object，必选 name: string # Pod 的名称，必选，命名规范需要符合 RFC 1035 规范，metadata.name namespace: string # Pod 所属的命名空间，默认值为 default，必选，metadata.namespace labels: # 标签定义 key: value # 标签是 key-value 格式 annotations: # 注解定义 key: value
静态 Pod 由 kubelet 管理的仅存在于特定 Node 上的 Pod。他们不能通过 API Server 进行管理，无法与 RC、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无法对他们进行健康检查。静态 Pod 是 由 kubectl 创建，并总在 kubelet 所在的 Node 上运行。创建静态 Pod - 配置文件方式设置 kubelet 的启动参数 --config，指定 kubelet 需要监控的配置文件所在的目录，kubelet 会定期扫描该目录，并根据该目录下的 .yaml 或 .json 文件进行创建操作。假设配置目录为 /etc/kubelet.d，配置启动参数为 --config=/etc/kubelet.d/ ，然后重启 kubelet 服务。--config=/etc/kubelet.d/ 适用于指定 kubelet 配置文件的参数，不是静态 Pod 的配置文件内容。kubelet 会从该目录中读取配置文件来启动和管理 Pod，这个参数通常用于配置 kubelet 的行为，而不是直接管理静态 Pod静态 Pod 实践检
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 都提供了一个独立
糖呀糖 xyz
我们谈论生活，讨论技术，借由文字，抵达心灵。
