Kubernetes 1.19：主要创新概述

今天，8月25日，将发布新版本的Kubernetes （总共延迟了将近2个月） -1.19 。遵循博客的传统，我们正在谈论新版本中最重要的变化。







用于制备这种材料的信息是取自该Kubernetes增强跟踪表，更新日志-1.19，在Sysdig概述，以及相关的问题，引入请求，Kubernetes增强提案（KEP）。



让我们从一些一般性的重大创新开始...



随着Kubernetes 1.19的版本中，“支持窗口” Kubernetes版本已经增加到从9个月（即最后3个版本）至1年（即4个版本）。为什么？



事实证明，由于项目开发的速度很高（频繁发布的主要版本），Kubernetes集群管理员没有时间更新其安装。相应的KEP的作者引用了工作组去年年初进行的一项调查，结果显示大约三分之一的Kubernetes用户正在处理生产中正在运行的过时的K8s版本:(





在调查时，当前的Kubernetes版本为1.13，即所有K8s用户1.9和1.10适用于当时不再受支持的发行版。）



因此，假设将Kubernetes版本的支持期延长了三个月-修复了代码中发现的问题的补丁-将确保超过80％的用户将在支持的K8版本上工作（而不是目前假设的50-60％） ）。



另一个重大发展：已开发出 结构化日志的标准...控制平面中的当前日志记录系统无法保证Kubernetes中消息和对象引用的单一结构，这会使此类日志的处理变得复杂。为解决此问题，引入了一种用于日志中消息的新结构，为此klog库已扩展了新方法，该方法提供了用于生成日志的结构化接口，以及用于标识日志中K8s对象的辅助方法。



在迁移到klog v2的同时，执行了向JSON输出日志的新格式的转换，这将简化对日志的请求的执行及其处理。为此，将出现一个标志--logging-format，默认情况下使用旧文本格式。



由于Kubernetes信息库庞大且作者结构化日志记录KEP是现实主义者，并将集中精力将最新颖的信息变为现实。



使用新的klog方法进行日志记录的说明：

klog.InfoS("Pod status updated", "pod", "kubedns", "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kubedns"

klog.InfoS("Pod status updated", "pod", klog.KRef("kube-system", "kubedns"), "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"

klog.ErrorS(err, "Failed to update pod status")

E1025 00:15:15.525108       1 controller_utils.go:114] "Failed to update pod status" err="timeout"

使用JSON格式：

pod := corev1.Pod{Name: "kubedns", Namespace: "kube-system", ...}
klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", "ready")

{
   "ts": 1580306777.04728,
   "v": 4,
   "msg": "Pod status updated",
   "pod":{
      "name": "nginx-1",
      "namespace": "default"
   },
   "status": "ready"
}

另一个重要的（和非常相关的）创新是用于通知已弃用的API机制，实施直接的beta版本（即默认激活的设备）。正如所解释的不断落后产能的作家，在许多Kubernetes，住在不同的国家和不同的时间小号英里的前景。跟踪它们，仔细阅读所有发行说明并手动清理配置/设置几乎是不可能的。



为解决此问题，现在使用不推荐使用的API时，Warning会将标头添加到其响应中，该标头在客户端可以识别（client-go），并且可能会有不同的反应：忽略，重复数据删除，记录。在kubectl实用程序中，他们教了如何将这些消息输出到stderr，如何在控制台中用颜色突出显示该消息，以及如何添加--warnings-as-errors带有自我解释名称的标志。



除此之外，还添加了特殊的指标来报告已弃用的API和审核注释的使用。



最后，开发人员参加 了Beta版本对Kubernetes功能的改进。正如项目经验所表明的那样，API中的某些新功能和更改被“卡在” Beta状态，原因是它们已被自动（默认）激活，并且不需要用户采取进一步措施。



为了防止这种情况的发生，建议 将那些已经处于beta测试状态达6个月（两个版本）并且不满足以下任何条件的功能自动发送到弃用列表：

1. 符合GA标准并晋升为稳定状态；
2. 有一个新的Beta，该旧Beta已过时。

现在，针对Kubernetes 1.19中的其他更改（按其各自的SIG进行分类）。

金库

新的CSIStorageCapacity 对象旨在改善使用CSI卷的Pod的调度过程：它们不会放置在存储空间用尽的节点上。为此，有关可用磁盘空间的信息将存储在API服务器中，并且可供CSI驱动程序和调度程序使用。当前的实施状态为Alpha版本；有关详细信息，请参见KEP。



alpha版本的另一项创新是可以直接在pod规范中定义临时卷，通用临时内联卷（KEP）。临时卷在生成时为特定的窗格创建，并在它们退出时被删除。可以早些定义它们（包括直接在规范中，即通过内联方法），但是现有方法证明了功能本身的一致性，并未涵盖其使用的所有情况。



新机制提供了一个简单的API，以为具有动态配置支持的任何驱动程序定义临时卷（以前，这需要修改驱动程序）。它使您可以使用任何临时卷（如CSI和树内卷EmptyDir），并且还支持另一项新功能（如上所述）-跟踪可用的存储空间。



使用新的临时卷（通用内联）的高级Kubernetes对象的示例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: scratch
          mountPath: /scratch
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: scratch
        ephemeral:
          metadata:
            labels:
              type: fluentd-elasticsearch-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "scratch-storage-class"
            resources:
              requests:
                storage: 1Gi

在这里，DaemonSet控制器创建带有视图名称fluentd-elasticsearch-b96sd的容器，此后将为该容器添加PersistentVolumeClaim fluentd-elasticsearch-b96sd-scratch。



而最后的完全新的存储功能，推出了作为一个alpha版本，是一个新的领域csidriver.spec.SupportsFSGroup为CSI司机表示支持对FSGroup基于权限（KEP）。动机：CSI卷的所有权更改是在将其安装到容器中之前执行的，但并非所有类型的存储都支持此类操作（例如NFS），这就是为什么现在可能导致错误的原因。



直到beta版本（即默认包含）：

• CSI- Azure vSphere ( , Kubernetes);
• Secrets ConfigMaps.

/ Kubelet

Seccomp已被声明为稳定（GA）。特别是，这项工作导致将API中的seccomp转换为字段，而不是声明为过时的注释（新的Kubelets忽略注释）并影响了PodSecurityPolicy。已将新字段添加到



PodSpec中，以允许您设置Pod主机的FQDN（完全合格域名）。目标是改善对Kubernetes中的遗留应用程序的支持。这是作者解释其意图的方式：fqdnInHostname

« Unix Linux-, Red Hat CentOS, FQDN- hostname. , , Kubernetes, . ».

默认设置是false保留旧的（对于Kubernetes）行为。功能状态-Alpha版本，计划在下一版本（1.20）中声明为稳定。



决定放弃Kubelet收集的Accelerator Metrics。建议由外部监视代理程序通过PodResources API收集此类指标。该API本身的创建正是为了从主Kubernetes存储库中删除所有特定于设备的指标，从而使供应商无需更改Kubernetes核心即可实现它们。 PodResources API是beta版（功能由Gate负责KubeletPodResources），并将很快稳定。对于当前版本，放弃过程处于alpha状态，详细信息位于KEP中。



从现在开始，可以在不使用Docker的情况下构建Kubelet：通过这种“没有”的说法，作者意味着不存在任何特定于Docker的代码，并且不依赖Golang软件包docker/docker。该计划的最终目标是实现完全“无docker”（即无Docker依赖）的Kubelet。您可以像往常一样在KEP上阅读有关动机的更多信息。这个机会立即获得了GA资格。



在最新的K8s版本中达到其Beta版的节点拓扑管理器现在可以在容器级别上对资源进行分级。

排程器

在Kubernetes 1.18中，我们写了关于均匀pod分布 （Even Pod Spreading）的全局配置，但是后来决定根据性能测试的结果推迟此功能。她现在处于Kubernetes（处于alpha状态）。



创新的本质是添加了全局约束（DefaultConstraints），该约束允许在更高级别（集群级别）且不仅限于PodSpec（直到topologySpreadConstraints）（直到现在）中规范用于分配pod的规则。默认配置将类似于当前插件DefaultPodTopologySpread：

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

详细信息在KEP中。



与“均匀Pod传播”有关的另一个功能：按故障域（区域，区域，节点等）分布的一组Pod，-从alpha转移到beta（默认情况下启用）。



调度程序中的其他三个功能也实现了类似的“增加”：

• 规划配置文件 （调度的配置文件），提出了在1.18;
• 在PriorityClasses中启用/禁用Pod抢占的选项；
• 配置文件kube-scheduler ComponentConfig。

网路

最终，Ingress资源被声明为稳定的，并且v1在API中具有版本。在这方面，相关文档中已经介绍了许多更新。特别要注意的变化明显，从用户这个PR：例如，有这样的重命名为spec.backend→ spec.defaultBackend，serviceName→ service.name，servicePort→ service.port.number...



的AppProtocol领域的服务和端点，以及在EndpointSlice API 上（KUBE-代理的Linux启动默认情况下使用EndpointSlices，但在Windows中仍为alpha）和SCTP支持。

库贝姆

kubeadm实用程序引入了两个新功能（alpha版本）。



首先是使用补丁来修改kubeadm生成的清单。已经可以使用Kustomize（在Alpha中）对其进行修改，但是kubeadm开发人员决定使用常规修补程序是首选方法（因为Kustomize成为不必要的依赖项，因此不受欢迎）。



现在，它可以应用（通过标记的原始补丁--experimental-patches的kubeadm命令）init，join并且upgrade，以及它们的相位。基于Kustomize的实现（标志--experimental-kustomize）将被弃用并删除。



第二个功能是使用组件配置的新方法与kubeadm合作的。该实用程序会生成，验证，设置默认值，并为诸如Kubernetes和kube-proxy之类的Kubernetes集群组件存储配置（以ConfigMaps的形式）。随着时间的流逝，这显然带来了许多困难：如何区分由kubeadm生成或由用户提交的配置（如果没有，那么如何处理配置迁移）？自动生成了哪些具有默认值的字段，以及哪些字段是有意设置的..



为解决这些问题，提出了大量更改，包括：拒绝设置默认值（这必须由组件本身完成），配置验证的委托本身组件，对每个生成的ConfigMap进行签名等。



对于kubeadm而言，另一个不太重要的功能是称为的功能门PublicKeysECDSA，它具有kubeadm init使用ECDSA证书通过创建群集的功能。kubeadm alpha certs renew还提供了更新现有证书（通过）的方法，但是没有机制可以轻松在RSA和ECDSA之间切换。

其他变化

• GA状态在身份验证领域中具有3个功能：CertificateSigningRequest API，限制节点对某些API的访问（通过准入插件NodeRestriction），Kubelet客户端证书的引导程序和自动更新。
• 通过更改重复数据删除方法，新的Event API也被声明为稳定的（以避免集群因事件而过载）。
• (kube-apiserver, kube-scheduler, etcd ) debian distroless. : , ( — KEP).
• Kubelet Docker runtime target-, TargetContainerName EphemeralContainer ( ).
• « » .status.conditions, API .
• kube-proxy IPv6DualStack Windows ( feature gate).
• 具有不言自明的名称CSIMigrationvSphere（从vSphere的内置-树中-插件迁移到CSI驱动程序）的功能闸已移至Beta版本。
• 对于kubectl run 添加的标志--privileged。
• 新的扩展点已添加到调度程序-中，该扩展点PostFilter在该阶段之后开始Filter。
• Windows上的关键容器支持已达到beta。

依赖关系更改：

• kubeadm中包含的CoreDNS版本-1.7.0；
• cri-tools 1.18.0;
• CNI（容器网络接口）0.8.6；
• etcd 3.4.9;
• Go使用的版本是1.15.0-rc.1。

聚苯乙烯

另请参阅我们的博客：

• « Kubernetes 1.18：主要创新回顾”；
• «Kubernetes 1.17: »;
• «Kubernetes 1.16: »;
• «Kubernetes 1.15: ».