.net程序员网站开发工程师,网站建设招标方案模板,wordpress 内存溢出,跨境电商要投资多少钱走过了突飞猛进的2018年#xff0c;Kubernetes在2019年终于迎来了第一个大动作#xff1a;Kubernetes 1.14版本的正式发布#xff01;Kubernetes 本次发布的 1.14 版本#xff0c;包含了 31 项增强#xff0c;其中 10 项为 GA#xff0c;12 项进入 beta 试用阶段#xf…走过了突飞猛进的2018年Kubernetes在2019年终于迎来了第一个大动作Kubernetes 1.14版本的正式发布Kubernetes 本次发布的 1.14 版本包含了 31 项增强其中 10 项为 GA12 项进入 beta 试用阶段7 个为全新的 alpha 功能。1.14 版本的主题是可扩展性并且支持更多的业务场景其中三个主要的功能具备生产可用一个重要功能进入 beta 试用阶段。总体而言1.14 版本相比之前的版本更着重于将更多的功能推进到稳定状态尤其是部分关键功能对于用户来说具有重大的里程碑意义。
Windows节点支持生产可用
截至目前1.14版本Windows节点支持已经稳定支持将Windows节点作为工作节点并向其调度Windows容器。Windows容器支持的引入允许用户通过Kubernetes的接口界面来体验Windows容器并见证Kubernetes对于Windows容器的价值。在同一集群中同时编排Windows与Linux应用对于拥有混合应用技术栈的企业尤其是传统企业具有里程碑式的意义。
Windows容器关键特性包含
支持Windows Server 2019作为工作节点支持与Azure-CNI、OVN-Kubernetes 和 Flannel等外置容器网络插件对接改进了对Pod、服务类型、工作负载控制器和 metric/quota 的支持使Windows容器基本匹配Linux容器所提供的能力
随着1.14版本的发布Kubernetes已经能为提供相对完善的Windows容器基础功能集但如果考虑端到端商用落地Windows容器商用方案用户仍然不得不关注以下方面的成熟度限制
1、操作系统版本限制Windows容器对Windows系统以及docker版本都有更加严格的要求例如Windows Server 2019/1809需要Docker EE-basic 18.09版本。
2、Hyper-V和Native容器的成熟度整体相对弱于Linux容器Native容器的安全隔离能有限Hyper-V隔离方案仍然是alpha特性需要持续完善而对于依赖GPU、GUI的应用支持较弱相关商用案例也较少。
3、Windows容器镜像生态
当前可用于Windows容器的base image有限主要就是windowsservercore和nanoserver针对实际场景的使用灵活度不高Windows容器的基础镜像尺寸较大而微软的MCR服务(Microsoft Container Registry)尚未明确中国区CDN的上线时间用户往往需要花费较长的时间下载镜像。
4、 网络方面Windows容器目前支持5种不同的网络模式虽然已有一些网络插件宣称可以满足基本的使用要求但性能和成熟度仍需验证。
5、其他限制
控制面master节点目前不能部署在Windows系统中这意味着Kubernetes集群必须包含使用Linux系统的主节点。目前 Windows 容器并不支持 Pod 优雅删除。并且在 Windows 容器环境中对单文件映射、特权容器、大页内存支持、Node Problem Detection 等能力也都没有提供支持。
在1.14版本稳定之后Kubernetes社区将继续完善对Windows容器支持包括但不限于
优化使用kubeadm在Windows环境下安装节点支持Calico CNI网络Hyper-V隔离模式下支持一个Pod内包含多个容器支持Pod优雅删除
kubectl插件机制宣布稳定命令行插件生态蓬勃发展
kubectl插件机制GA
kubectl插件机制允许开发者已独立的二进制的形式发布自定义的kubectl子命令。这可以用于扩展kubectl具有更高级别的功能和附加的porcelain(例如添加set-ns命令)。插件必须具有kubectl-的命名前缀并保存在用户PATH中为了GA插件机制已经被大大简化了。目前有点类似Git的插件系统。
集成kustomize
kustomizehttps://GitHub.com/Kubernetes-sigs/kustomize是K8s社区命令行兴趣小组SIG-CLI的一个子项目致力于为用户提供一种可以重复使用配置的声明式应用管理工具让用户在配置工作中只需要管理和维护kubernetes的原生API对象而不需要使用和管理复杂的模版。
在这次发布的版本中kustomize提供声明式资源配置的创建修改等能力可以kubectl –k参数和kustomize子命令来执行。kustomize使用Kubernetes原生概念帮助用户创建和复用资源配置。用户可以利用 kubectl apply -k dir/将指定目录的kustomization.yaml提交到集群中。用户还可以直接将自定义的资源配置发送到标准输入而不是通过 kubectl kustomize dir/应用。更多的kustomize子命令将会在kustomize代码仓库中继续开发完善用户可以通过更新独立的kustomize二进制文件来体检最新的kustomize特性。 据不完全统计GitHub 上有超过 200 种 kubectl 相关的第三方命令行工具随着 kubectl 插件机制稳定相信这些工具很快会基于插件机制标准化更好地与 kubectl 集成给用户提供强大的扩展命令集。
随本次 Kubernetes 1.14 版本发布的还有全新的 kubectl 文档及 Logo。社区重写了 kubectl 文档并重点聚焦使用声明式的资源配置管理资源。目前 kubectl 文档已作为独立的站点上线地址为https://kubectl.docs.kubernetes.io新的 kubectl Logo 及吉祥物kubee-cuddle也被启用。持久化本地存储卷生产可用
历经漫长的改进持久化本地存储卷特性终于在1.14版本中达到生产可用。
本地持久卷可以使用K8s节点上挂载的本地存储设备作为持久卷的来源。相对于远程磁盘来说持久化本地存储拥有优越的性能使用更少的系统开销更加适合分布式文件系统以及数据库等场景。相比于云盘本地SSD盘比远程磁盘就具有更好的IO性能。相比于裸机除了性能以外本地存储通常更加便宜并且使用它是配置分布式文件系统的必要条件。
虽然本地持久卷特性达到生产可用但是易用性仍然没有得到显著的改进。用户可以通过两种相对手动的方式来使用持久化本地存储特性
用户手动指定块设备的方式提供本地持久卷使用 sig-storage-local-static-provisioner 插件静态维护本地卷的生命周期。
根据Pod及PVC状态自动地维护各节点中本地持久卷的能力仍然需要较长的时间在社区推进。
应用就绪状态判断的改进Pod Readiness Gates (Pod Ready)生产可用
对于Pod的状态Kubernetes为用户提供了两项判断Pod运行情况的能力Readiness就绪状态和Liveness存活状态。一个Pod被判断为Ready就绪意味着所有初始化相关的工作已经完成Pod可以接收处理外部访问的请求。而Liveness则用于判断已就绪的Pod是否持续处于正常工作中。
然而在实际使用中特别是针对大型应用情况往往比较复杂。由于K8s中大量采用的异步机制、以及多种对象关系设计上的解耦当应用实例数增加/删除、或者应用版本发生变化触发滚动升级时系统并不能保证应用相关的Service、负载均衡器配置总是及时完成刷新。在一些情况下往往只是新的Pod完成自身初始化系统尚未完成Endpoint、负载均衡器等外部可达的访问信息刷新老的Pod就立即被删除最终造成服务不可用。这对用户来说是不可接受的。
Pod Ready的引入正是为了修正Pod就绪状态的判断机制——用户可以通过 ReadinessGates 自定义Pod就绪的条件如从外部访问入口判断新建的Pod开始处理外部请求当用户自定义的条件以及容器状态都就绪时kubelet才会标记Pod准备就绪。
在1.14版本中Pod ready特性达到了稳定用户可以在生产系统中直接使用该特性。需要注意的是对于用户自定义的就绪条件一定需要有自定义的控制器配合更新Pod状态否则Pod永远不会变成就绪状态。
Pod优先级与抢占式调度生产可用
Pod优先级与抢占可以使K8s调度器在集群资源耗尽的情况下优先调度更加重要的Pod并且驱逐集群中正在运行的相对不重要的Pod为更重要的Pod腾出资源。Pod的重要性通过PriorityClassName定义其中\u0026quot;system-node-critical\u0026quot; 和 “system-cluster-critical” 是两个特殊的最高优先级的关键词。优先级低的Pod在资源不足时容易首先被驱逐因而对于重要的daemonset或者重要的应用组件用户可以设置较高的优先级防止被抢占。
要使用优先级与抢占管理员必须开启Priority Admission Controller。用户在为Pod设置PriorityClassName时必须指向集群中已创建的PriorityClass对象否则Pod创建失败。
PID限制beta试用阶段
进程ID (PID) 是Linux主机基本的资源以往K8s没有任何措施限制容器内的进程创建PID如果PID资源耗尽即使其他的资源充足也可能导致主机不稳定。在引入PID限制特性后K8s管理员可以通过kubelet启动参数–pod-max-pids来设置每个Pod最大可启动的进程数目并通过–system-reserved和–kube-reserved两项参数设置系统预留的PID数目。PID限制特性带来的主要好处有
防止Pod因PID资源匮乏而不能正常运行隔离Pod之间以及Pod与node之间的PID资源
Kubeadm
在高可用集群中自动执行控制面之间的证书复制。*kubeadm join *命令使得用户自定义集群纳管节点的工作流程变为可能。
总结核心趋于稳定面向用户场景开枝散叶
结合最近几次版本发布来看Kubernetes核心的发展越来越趋于稳定1.14版本几乎没有引入大的新特性而是把重点放在了让已有特性的稳定上。正如许多人会说Kubernetes正在变得无聊事实上放眼整个云原生生态面向最终用户的各种落地场景仍有巨大的发展空间许许多多围绕Kubernetes的新项目仍然在如雨后春笋般地涌现而K8s本身一些子项目的动态也开始进入人们的视野不断地被商业落地。相信2019年会是Kubernetes和云原生技术面向用户场景开枝散叶的一年。
