同一个 Pod 中的多个容器能够共享 Pod 级别的存储卷 Volume。Volume 可以被定义为各种类型，多个容器各自进行挂载操作，将一个 Volume 挂载为容器内部需要的目录多容器协作实践解析Pod 内包含两个容器：tomcat 和 busybox，在 Pod 级别设置 Volume"apps-logs"，用于 tomcat 向其中写日志文件，busybox 读日志文件apiVersion: v1 kind: Pod metadata: name: volume-pod spec: containers: - name: tomcat # 第一个容器（主容器）tomcat image: tomcat # 使用 tomcat 镜像 ports: - containerPort: 8080 # 容器内部端口 volumeMounts: - name: app-logs
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
糖呀糖 xyz
我们谈论生活，讨论技术，借由文字，抵达心灵。
