Kubernetes 1.8 更新日志深度解析：安全加固、工作负载 API 演进与生态扩展

教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载2017 年 9 月 28 日发布的 Kubernetes 1.8是该版本迭代历程中承上启下的重要里程碑它让基于角色的访问控制RBAC正式成为 stable 特性把核心工作负载 API 推进到apps/v1beta2并围绕网络策略出站流量、Kubelet 证书轮换、CronJob 与自定义资源定义CRD等能力持续强化集群安全与工作负载支持。本文以本仓库 appendix/kubernetes-1.8-changelog.md 的官方版本记录为主线结合仓库内 concepts 目录下的专题文档与 manifests 中的真实配置清单逐项拆解 1.8 版本的关键特性、适用场景与实战用法帮助读者理解该版本在 Kubernetes 演进史中的定位并直接上手使用这些 API 能力。版本概览从安全到工作负载的全面增强Kubernetes 1.8 发布于 2017 年 9 月 28 日。该版本包含了一系列功能改进与增强同时提升了项目的成熟度与治理模式为 Kubernetes 项目的持续发展奠定了基础。从发布说明的叙述看1.8 版本的更新可以概括为两大主线聚焦安全性RBAC 成为 stable 支持网络策略新增对出站Egress流量的 Beta 支持Kubelet 的 TLS 证书轮换进入 Beta。聚焦工作负载支持通过apps/v1beta2组和版本推动核心工作负载 API 的 Beta 版本为大数据任务提供 Kubernetes 原生支持的 Apache Spark批量工作负载受益于 CronJobs 的 Beta 版本CRD 作为测试版继续演进为 Operator Pattern 提供扩展机制。此外1.8 还带来了一批 Alpha 级预览功能包括 Volume 快照、PV 调整大小、自动 taint、Pod 优先级、kubectl 插件等体现了社区各 SIG 持续为各自领域用户输送新能力的节奏。下文将按照安全性 → 工作负载 → 预览功能 → 版本演进脉络的顺序展开并在每个主题中结合仓库内的专题文档与实际清单进行纵深讲解。聚焦安全性RBAC 稳定化与网络策略增强RBAC 成为 stable动态定义 API 访问策略1.8 版本中基于角色的访问控制RBAC正式成为 stable 支持。RBAC 允许集群管理员动态定义角色以此控制对 Kubernetes API 的访问策略是强化集群内组织和监管安全要求的强大工具。关于 RBAC 的完整使用方式本仓库 concepts/rbac.md 提供了系统性教程。其中要点包括启用方式使用--authorization-modeRBAC启动 API Server。四种顶级类型Role与ClusterRole角色定义权限以纯累加形式累积、RoleBinding与ClusterRoleBinding角色绑定将角色授予用户、用户组或服务账户。作用范围差异Role只能授予某一单一命名空间内资源的访问权限ClusterRole则可授予集群范围资源如 node、非资源 endpoint如/healthz以及跨所有命名空间的命名空间范围资源如 pod。子资源表达资源与子资源用斜线划分例如resources: [pods, pods/log]resourceNames可将get、delete、update、patch等动词限定到具体资源实例但需注意设置了resourceNames后list、watch、create、deletecollection等动词因请求 URL 中不包含资源名而不会被匹配。默认角色体系API Server 会自动创建一组默认的ClusterRole与ClusterRoleBinding包括超级用户角色cluster-admin、面向命名空间的admin/edit/view以及system:前缀的核心组件角色如system:node、system:kube-scheduler与system:controller:前缀的控制器角色。权限升级防护RBAC API 会阻止用户通过编辑角色或角色绑定来升级权限用户在创建/更新角色或绑定前必须已经拥有其中包含的所有权限或获授在特定角色上执行bind操作的权限。仓库 manifests/dashboard/dashboard-rbac.yaml、manifests/heapster/heapster-rbac.yaml 等文件中可以找到 RBAC 在真实组件部署中的绑定示例可作为配置参考。网络策略出站流量过滤的 Beta 支持1.8 版本通过网络策略筛选出站流量Egress的 Beta 支持增强了原本对入站流量Ingress进行过滤的现有能力。RBAC 与网络策略因此并称为强化 Kubernetes 内组织和监管安全要求的两个强大工具。本仓库 concepts/network-policy.md 对 NetworkPolicy 做了完整说明关键点如下作用对象与层级NetworkPolicy 的作用对象是 Pod也可应用到 Namespace 和集群的 Ingress、Egress 流量它作用在 L3/4 层即限制对 IP 地址和端口的访问若需应用层访问限制则要借助如 Istio 这类 Service Mesh。前提条件网络策略必须通过网络插件来实现必须使用支持NetworkPolicy的网络方案如 Calico否则将配置 POST 到 API Server 不会起任何作用。隔离语义默认 Pod 是未隔离的可从任意源接收请求一旦某个网络策略选中了特定 Pod该 Pod 将拒绝所有该策略不允许的连接而 Namespace 中未被选中的 Pod 仍接收所有流量。默认策略通过创建选择所有 Pod 但不允许任何流量的策略空的podSelector可实现命名空间的默认拒绝隔离反之可创建ingress: - {}的策略显式放行所有入站流量。仓库 manifests/weave/scope.yaml 等清单中同样可以观察到网络相关组件与策略的结合使用方式。Kubelet TLS 证书轮换进入 BetaKubelet 的传输层安全性TLS证书轮换在 1.8 中成为 Beta 特性。自动证书轮换减轻了集群安全性运维的负担——集群管理员不再需要手工为每台节点维护与更新证书。结合本仓库 guide/tls-bootstrapping.md 与 concepts/rbac.md 中关于system:node-bootstrapper角色的说明可以看出Kubelet TLS 引导与证书轮换依赖一套完善的 RBAC 权限体系支撑两者共同构成了节点身份管理的安全闭环。聚焦工作负载支持apps/v1beta2 与批量任务apps/v1beta2核心工作负载 API 的 Beta 版本Kubernetes 1.8 通过apps/v1beta2组和版本推动核心工作负载 API 的 Beta 版本涵盖当时版本的Deployment、DaemonSet、ReplicaSet 和 StatefulSet。工作负载 API 是现有工作负载迁移到 Kubernetes以及开发基于 Kubernetes 的云原生应用程序的基石。从版本演进的角度看这一布局在 1.9 中进一步完成apps/v1Workloads API 成为 GAGeneral Availability且默认启用将 DaemonSet、Deployment、ReplicaSet 和 StatefulSet 组合为 Kubernetes 中长期运行的无状态和有状态工作负载的基础参见 appendix/kubernetes-1.9-changelog.md。仓库内的真实清单可以印证工作负载 API 的实际用法manifests/test/web.yaml 演示了 StatefulSet 的经典组合一个名为 nginx 的 Headless ServiceclusterIP: None用于控制网络域一个通过volumeClaimTemplates申请稳定存储的 StatefulSet。manifests/kafka/kafka.yaml 展示了生产级有状态应用的部署范式Headless Servicekafka-svc配合apps/v1beta1StatefulSet3 副本并叠加policy/v1beta1PodDisruptionBudgetminAvailable: 2与 Pod 反亲和podAntiAffinity保证 Kafka 这类有状态服务在滚动更新与故障迁移时的数据安全与可用性。关于 StatefulSet 的完整特性稳定的持久化存储、稳定的网络标识、有序部署/扩展/收缩/删除、自动滚动升级可参见 concepts/statefulset.md其中详细说明了 Pod DNS 命名格式statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local以及删除或 scale 不会删除关联 volume 的数据安全设计。Apache Spark 原生支持与 CronJobs对于那些考虑在 Kubernetes 上运行大数据任务的用户1.8 的工作负载 API 支持运行 Kubernetes 原生支持的 Apache Spark批量工作负载如夜间 ETL 工作则受益于CronJobs的 Beta 版本。本仓库 concepts/cronjob.md 对 CronJob 进行了详细讲解前提条件使用 CronJob 需要集群版本 1.8对于 1.8 的集群可通过启动 API Server 时传递--runtime-configbatch/v2alpha1true开启 batch/v2alpha1 API。核心字段.spec.schedule必需指定任务运行周期格式同 Cron。.spec.jobTemplate必需指定需要运行的任务格式同 Job。.spec.startingDeadlineSeconds可选启动 Job 的期限秒级错过执行时间将被视为失败。.spec.concurrencyPolicy可选并发策略仅限Allow默认允许并发、Forbid前一个未完成则跳过下一个、Replace取消当前运行中的 Job 并替换三者之一该策略只作用于同一 CronJob 创建的 Job。.spec.suspend可选设为true后挂起后续所有执行默认false。.spec.successfulJobsHistoryLimit与.spec.failedJobsHistoryLimit历史限制默认分别为3和1设为0则对应类型的 Job 完成后不保留。限制CronJob 在每次调度运行时间内大概会创建一个 Job 对象特定环境下可能创建两个或一个都不创建因此创建 Job 的操作应该是幂等的CronJob 本身不检查 Pod重试创建 Pod 与成败判定由 Job 负责。删除语义删除 CronJob 不会自动删除已创建的 Job 与 Pod需要列出并删除由该 CronJob 创建的以前缀hello-命名的Job或使用kubectl delete jobs --all清理当前 Namespace 内的全部 Job。仓库中 manifests/kafka 目录下的kafkaGenConfig.sh、server.properties等文件以及 useCases 中的大数据相关主题如 useCases/big-data.md、useCases/running-spark-with-kubernetes-native-scheduler.md可进一步延伸理解 Kubernetes 承载有状态与批量工作负载的实践。CRD 与 Operator Pattern扩展 API 与自动化运维有状态应用自定义资源定义CRD在 Kubernetes 1.8 中依然为测试版但它提供了一种强大的机制来扩展 Kubernetes 和用户定义的 API 对象。CRD 的一个典型用例是通过Operator Pattern自动执行复杂的有状态应用例如键值存储、数据库和存储引擎的部署与运维。随着稳定性持续推进CRD 的验证能力也在不断增强。本仓库 concepts/crd.md 是一份完整的 CRD 上手教程覆盖了从创建到高级主题的全流程创建 CRDCustomResourceDefinition的名称必须符合plural.group格式如crontabs.stable.example.comspec中定义 REST API 组、版本versions[].served开关版本、storage指定唯一存储版本、scopeNamespaced 或 Cluster、namesplural/singular/kind/shortNames。创建后 API Server 会为指定版本创建新的 RESTful 资源路径如/apis/stable.example.com/v1/namespaces/*/crontabs/...可通过监控 CRD 的Established状态确认端点就绪。创建自定义对象自定义对象可包含任意 JSON 的自定义字段如cronSpec、image创建后用kubectl get crontab、kubectl get ct -o yaml管理查看。删除 CRD删除 CRD 会同时删除 RESTful API 端点以及存储其中的所有自定义对象重新创建同名的 CRD 将从空开始。高级主题Finalizer终结器允许控制器实现异步预删除 hook存在终结器时对象无法被硬删除首个删除请求会设置metadata.deletionTimestamp各控制器执行完自己的终结器后对象才被最终删除metadata.deletionGracePeriodSeconds控制轮询更新间隔。Validation验证通过 OpenAPI v3 Schema 校验自定义对象spec.cronSpec必须匹配正则、spec.replicas必须落在minimum/maximum区间等非法值会返回带validation failure list的错误信息部分字段如default、nullable、$ref、uniqueItems: true、additionalProperties: false不可设置可通过--feature-gatesCustomResourceValidationfalse禁用。additionalPrinterColumns自 Kubernetes 1.11 起 kubectl 使用服务器端打印可自定义kubectl get的输出列type支持integer/number/string/boolean/dateformat支持int32/int64/float/double/byte/date/date-time/passwordpriority区分标准视图与-o wide视图。子资源自定义资源支持/status与/scale子资源可通过--feature-gatesCustomResourceSubresourcesfalse禁用/scale子资源要求定义specReplicasPath与statusReplicasPath必需以及labelSelectorPath可选配合 HPA 使用启用后可用kubectl scale命令缩放自定义资源。Category分类通过categories列表将自定义资源归入分组如all即可用kubectl get all一并列出。仓库中 manifests/openebs/openebs-operator.yaml、manifests/sofa-mesh/sofa-mesh-demo.yaml 均包含kind: CustomResourceDefinition的真实定义展示了 CRD 在存储 Operator 与 Service Mesh 场景中的落地形态。此外develop/operator.md、develop/operator-sdk.md、develop/kubebuilder.md 提供了从零开发 Operator 的工具链指引concepts/custom-resource.md 则是阅读 CRD 教程前的预备知识。更多Alpha 预览功能一览除了稳定现有的功能Kubernetes 1.8 还提供了许多预览新功能的 Alpha 版本包括Volume 快照为持久化存储的快照能力奠定基础是数据备份与恢复场景的早期探索。PV 调整大小允许在 PVC 层面动态调整持久卷容量提升存储资源管理的灵活性。自动 taint由系统自动为节点打上污点taint配合 concepts/taint-and-toleration.md 中的调度语义优化工作负载在异常节点上的调度行为。Pod 优先级为 Pod 引入优先级概念支撑关键业务的调度抢占。kubectl 插件允许以插件机制扩展 kubectl 命令增强日常运维体验。这些能力在该版本中尚处 Alpha 阶段不建议直接用于生产但它们清晰勾勒了 Kubernetes 在存储、调度与工具链三个方向上的演进路线图为后续版本的功能毕业提供了铺垫。版本演进脉络1.7 → 1.8 → 1.9将 1.8 放在相邻版本的上下文中观察可以更清楚地看到各特性的生命周期特性Kubernetes 1.7Kubernetes 1.8Kubernetes 1.9Network Policy提升为稳定版新增 Egress出站流量Beta 支持持续演进Kubelet TLS 证书轮换支持客户端/服务器端证书轮换配合 TLS bootstrapping证书轮换成为 Beta—工作负载 APIStatefulSet 更新为 BetaTPR 即将被 CRD 取代apps/v1beta2推动核心工作负载 API Betaapps/v1Workloads API 成为 GA自定义资源TPR 被 CRD 取代1.8 中移除 TPRCRD 仍为测试版验证能力持续增强CRD 校验成为 Beta 且默认启用存储本地存储 AlphaStorageOS 插件Volume 快照、PV 调整大小Alpha 预览容器存储接口CSIAlpha 实现其它API 聚合、CRI 增强、外部准入控制器 AlphaCronJobs BetaSpark 原生支持Windows 支持 BetaIPVS 模式 BetaCoreDNS Alpha上表信息来源于仓库 appendix/kubernetes-1.7-changelog.md 与 appendix/kubernetes-1.9-changelog.md 的对应版本记录。可以看出1.8 承担了安全稳定化 工作负载 API 定型的过渡角色1.7 中宣告的 TPR 弃用第三方资源已被 CRD 取代1.8 中移除也在 1.8 中正式落地而 1.9 则在此基础上完成工作负载 API 的 GA 毕业。仓库配套资源与继续深入要在真实环境中验证或扩展 1.8 版本涉及的各项能力可优先查阅仓库内以下配套内容概念深化concepts/rbac.md、concepts/network-policy.md、concepts/crd.md、concepts/cronjob.md、concepts/statefulset.md 分别对应 1.8 更新日志中提到的五大核心特性均为可独立阅读的完整教程。实战清单manifests/kafka/kafka.yaml有状态 PDB 反亲和、manifests/test/web.yamlHeadless Service StatefulSet volumeClaimTemplates、manifests/openebs/openebs-operator.yamlCRD Operator 形态、manifests/dashboard/dashboard-rbac.yaml 与 manifests/heapster/heapster-rbac.yamlRBAC 绑定实践。工具链与周边guide/tls-bootstrapping.mdKubelet TLS 引导与证书轮换、develop/operator.md 与 develop/operator-sdk.mdOperator Pattern 开发、useCases/big-data.md大数据工作负载。需要说明的是1.8 是 2017 年的历史版本本文所描述的特性状态stable/beta/alpha均以该版本发布时的定义为准当前仓库中的部分专题文档如 concepts/rbac.md标注了基于更早版本撰写的前提读者在实践时应以实际集群版本对应的 API 状态为准注意apps/v1beta2、batch/v1beta1等组版本在现代集群中已被apps/v1、batch/v1取代。理解 1.8 的价值更多在于把握 Kubernetes 安全模型与工作负载 API 的演化逻辑这为阅读后续版本更新日志与上手现代特性提供了完整的历史坐标系。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Kubernetes 1.7 更新日志深度解析安全、有状态负载与 API 可扩展性三大主线Kubernetes 1.7 更新日志深度解析安全、有状态负载与 API 可扩展性三大主线 2017 年 6 月 29 日发布的 Kubernetes 1.7教程云原生容器编排PostCSS 变更日志深度解读从 8.5.26 到 0.1 的演进脉络与安全加固全析PostCSS 变更日志深度解读从 8.5.26 到 0.1 的演进脉络与安全加固全析 PostCSS 是一个用 JavaScript 插件转换 CSS 的工前端前端构建Kubernetes SIG Apps 2025 年度报告深度解读工作负载 API 演进与 AI 原生应用落地Kubernetes SIG Apps 2025 年度报告深度解读工作负载 API 演进与 AI 原生应用落地 本篇指南以 Kubernetes 社区仓库中开源治理文档研发协作上一篇如何快速构建数据科学管道LineaPy 完整入门指南下一篇caddy-l4核心功能解析从基础到高级的Layer 4流量控制技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考