首页 文章 精选 留言 我的

精选列表

搜索[k8s]，共3940篇文章
优秀的个人博客,低调大师

Kubernetes迎来7周年，VMware简化K8s部署与应用的成就与挑战

作为基于容器的分布式管理系统，Kubernetes历经七年发展，生态系统不断壮大，被越来越多的企业投入到生产环境中。Craig McLuckie和Joe Beda是Kubernetes的主要创始人，当初在谷歌内部Kubernetes起步的时候，它的项目名称叫Project 7(七号项目)，这个名字来自于科幻电影Star Trek(星际迷航)提供的灵感，所以在上个月为Kubernetes庆祝的7岁生日，这个“7”是非常有特殊意义的。2016年Craig McLuckie和Joe Beda离开谷歌并创办Heptio，2018年12月，VMware完成了对Heptio的收购，同时两位加入VMware，分别担任VMware应用现代化业务部门研发副总裁和VMware首席工程师。 VMware应用现代化业务部门研发副总裁Craig McLuckie近期在接受记者采访时表示，企业在使用Kubernetes时，通常会遇到来自两个方面的挑战：一是如何能够以一种可扩展的方式迅速运行操作Kubernetes;二是如何让广大开发人员能够轻而易举地用上Kubernetes。基于此，VMware推出了Tanzu Kubernetes Grid(TKG)，很好地帮助用户改善了使用Kubernetes的复杂性。 VMware应用现代化业务部门研发副总裁 Craig McLuckie 应用Kubernetes面临的主要挑战 虽然越来越多的企业开始使用Kubernetes，但在用户使用过程当中，仍然存在一些不友好的地方。 在VMware看来，Kubernetes无论是在部署还是使用过程中，都或多或少地存在着一些问题。Craig McLuckie表示，大部分企业都是以一种更加精细粒度的方式来部署Kubernetes，例如构建很多小规模Kubernetes集群。这种部署模式带来的最大挑战是当企业有了自建Kubernetes集群之后，由于自身技术能力跟不上，不能够对这些集群进行实时升级，无法通过Kubernetes上游项目中的各种创新来进行更新，这就带来了较大的安全隐患。 除此之外，很多开发人员也反映Kubernetes在使用过程中出现了一些复杂性，尤其是Spring方面。Craig McLuckie表示，VMware一直都在支持Spring社区的发展，通过最新调查发现，目前已经有75%的Spring开发者在Kubernetes平台之下运行应用。如果把Kubernetes和Spring结合在一起，不仅能够带来运维方面的便利，而且能够让开发者只需要专注于代码开发，而不需要去关注代码的运行环境，更不需要关注基础架构层面的各种问题。 “我们看到，目前Kubernetes使用者呈现出指数级的增长，与VMware合作的每一个企业都在以某种方式部署Kubernetes，但是很多企业在部署和使用Kubernetes时都会遇到一些问题。”Craig McLuckie表示，借助VMware推出的Tanzu Kubernetes Grid(TKG)，能够让用户更加易于获得和运维。 以Tanzu Kubernetes Grid简化Kubernetes部署与应用 VMware Tanzu Kubernetes Grid(TKG)是VMware Tanzu产品组合的首批产品之一，不仅支持私有云以及VMware Cloud，同时也能够支持目前主流的公有云环境，且支持IaaS环境。 当然，随着越来越多集群运行在不同的云环境中，或者网络边缘之上，VMware还提供了统一的管理工具：Tanzu Mission Control(Tanzu任务控制)，对运行在不同环境中的集群实现统一的管理。 Craig McLuckie表示，Tanzu Mission Control(Tanzu任务控制)是Tanzu技术中非常关键的组成部分，在其全生命周期管理的一系列工具中，包括身份管理、安全能力、配置管理、审计管理、数据保护等等，都能够直接用于支持Kubernetes运维，而且能够通过API实现接入。这样的优势在于，智能化的管理工具让开发者能够如使用Linux一样，轻松应用Kubernetes，使得开发者能够对各种集群进行整合化管理，在整合化集群之上部署应用。 Craig McLuckie强调，通过Tanzu Advanced提供的丰富技术和能力，让Kubernetes更加简单易用，且功能变得更加强大，帮助用户在对现有应用进行现代化管理的同时，更加高效地构建新型应用。 实际上，VMware还在致力于推出容器本地的虚拟化。VMware首席工程师 Joe Beda表示，VMware正在通过不同的方法来实现容器本地的虚拟化。据介绍，在vSphere 7当中已经内置了VMware本地PODs，通过hypervisor来支持Kubernetes Pods，这样能够与部分云供应商提供的容器本地虚拟化是相同的。 VMware首席工程师 Joe Beda “虽然Kubernetes已经走过了七年，但作为一个社区，仍然处于早期发展阶段，在VMware前方还有大量且非常精彩的工作去做，不仅要让Kubernetes的操作运维更加简单易用，而且还要通过Kubernetes，把基于Kubernetes的开源社群创新充分释放出来。”Craig McLuckie表示，VMware Tanzu能够让客户根据现有阶段的能力部署Kubernetes，用Kubernetes补充和增强他们在技术上已经作出的投资，帮助他们对现有应用程序进行现代化改造，按照自己选定的速度和步骤，使得数据中心能够更好地应对各种创新。 可信云原生制品仓库：Harbor 在本场采访活动中，VMware中国研发技术总监、CNCF Harbor开源项目创建人张海宁还详细介绍了来自VMware中国研发中心原创的开源项目：Harbor。实际上，这个项目已经拥有7年的发展历程。 VMware中国研发技术总监、CNCF Harbor开源项目创建人 张海宁 据介绍，Harbor是一个可信云原生制品仓库的产品，最早在2016年开源，是中国原创的第一个CNCF开源项目，也是最早从CNCF毕业的中国开源项目。 张海宁表示，CNCF最新用户调查数据反馈，Harbor在全国生产系统中的用户使用率达到了47%，在所有中国原创CNCF项目中排名第一，得到了用户的高度认可。 虽然是一个开源的项目，但在VMware Tanzu Advanced的产品当中，就包括了很多Harbor的源代码。张海宁告诉记者，在vSphere7中的vRegistry service，能够使用Harbor原生内置的支持容器镜像管理，用户在使用vSphere Kubernetes平台时，可以用vRegistry service自动去获得镜像管理能力，包括镜像扫描、镜像安全保护等等一系列策略。 除此之外，诸如TKG Registry Service企业级Kubernetes产品镜像仓库管理、TMC artifact management service中基于公有云上的Tanzu Mission Control，都是基于Harbor管理能力去实现的。此外，基于中央平台管理多个Kubernetes集群能力的SaaS服务，在国外已经落地，在国内正在尝试今年落地。 张海宁告诉记者，VMware利用Harbor搭建了一个对外使用的容器镜像仓库，能够让合作伙伴快速使用Harbor。同时，在产品和商业化过程中，也加入了Harbor的产品理念，构建了很多对外的服务，取得了非常不错的成绩。 【责任编辑：张诚 TEL：（010）68476606】
2021-07-06
优秀的个人博客,低调大师

Volcano 社区 v1.2.0 正式发布，基于 K8s 的容器批量计算平台

Volcano社区已正式发布v1.2.0版本。此次发布的1.2版本关键特性为支持TDM和SLA插件。 Volcano v1.2 关键特性介绍 SLA插件 SLA（Service Level Agreement）插件支持用户通过为作业定义最大预期等待时长的方式来进行调度优先级排序。 用户可以对单个作业打上名为“sla-waiting-time”的annotation，定义最大预期等待时长。equeue action和allocate action将比较作业的实际等待时长和最大预期等待时长的关系。若已超时，该作业将被直接被标记为“piplined”的状态，获取优先分配资源的权利。JobOrderFn中会根据作业实际等待时间和最大预期等待时间的差值，决定作业调度的排序。 例1 作业的SLA定义 apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: annotations: sla-waiting-time: 1h2m3s // 定义作业最大等待时长为1h2m3s 例2 全局定义作业SLA 用户也可以通过在scheduler的配置文件中定义全局SLA的方式，为所有作业配置SLA。 actions: "enqueue, allocate, backfill" tiers: - plugins: - name: priority - name: gang - name: sla arguments: sla-waiting-time: 1h2m3s // 全局定义作业SLA SLA插件的实现是对v1.1.0版本中作业资源预留特性设计的优化。点此查看该特性的详细设计和实现。 TDM插件 TDM（Time Division Multiplexing）插件的使用场景为：某些节点同时属于Kubernetes集群和Yarn集群，且被分时复用。 为了满足该场景，可提前为复用节点打上“volcano.sh/revocable-zone”标签，并在scheduler配置文件中配置分用时段。打上“volcano.sh/preemptable: true”标签的作业，其所属的Pod也将集成该标签。这类Pod将被优先调度到复用节点上。当复用节点的管理权在集群层面进行切换时（分用时段到期），复用节点上的负载将被驱逐，腾空后的节点纳入到新集群中。 例3 TDM插件在scheduler中的配置 tiers: - plugins: - name: tdm arguments: tdm.revocable-zone.rz1: 1:00-4:00 tdm.evict.period: 1m 其他特性 v1.2.0还新增了和系统稳定性、用户体验、性能优化有关的一些特性，如重构了overcommit插件、当作业更新时同时更新ssh secret、优化了nodeorder插件等。 详情查看https://github.com/volcano-sh/volcano/releases/tag/v1.2.0。 关于 Volcano Volcano 是基于 Kubernetes 构建的批量计算平台，源自于华为云 AI 容器，提供作业管理、批量调度、依赖管理、资源预留等能力，支持包括 TensorFlow、Spark、MPI、Slurm 在内的多个业界主流计算框架，主要帮助用户将 AI、大数据等资源消耗波动大、计算密集型的业务从传统的 Batch、HPC 系统快速迁移到云原生。Volcano 也是 CNCF 首个和唯一的容器批量计算项目。 稿源：华为开源
2021-03-07
优秀的个人博客,低调大师

TeamCity 2020.1 发布：构建步骤的条件、对 K8s 的支持、新的集成与 UI

TeamCity 2020.1 发布了。此版本能够指定构建步骤的条件，可在 Kubernetes 群集中启动构建代理，并与 Azure DevOps 和 Jira Software Cloud 集成。它在多节点设置中为辅助服务器增加了更多功能，带有新的 Slack 通知程序，还对实验性的 UI 进行了许多重大改进。 指定构建步骤的条件 你是否曾经想过在不同的平台上执行不同的命令行脚本，或者将更改在不同的分支中部署到不同的登台服务器？现在，TeamCity 2020.1 允许用户指定构建步骤的条件，并仅在满足条件时执行它们。 集群部署 现在即可直接使用简单且可重复的集群部署。TeamCity 2020.1 允许在 Kubernetes 之上实现可扩展的 CI/CD 架构：可以在需要时自动启动构建代理，执行其工作，然后在构建完成后将其删除。 多服务器 运行多个 TeamCity 服务器并使它们协同工作，有助于提升 CI/CD 的性能和可靠性。通过使用触发器处理扩展辅助服务器的功能并支持 UI 中的用户级操作，新版本改善了 TeamCity 在集群环境中的工作方式。 触发处理 从事大型安装工作的专业人员会触发数百（甚至数千）个触发器，这些触发器会触发 VCS、软件包更新和新工件的更改。为了帮助他们获得最高的性能，TeamCity 现在允许辅助服务器参与此过程，并减轻主服务器的负担。 用户级操作 改进了辅助服务器的 UI，从而可以修改用户配置文件、更改项目和配置的视图、管理构建代理等。 更轻松地部署云构建代理 TeamCity 2020.1 带有一个新选项，可以从 TeamCity 服务器下载预打包的代理分发版。预打包的构建代理不需要在连接到 TeamCity 服务器时进行自我更新，因此可以更快、更直接地创建和更新云镜像。 升级通知 新版本实施了一项新的构建功能，该功能使项目管理员可以为整个团队设置自动警报。可以在构建配置级别上配置新的通知，这样就能够使用 Kotlin DSL 进行编辑、重复使用和共享。 全新的 Slack 通知程序可让你的团队直接在 Slack 中获取有关构建状态的通知。 新的Sakura UI 为了支持经典 TeamCity 的更多用例，版本 2020.1 的实验性 UI 附带了更新的“代理和项目”页面，并允许配置项目侧边栏。 更新说明：https://blog.jetbrains.com/teamcity/2020/05/teamcity-2020-1-conditional-build-steps-support-for-kubernetes-slack-notifier-integration-with-azure-devops-and-jira-software-cloud-and-more/
2020-05-24
优秀的个人博客,低调大师

k8s数据持久化之statefulset的数据持久化，并自动创建PV与PVC

一：Statefulset StatefulSet是为了解决有状态服务的问题，对应的Deployment和ReplicaSet是为了无状态服务而设计，其应用场景包括：1.稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现2.稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现3.有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现4.有序收缩，有序删除（即从N-1到0） 因为statefulset要求Pod的名称是有顺序的，每一个Pod都不能被随意取代，也就是即使Pod重建之后，名称依然不变。为后端的每一个Pod去命名。 从上面的应用场景可以发现，StatefulSet由以下几部分组成： 1.用于定义网络标志的Headless Service（headless-svc：无头服务。因为没有IP地址，所以它不具备负载均衡的功能了。） 2.用于创建PersistentVolumes的volumeClaimTemplates 3.定义具体应用的StatefulSet StatefulSet：Pod控制器。RC、RS、Deployment、DS。 无状态的服务。template（模板）：根据模板创建出来的Pod，它们的状态都是一模一样的（除了名称、IP、域名之外）可以理解为：任何一个Pod，都可以被删除，然后用新生成的Pod进行替换。 有状态的服务：需要记录前一次或者多次通信中的相关时间，以作为下一次通信的分类标准。比如：MySQL等数据库服务。（Pod的名称，不能随意变化。数据持久化的目录也是不一样，每一个Pod都有自己独有的数据持久化存储目录。） 每一个Pod-----对应一个PVC-----每一个PVC对应一个PV。 测试：要求二、以自己的名称创建一个名称空间，以下所有资源都运行在此空间中。用statefuset资源运行一个httpd web服务，要求3个Pod，但是每个Pod的主界面内容不一样，并且都要做专有的数据持久化，尝试删除其中一个Pod，查看新生成的Pod，是否数据与之前一致。 1.基于NFS服务，创建NFS服务。 1.[root@master~]#yum-yinstallnfs-utilsrpcbind2.[root@master~]#mkdir/nfsdatabr/>2.[root@master~]#mkdir/nfsdata3.[root@master~]#vim/etc/exports4./nfsdata*(rw,sync,no_root_squash)5.[root@master~]#systemctlstartnfs-server.servicebr/>4./nfsdata*(rw,sync,no_root_squash)5.[root@master~]#systemctlstartnfs-server.service6.[root@master~]#systemctlstartrpcbind7.[root@master~]#showmount-ebr/>7.[root@master~]#showmount-e8.Exportlistformaster:9./nfsdata* 2.创建RBAC权限vim rbac-rolebind.yaml apiVersion: v1 kind: Namespace metadata: name: lbs-test apiVersion: v1 kind: ServiceAccount 创建rbac授权用户。及定义权限 metadata: name: nfs-provisioner name：lbs-test --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nfs-provisioner-runner name：lbs-test rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["events"] verbs: ["watch", "create", "update", "patch"] - apiGroups: [""] resources: ["services", "endpoints"] verbs: ["get","create","list", "watch","update"] - apiGroups: ["extensions"] resources: ["podsecuritypolicies"] resourceNames: ["nfs-provisioner"] verbs: ["use"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: run-nfs-provisioner subjects: - kind: ServiceAccount name: nfs-provisioner namespace: lbs-test 如没有名称空间需要添加这个default默认否则报错 roleRef: kind: ClusterRole name: nfs-provisioner-runner apiGroup: rbac.authorization.k8s.io 执行yaml文件： 1.[root@masteryaml]#kubectlapply-frbac-rolebind.yaml2.namespace/lbh-testcreated3.serviceaccount/nfs-provisionercreated4.clusterrole.rbac.authorization.k8s.io/nfs-provisioner-runnercreated5.clusterrolebinding.rbac.authorization.k8s.io/run-nfs-provisionercreated 3.创建Deployment资源对象。 [root@master yaml]# vim nfs-deployment.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nfs-client-provisioner name：lbs-test spec: replicas: 1#副本数量为1 strategy: type: Recreate#重置 template: metadata: labels: app: nfs-client-provisioner spec: serviceAccount: nfs-provisioner#指定账户 containers: - name: nfs-client-provisioner image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner使用的是这个镜像。 volumeMounts: - name: nfs-client-root mountPath: /persistentvolumes#指定容器内的挂载目录 env: - name: PROVISIONER_NAME#容器内置变量 value: bdqn#这是变量的名字 - name: NFS_SERVER value: 192.168.1.1 - name: NFS_PATH#指定Nfs的共享目录 value: /nfsdata volumes:#指定挂载到容器内的nfs路径与IP - name: nfs-client-root nfs: server: 192.168.1.1 path: /nfsdata 执行yaml文件，查看Pod：1.[root@masteryaml]#kubectlapply-fnfs-deployment.yamlbr/>1.[root@masteryaml]#kubectlapply-fnfs-deployment.yaml2.deployment.extensions/nfs-client-provisionercreated3.[root@masteryaml]#kubectlgetpod-nlbs-testbr/>3.[root@masteryaml]#kubectlgetpod-nlbs-test4.NAMEREADYSTATUSRESTARTSAGE5.nfs-client-provisioner-5d88975f6d-wdbnc1/1Running013s 4.创建Storageclass资源对象（sc）： root@master yaml]# vim sc.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: sc-nfs namespace：lbs-test #名称空间 名 provisioner: lbs-test#与deployment资源的env环境变量value值相同 reclaimPolicy: Retain #回收策略 执行yaml文件，查看SC：1.[root@masteryaml]#kubectlapply-fsc.yamlbr/>1.[root@masteryaml]#kubectlapply-fsc.yaml2.storageclass.storage.k8s.io/sc-nfscreated3.[root@masteryaml]#kubectlgetsc-nlbs-testbr/>3.[root@masteryaml]#kubectlgetsc-nlbs-test4.NAMEPROVISIONERAGE5.sc-nfslbs-test8s 5.创建StatefulSet资源对象，自动创建PVC： vim statefulset.yaml apiVersion: v1 kind: Service metadata: name: headless-svc namespace: lbs-test labels: app: headless-svc spec: ports: - port: 80 name: myweb selector: app: headless-pod clusterIP: None --- apiVersion: apps/v1 kind: StatefulSet metadata: name: statefulset-test namespace: lbs-test spec: serviceName: headless-svc replicas: 3 selector: matchLabels: app: headless-pod template: metadata: labels: app: headless-pod spec: containers: - image: httpd name: myhttpd ports: - containerPort: 80 name: httpd volumeMounts: - mountPath: /mnt name: test volumeClaimTemplates: 这个字段：自动创建PVC - metadata: name: test annotations: //这是指定storageclass，名称要一致 volume.beta.kubernetes.io/storage-class: sc-nfs spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Mi 执行yaml文件，查看Pod：1.[root@masteryaml]#kubectlapply-fstatefulset.yamlbr/>1.[root@masteryaml]#kubectlapply-fstatefulset.yaml2.service/headless-svccreated3.statefulset.apps/statefulset-testcreated4.[root@masteryaml]#kubectlgetpod-nlbs-testbr/>3.statefulset.apps/statefulset-testcreated4.[root@masteryaml]#kubectlgetpod-nlbs-test5.NAMEREADYSTATUSRESTARTSAGE6.nfs-client-provisioner-5d88975f6d-wdbnc1/1Running022m 7.statefulset-test-01/1Running08m59s8.statefulset-test-11/1Running02m30s9.statefulset-test-21/1Running0109s **查看是否自动创建PV及PVC** PV： 1.[root@masteryaml]#kubectlgetpv-nlbs-test 2.NAMECAPACITYACCESSMODESRECLAIMPOLICYSTATUSCLAIMSTORAGECLASSREASONAGE 3.pvc-0454e9ad-892f-4e39-8dcb-79664f65d1e5100MiRWODeleteBoundlbh-test/test-statefulset-test-2sc-nfs4m23s 4.pvc-2cb98c60-977f-4f3b-ba97-b84275f3b9e5100MiRWODeleteBoundlbh-test/test-statefulset-test-0sc-nfs11m 5.pvc-99137753-ccd0-4524-bf40-f3576fc97eba100MiRWODeleteBoundlbh-test/test-statefulset-test-1sc-nfs5m4s PVC： 1.[root@masteryaml]#kubectlgetpvc-nlbs-test 2.NAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGE 3.test-statefulset-test-0Boundpvc-2cb98c60-977f-4f3b-ba97-b84275f3b9e5100MiRWOsc-nfs13m 4.test-statefulset-test-1Boundpvc-99137753-ccd0-4524-bf40-f3576fc97eba100MiRWOsc-nfs6m42s 5.test-statefulset-test-2Boundpvc-0454e9ad-892f-4e39-8dcb-79664f65d1e5100MiRWOsc-nfs6m1s 查看是否创建持久化目录： 1.[root@masteryaml]#ls/nfsdata/2.lbh-test-test-statefulset-test-0-pvc-2cb98c60-977f-4f3b-ba97-b84275f3b9e53.lbh-test-test-statefulset-test-1-pvc-99137753-ccd0-4524-bf40-f3576fc97eba4.lbh-test-test-statefulset-test-2-pvc-0454e9ad-892f-4e39-8dcb-79664f65d1e5 6.在pod资源内创建数据。并访问测试。 1.[root@masteryaml]#cd/nfsdata/ 2.[root@masternfsdata]#echo111>lbs-test-test-statefulset-test-0-pvc-2cb98c60-977f-4f3b-ba97-b84275f3b9e5/index.html 3.[root@masternfsdata]#echo222>lbs-test-test-statefulset-test-1-pvc-99137753-ccd0-4524-bf40-f3576fc97eba/index.html 4.[root@masternfsdata]#echo333>lbs-test-test-statefulset-test-2-pvc-0454e9ad-892f-4e39-8dcb-79664f65d1e5/index.html 5.[root@masternfsdata]#kubectlgetpod-owide-nlbs-test 6.NAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATES 7.nfs-client-provisioner-5d88975f6d-wdbnc1/1Running030m10.244.2.2node02<none><none> 8.statefulset-test-01/1Running017m10.244.1.2node01<none><none> 9.statefulset-test-11/1Running010m10.244.2.3node02<none><none> 10.statefulset-test-21/1Running09m57s10.244.1.3node01<none><none> 11.[root@masternfsdata]#curl10.244.1.2 12.111 13.[root@masternfsdata]#curl10.244.2.3 14.222 15.[root@masternfsdata]#curl10.244.1.3 16.333 7.删除其中一个pod，查看该pod资源的数据是否会**重新创建并存在。** 1.[root@master~]#kubectlgetpod-nlbs-test 2.NAMEREADYSTATUSRESTARTSAGE 3.nfs-client-provisioner-5d88975f6d-wdbnc1/1Running033m 4.statefulset-test-01/1Running020m 5.statefulset-test-11/1Running013m 6.statefulset-test-21/1Running013m 7.[root@master~]#kubectldeletepod-nlbs-teststatefulset-test-0 8.pod"statefulset-test-0"deleted **9.删除后会重新创建pod资源** 10.[root@master~]#kubectlgetpod-nlbs-test-owide 11.NAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATES 12.nfs-client-provisioner-5d88975f6d-wdbnc1/1Running035m10.244.2.2node02<none><none> 13.statefulset-test-01/1Running051s10.244.1.4node01<none><none> 14.statefulset-test-11/1Running015m10.244.2.3node02<none><none> 15.statefulset-test-21/1Running014m10.244.1.3node01<none><none> **数据依旧存在。** 16.[root@master~]#curl10.244.1.4 17.111 18.[root@master~]#cat/nfsdata/lbs-test-test-statefulset-test-0-pvc-2cb98c60-977f-4f3b-ba97-b84275f3b9e5/index.html 19.111 StatefulSet资源对象，针对有状态的服务的数据持久化测试完成。通过测试，即使删除Pod，重新生成调度后，依旧能访问到之前的持久化数据。
2020-02-25
优秀的个人博客,低调大师

Kubernetes 实战教学，手把手教您如何在 K8s 平台上使用 Compose（一）

出品丨Docker公司（ID：docker-cn）编译丨小东每周一、三、五，与您不见不散！ 用过 Kubernetes 的用户都知道 Kubernetes API 真的非常庞大。在最新的版本中，从 Pods 和 Deployments 到 Validating Webhook Configuration 和 ResourceQuota，超过 50 个一级对象。如果您是开发人员，我确信这会很容易导致群集配置时出现紊乱。因此，需要一种简化的方法（如 Swarm CLI / API）来部署和管理在 Kubernetes 集群上运行的应用程序。 在 Dockercon 的第二天，Docker 在 Kubernetes 项目上开源了 Compose。这个工具无疑可以简化 Kubernetes。如果您不知道，Docker 企业版已经在 Compose File 3.3 版本中启用了这个功能，它可以让您使用相同的 docker-compose.yml 文件进行 Swarm 部署，也可以在部署应用栈时指定 Kubernetes 工作负载。 让我来解释一下这究竟意味着什么？想象一下，您正在使用 Macbook 上运行的 Docker Desktop。 Docker Desktop 提供了为您的开发环境运行单个节点 Swarm 以及 Kubernetes 集群的功能。您可以选择从本地群集切换到云平台上运行的远程 Swarm 或 Kubernetes 群集，如 GKE / AKS。在本地单节点群集（可能是 Minikube 或 Docker Desktop for Mac）中开发代码后，您可能希望在远程云平台上对其进行测试。之前，所有这一切都需要“点击”将环境从本地群集切换到 GKE 或 AKS。现在，您可以使用相同的 Swarm CLI 命令在相同的 Docker Compose 文件中将应用程序部署到云平台。 在我们演示如何实现之前，让我们花一些时间来了解从 Swarm 到 Kubernetes 的映射是如何实现的？从根本上说，Swarm 到 Kubernetes 的1：1映射并不简单。由于应用栈本质上只是 Swarm 服务的列表，因此映射是基于每个服务完成的。根据官方文档，映射 Swarm 服务基本上需要两类 Kubernetes 对象：一类用于部署和扩展容器，另一类用于处理栈内和栈外网络。在 Kubernetes 中，不是操纵单个容器，而是操作一组称为 pod 的容器。Pods 可以根据需要使用不同的控制器来进行部署和扩展。如果声明服务是全局的，则 Kubernetes 上的 Compose 使用 DaemonSet 来部署 pod。 注意:此类服务不能使用持久化卷。如果服务使用卷，则需要使用 StatefulSet。谈到栈内网络，基本上 Kubernetes 没有像 Swarm 那样的网络概念。相反，命名空间中存在的所有 pod 都可以相互联网。为了使 pod 之间的 DNS 名称解析起作用，需要使用 HeadlessService。浏览 https://github.com/docker/compose-on-kubernetes/blob/master/docs/mapping.md 进一步详细了解从 Swarm 到 Kubernetes 的映射。 架 构 Kubernetes 上 Compose 是由服务器端和客户端组件组成。选择此架构是为了能够管理应用栈的整个生命周期。下图是该架构的结构图： REST API 使用 API 服务器聚合向 Kubernetes 客户端公开自定义 API 服务器。 客户端使用声明性 REST API 与服务器通信。它通过将序列化应用栈结构（v1beta2）或 Compose 文件（v1beta1） POST 到 API 服务器来创建应用栈。此 API 服务器将应用栈存储在 etcd 键值存储中。 服务器端架构 在 Kubernetes 上的 Compose 中有两个服务器端组件： Compose API 服务器； Compose 控制器； Compose API 服务器通过添加用于创建和操作应用栈的路径来扩展 Kubernetes API。它负责将应用栈存储在 etcd 键值存储中。 它还包含将 v1beta1 代表转换为 v1beta2 的逻辑，因此 Compose 控制器只需要处理应用栈的一个代表。 Compose 控制器负责将堆栈结构（v1beta2 模式）转换为 Kubernetes 对象，然后将当前的集群状态与所需的集群状态进行协调。它通过与 Kubernetes API 交互来实现这一点，它是一个 Kubernetes 客户端，可以监视有趣的事件并操纵较低级别的 Kubernetes 对象。 在下一篇文章中，我将展示如何在 Kubernetes 上运用 Compose 的实战演示。
2019-02-15
优秀的个人博客,低调大师

容器平台选型的十大模式：Docker、DC/OS、K8S 谁与当先？【转】

网易企业服务2017-10-13 无论是在社区，还是在同客户交流的过程中，总会被问到到底什么时候该用 Docker？什么时候用虚拟机？如果使用容器，应该使用哪个容器平台？ 显而易见，我不会直接给大家一个答案，而是希望从技术角度进行分析具体的场景。例如客户是大公司还是小公司，将部署小集群还是大集群，倾向于私有云还是公有云，已经采购了 IaaS 还是没有 IaaS，IT 运维能力强还是弱，是否需要物理机、虚拟机、容器的混合部署，是一般的并发系统还是高并发，这里面所应该做的技术选型都不一样。举个例子，如果你是一个初创型的主营业务非 IT 的小公司，自然不应该花大力气在数据中心里面自己搭建一套大规模、高并发、高性能的容器平台。 接下来，首先，我们来谈下什么情况下应该使用 Docker 的问题。 如上图所示，左面是我们经常挂在嘴边的所谓容器的优势，但是虚拟机都能一一怼回去。 如果部署的是一个传统的应用，这个应用启动速度慢，进程数量少，基本不更新，那么虚拟机完全能够满足需求。 应用启动慢：应用启动 15 分钟，容器本身秒级，虚拟机很多平台能优化到十几秒，两者几乎看不出差别； 内存占用大：动不动 32G，64G 内存，一台机器跑不了几个； 基本不更新：半年更新一次，虚拟机镜像照样能够升级和回滚； 应用有状态：停机会丢数据，如果不知道丢了什么，就算秒级启动也没有用，照样恢复不了，而且还有可能因为丢数据，在没有修复的情况下，盲目重启带来数据混乱； 进程数量少：两三个进程相互配置一下，不用服务发现，配置不麻烦 如果是一个传统应用，根本没有必要花费精力去容器化，因为白花了力气，享受不到好处。 那么什么情况下，才应该考虑做一些改变呢： 传统业务突然被互联网业务冲击了，应用老是变，三天两头要更新，而且流量增大了，原来支付系统是取钱刷卡的，现在要互联网支付了，流量扩大了 N 倍。 这种情况下就只能：拆。 拆开了，每个子模块独自变化，相互影响变少。 拆开了，原来一个进程扛流量，现在多个进程一起扛。 这被称为微服务。 微服务场景下，进程多，更新快，于是出现 100 个进程，每天一个镜像。 容器乐了，每个容器镜像小，没什么问题，虚拟机哭了，因为虚拟机每个镜像太大了。 所以微服务场景下，可以开始考虑用容器了。 这时虚拟机又怒了，我不用容器了，微服务拆分之后，用 Ansible 自动部署是一样的。 这从技术角度来讲没有任何问题，问题是从组织角度出现的。一般的公司，开发会比运维多得多，开发写完代码就不用管了，环境的部署完全是运维负责，运维为了自动化，写 Ansible 脚本来解决问题。 然而这么多进程，又拆又合并的，更新这么快，配置总是变，Ansible 脚本也要常改，每天都上线，不得累死运维。 所以在如此大的工作量情况下，运维很容易出错，哪怕通过自动化脚本。这时，容器就可以作为一个非常好的工具运用起来。 除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。 这样做的好处就是，虽然进程多，配置变化多，更新频繁，但是对于某个模块的开发团队来讲，这个量是很小的，因为 5-10 个人专门维护这个模块的配置和更新，不容易出错。 如果这些工作量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量也会大非常多。 容器是一个非常好的工具，就是让每个开发仅仅多做 5% 的工作，就能够节约运维 200% 的工作量，并且不容易出错。 然而原来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？ 这就不是技术问题了，其实这就是 DevOps，DevOps 不是不区分开发和运维，而是公司从组织到流程能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。 所以微服务、DevOps、容器是相辅相成，不可分割的。不是微服务，根本不需要容器，虚拟机就能搞定，不需要 DevOps，一年部署一次，开发和运维沟通再慢都能搞定。 所以，容器的本质是基于镜像的跨环境迁移。 镜像是容器的根本性发明，是封装和运行的标准，其它什么 namespace，cgroup，早就有了，这是技术方面。 在流程方面，镜像是 DevOps 的良好工具。 容器是为了跨环境迁移的，第一种迁移的场景是开发、测试、生产环境之间的迁移。如果不需要迁移，或者迁移不频繁，虚拟机镜像也行，但总是要迁移，带着几百 G 的虚拟机镜像，太大了。 第二种迁移的场景是跨云迁移，跨公有云，跨 Region，跨两个 OpenStack 的虚拟机迁移都是非常麻烦，甚至不可能的，因为公有云不提供虚拟机镜像的下载和上传功能，而且虚拟机镜像太大了，一传传一天。 所以跨云场景下，混合云场景下，容器也是很好的使用场景。这也同时解决了仅仅私有云资源不足，扛不住流量的问题。 所以这是我认为的容器的本质，是最终应该使用容器的正确姿势，当然一开始你不一定完全按照这个来。 模式一：公有云虚拟机 适合场景：初创公司，无信息安全担忧 如果您是一家初创公司，人员少，IT 运维能力不足，要部署的系统很少，能够花在 IT 系统上的资金有限，当然应该选择公有云的虚拟机部署，它能够解决您的如下问题： 基层 IT 资源的管理交给公有云平台，公司自身运维人员仅需要基本的 Linux 能力； 少量的部署系统，例如 10 台以下的虚拟机，往往替换一个 war，重启 Tomcat 就能解决，如果稍微虚拟机多一点 10 到 20 台，Ansible 脚本可以很好地解决这个问题； 公有云按量按时收费，可以在花费很少的情况下启动，并且在业务飞速扩展的时候，迅速申请大量虚拟机； 这里所说的信息安全担忧，真的仅仅是心理的担忧，公有云往往有大量的安全机制来保证每个租户的安全隔离，只要用好了这些机制，公有云的安全性绝对大于一般公司自己搭建的数据中心，当客户在说要安全的时候，客户在想什么？ 这篇文章讲到了绝对的端到端解决方案。 这里贴张图说明公有云的安全性： （点击图片放大查看） 公有云为支撑自身高并发业务积累了更强的安全防护能力和更多的安全防护经验： 多线 BGP，外网线路冗余 高吞吐量的 DDoS 外网防护 更完善的防火墙，入侵检测，WAF 更完善的流量清洗规则 公有云为支撑自身高并发业务推出了更安全、更高可靠、更高可用的 PaaS 服务： 数据库： 高可用：主备切换数据零丢失 高可靠：同城双活，异地备份 安全性：访问控制，IP 白名单 对象存储： 高可靠：超大容量，三份备份，异地同步 安全性：访问控制，防盗链 公有云为支撑自身高并发业务推出更完善的监控运维的系统，流程，经验： 完善的监控系统，保障大促期间系统故障的快速定位和排障 保障大促能够极大的提升和训练一支有经验的运维团队 大促的业务层面的数据对运维也是机密的，需要流程保障 道高一尺魔高一丈，公有云为保证自身业务的安全性对云平台不断升级： 越来越强的 DDoS 防护 越来越完善的防火墙规则 最新的云平台安全功能和机制 不断更新的虚拟机和容器镜像建设漏洞 不断更新的病毒库 模式二：无 IaaS，裸用容器 适用场景：初创公司无 IaaS，有信息安全担忧 但是即便如此，还是有初创公司或者初创项目，也许因为心理方面，也许因为合规方面，非常担心信息安全问题，还是希望采取部署在自己机房的方式。 但由于是初创公司，在机房里面一般是不能部署 IaaS，因为 IaaS 平台的运维难度，优化难度更大，没有一个 50 人的团队根本玩不起来，所以一般在使用容器之前，采用的是物理机部署的方式，当物理机数目非常小，比如部署 5 到 10 个应用的时候手动部署或者简单脚本部署就可以，但是一旦到了 20 个应用，手动部署和简单脚本就非常麻烦了： 运维人员比例低，而应用相对较多 部署在同一个物理机上的应用多，配置冲突，端口冲突，互相连接，运维需要一个 excel 去管理，还容易出错 物理机容器被脚本和 Ansible 改的乱七八糟，难以保证环境一致性，重装物理机更加麻烦 不同的应用依赖不同的操作系统和底层包，千差万别 这个时候，可以试一下裸用容器，即在原来的脚本，或者 Ansible 里面，将启动进程，改为使用 Docker run，可以有以下的作用： 配置，端口隔离，冲突减少 基于容器部署，使得环境一致性，安装和删除干干净净 不同的操作系统和底层包，都可以用容器镜像搞定 在这个阶段，最简单的方式就是把容器当做虚拟机来使用，也即先启动容器，然后在里面下载 war 包等，当然也可以更进一步，将 war 包和配置直接打在容器镜像里面，这样需要一个持续集成的流程了，不仅仅是运维的事情，开发也要参与其中。 在这个阶段，网络的模式可以使用桥接打平的方式。 这种方式好处是访问 Docker 和访问物理机一样，可很方便地实现 Docker 里面和物理机里面的互通，兼容原来部署在物理机上的应用。 当然 Bridge 的性能一般，如果性能要求比较高，可使用 SR-IOV 网卡嵌入容器内。 模式三：有 IaaS，裸用容器 适用场景：创新项目，引入 DevOps 流程 有一些公司规模大一些，已经采购了 IaaS，只不过有一些创新的项目需要部署，这种状态下，基本虚拟机已经能够满足需求，而且由于能够运维 IaaS，IT 能力比较强，一般也采用了 Ansible 等部署工具。 这种情况下，使用容器的动力相对比较少，然而容器也是能够带来一定好处的，就是 DevOps。 创新项目迭代速度比较快，如果有比较多的创新项目，对运维的压力也是非常大的，这里的裸用容器和模式二的裸用容器不同的是，不是拿容器当做虚拟机来用，而是将容器当做交付物来用。 虽然容器化对于运维的整个过程来讲改进有限，但是关键就是要开发写一个 Dockerfile，这一点非常重要，意味着运行环境的配置提前到开发，而非直接交到运维，也即上面说的，开发 5% 的工作量增加减少大量运维工作，容器环境原子性升级回滚使得停服时间变短，可以保持开发、测试、运维环境的一致性。 模式四：使用 Docker Swarm Mode 适用场景：发展中公司，中等规模集群 当集群规模超过 50 台时，裸用容器已经非常难受了，因为网络、存储、编排、服务发现等全部要靠自己的脚本或 Ansible 来搞定，是时候引入容器平台了。 当容器平台规模不是很大时，Docker Swarm Mode 还是比较好用的： 集群的维护不需要 Zookeeper，不需要 Etcd，自己内置 命令行和 Docker 是一样的，用起来顺手 服务发现和 DNS 是内置的 Docker Overlay 网络是内置的 总之 docker 帮你料理好了一切，你不用太关心细节，很容易就能够将集群运行起来。 而且可以通过 docker 命令，像在一台机器上使用容器一样使用集群上的容器，可以随时将容器当虚拟机来使用，这样对于中等规模集群，以及运维人员还是比较友好的。 当然内置的太多了也有缺点，就是不好定制化，不好 Debug，不好干预。当你发现有一部分性能不行时，你需要改整个代码，全部重新编译，当社区更新了，合并分支是很头疼的事情。当出现问题时，由于 Manager 大包大揽干了很多活，不知道哪一步出错了，反正就是没有返回，停在那里，如果重启整个 Manager，影响面又很大。 模式五：使用 Marathon 和 Mesos 使用场景：万节点集群，多定制 当集群规模大一些，几百个节点时，很多人就不愿意使用 Docker Swarm Mode 了，很多的选择是既没有用 DC/OS，也没有用 Kubernetes，而是仅仅用了 Marathon 和 Mesos。 因为 Mesos 是一个非常优秀的调度器，它的双层调度机制可以使得集群规模大很多。 Mesos 的调度过程如图所示： Mesos 有 Framework、Master、Agent、Executor、Task 几部分组成。这里面有两层的 Scheduler，一层在 Master 里面，allocator 会将资源公平的分给每一个 Framework，二层在 Framework 里面，Framework 的 scheduler 将资源按规则分配给 Task。 其它框架的调度器是直接面对整个集群，Mesos 的优势在于，第一层调度先将整个 Node 分配给一个 Framework，然后 Framework 的调度器面对的集群规模小很多，然后在里面进行二次调度，而且如果有多个 Framework，例如有多个 Marathon，则可以并行调度不冲突。 详细的调度机制非常复杂，可以看 号称了解 mesos 双层调度的你，先来回答下面这五个问题！这篇文章。 而且 Mesos 的架构相对松耦合，有很多可以定制化的地方，从而运维人员可以根据自己的需要开发自己的模块。详细的定制方式看文章 定制化 Mesos 任务运行的几种方法。 这也是很多优秀的公司使用 Marathon 和 Mesos 的原因。 例如爱奇艺、去哪儿、携程、当当等都选择了使用 Mesos，需要提一下的是，大家如果参加社区，能发现裸用 Marathon 和 Mesos 的很多，但是整个 DC/OS 都用得比较少，而用 Marathon 和 Mesos 往往不能解决一些问题，因而这些 IT 能力非常强的互联网公司做了大量的自己的定制化，增加了 Marathon 和 Mesos 的外围模块。 模式六：使用开源 Kubernetes 使用场景：千节点集群，少定制 Kubernetes 模块划分得更细，模块比较多，比起裸 Marathon 和 Mesos 来讲功能丰富，而且模块之间完全的松耦合，可以非常方便地进行定制化。 而且 Kubernetes 的数据结构的设计层次比较细，非常符合微服务的设计思想。例如从容器->Pods->Deployment->Service，本来简单运行一个容器，被封装为这么多的层次，每个层次有自己的作用，每一层都可以拆分和组合，这样带来一个很大的缺点，就是学习门槛高，为了简单运行一个容器，需要先学习一大堆的概念和编排规则。 但是当需要部署的业务越来越复杂时，场景越来越多时，你会发现 Kubernetes 这种细粒度设计的优雅，使得你能够根据自己的需要灵活的组合，而不会因为某个组件被封装好了，从而导致很难定制。例如对于 Service 来讲，除了提供内部服务之间的发现和相互访问外，还灵活设计了 headless service，这使得很多游戏需要有状态的保持长连接有了很好的方式，另外访问外部服务时，例如数据库、缓存、headless service 相当于一个 DNS，使得配置外部服务简单很多。很多配置复杂的大型应用，更复杂的不在于服务之间的相互配置，可以有 Spring Cloud 或者 Dubbo 去解决，复杂的反而是外部服务的配置，不同的环境依赖不同的外部应用，External Name 这个提供了很好的机制。 包括统一的监控 cadvisor，统一的配置 confgMap，都是构建一个微服务所必须的。 然而 Kubernetes 当前也有一个瓶颈——集群规模还不是多么大，官方说法是几千个节点，所以超大规模的集群，还是需要有很强的 IT 能力进行定制化，这个在模式七中会说一下我们在网易云上做的事情。但是对于中等规模的集群也足够了。 而且 Kubernetes 社区的热度，可以使得使用开源 Kubernetes 的公司能够很快地找到帮助，等待到新功能的开发和 Bug 的解决。 模式七：深入掌握使用 Kubernetes 使用场景：万节点集群，IT 能力强 随着 Kubernetes 使用规模的越来越大，大型的公司可以对 Kubernetes 进行一定的定制化，从而可以实现万节点甚至更大规模的支撑，当然需要 IT 能力比较强，网易在这方面有很多的实践。 从 APIServer 看集群的规模问题 随着集群规模的扩大，apiserver 的压力越来越大。 因为所有的其他组件，例如 Controller、Scheduler、客户端、Kubelet 等都需要监听apiserver，来查看 etcd 里面的变化，从而执行一定的操作。 很多人都将容器和微服务联系起来，从 Kubernetes 的设计可以看出，Kubernetes 的模块设计时非常的微服务化，每个进程都仅仅干自己的事情，而通过 apiserver 的松耦合关联起来。 而 apiserver 则很像微服务中的 api 网关，是一个无状态的服务，可以很好地弹性伸缩。 为了应对 listwatch，apiserver 用了 watchcache 来缓解压力，然而最终的瓶颈还是在 etcd 上。 最初用的是 etcd2，这时候 listwatch 每次只能接受一个事件，所以压力很大。为了继续使用 etcd2，则需要使用多个 etcd2 的集群来解决这个问题，通过不同的租户分配到不同的 etcd2 集群来分担压力。 将来会迁移到 etcd3 有了事件的批量推送，但是从 etcd2 到 etcd3 需要一定的迁移工作。 通过优化 Scheduler 解决并行调度的问题 大的资源池的调度也是一个很大的问题，因为同样一个资源只能被一个任务使用，如果并行调度，则存在两个并行的调度器同时认为某个资源空闲，于是同时将两个任务调度到同一台机器，结果出现竞争的情况。 为了租户隔离，不同的租户是不共享虚拟机的，这样不同的租户是可以参考 Mesos 机制进行并行调度的。因为不同的租户即便进行并行调度，也不会出现冲突的现象，每个租户不是在几万个节点中进行调度，而仅仅在属于这个租户的有限的节点中进行调度，大大提高了调度策略。 并且通过预过滤无空闲资源的 Node，调整 predicate 算法进行预过滤，进一步减少调度规模。 通过优化 Controller 加快新任务的调度速度 Kubernetes 采用的是微服务常使用的基于事件的编程模型。 当有增量事件产生时，则 controller 根据事件进行添加、删除、更新等操作。 但基于事件模型的一个缺点是，总是通过 delta 进行事件触发，过了一段时间，就不知道是否同步了，因而需要周期性地 Resync 一下，保证全量的同步之后，然后再进行增量的事件处理。 然而问题来了，当 Resync 时，正好遇到一个新容器的创建，则所有的事件在一个队列里面，拖慢了新创建容器的速度。 通过保持多个队列，并且队列的优先级 ADD 优于 Update 优于 Delete 优于 Sync，保证相应的实时性。 模式八：深入掌握使用 DC/OS 使用场景：万节点集群，IT 能力强 前面说过 Mesos 由于本身独特的调度机制，从而支撑的集群规模比较大，但是大多数使用 Mesos 的公司都没有使用 DC/OS，而是裸使用 Marathon 和 Mesos 外加自己定制开发的一些组件。 Mesos 可以支持当集群规模非常大，单个 Marathon 的性能不足以支撑时，可以使用自己的 Framework 机制，使得不同的租户使用单独的 Marathon 来解决问题。 后来 DC/OS 在最基础的 Marathon 和 Mesos 之上添加了很多的组件，如图所示，现在已经非常丰富，例如 DCOS 的客户端 (kubectl)、API 网关 admin router (类似 apiserver)、服务发现 minuteman(类似 kube-proxy)、Pod 的支持、CNI 插件的支持、存储插件的支持等，和 Kubernetes 已经非常像了。 很多公司裸用 Marathon 和 Mesos 而没有进一步使用 DC/OS，可能是因为和核心组件 Mesos 已经经过大规模生产性支撑不同，这些外围的组件也是新的，对其稳定性也是有一定的顾虑，所以需要比较长的学习曲线，并且对于这些新的组件有非常好的把控，才敢上生产。 所以从这个角度来讲，虽然 Mesos 的稳定性和大规模无容置疑，但就整个 DC/OS 来讲，和 Kubernetes 从功能和稳定性来讲，在伯仲之间，都需要使用者有强大的 IT 能力，对于开源软件的各个模块非常熟悉，甚至能够做一定的代码修改和 Bug fix，才敢在大规模集群中使用。 模式九：部署大数据，Kubernetes vs. Mesos Mesos 还有一个优势，就是 Mesos 可以通过开发 Framework，构建大数据平台，例如 Spark 就有基于 Mesos 的部署方式。 基于 Mesos 的 Spark 有两种方式，粗粒度和细粒度。 粗粒度模式（Coarse-grained Mode）：应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。组粒度的方式浪费资源。 细粒度模式（Fine-grained Mode）：按需分配，应用程序启动时，先会启动 executor，但每个 executor 占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，mesos 会为每个 executor 动态分配资源，每分配一些，便可以运行一个新任务，单个 Task 运行完之后可以马上释放对应的资源。细粒度的缺点是性能有问题。 其实细粒度模式才是真正能够发挥 Mesos 动态资源调度最有效的方式，但是考虑到有大幅度的性能降低，https://issues.apache.org/jira/browse/SPARK-11857，很可惜这种方式在 Spark 2.0.0 被 deprecated 掉了。 如果使用 kubernetes 部署大数据，其实和部署一个普通的应用思路差不多，和 Mesos 不同，kubernetes 不会干预到大数据运行的上下文中，Kubernetes 启动的容器仅仅作为资源预留方式存在，容器内的资源分配则大数据平台自己解决。这样的利用率就降低了，相当于粗粒度模式。 基于容器部署大数据平台，也是建议部署计算部分，例如 Map-Reduce，或者 Spark，对于数据部分 HDFS，应当另行部署。 模式十：容器和虚拟化混合部署 使用场景：大型公司，逐步容器化 对于很多大公司但是非互联网公司，使用容器还是需要小心对待的，因而需要逐步容器化，所以存在有 IaaS 平台，并且虚拟机和容器混合使用的状态，这种状态可能会持续相当长的时间。 在这种情况下，建议容器套在虚拟机里面使用。 使用 Flannel 和 Calico 都仅仅适用于裸机容器，而且仅仅用于容器之间的互通。 一旦有 IaaS 层，就会存在网络二次虚拟化的问题。 虚拟机之间的互联是需要通过一个虚拟网络的，例如 vxlan 的实现，而使用 Flannel 或者 Calico 相当于在虚拟机网络虚拟化的上面再做一次虚拟化，使得网络性能大幅度降低。 而且如果使用 Flannel 或者 Calico，那容器内的应用和虚拟机上的应用相互通信时，则需要出容器平台，多使用 node port，通过 NAT 的方式访问，或者通过外部负载均衡器的方式进行访问。在现实应用中，不可能一下子将所有的应用全部容器化，只是部分应用容器化，部分应用部署在虚拟机里面是常有的现象。然而通过 NAT 或者外部负载均衡器的方式，对应用的相互调用有侵入，使得应用不能像原来一样相互调用，尤其是当应用之间使用 Dubbo 或者 SpringCloud 这种服务发现机制时，尤其如此。 网易云开发了自己的 NeteaseController，在监听到有新的 Pod 创建时，调用 IaaS 的 API 创建 IaaS 层的虚拟网卡，然后在虚拟机内部，通过调用 Netease CNI 插件将虚拟网卡添加到容器里面。添加技术用的就是上一节提到的 setns 命令。 通过这个图我们可以看出，容器的网卡是直接连接到虚拟私有网络的 OVS 上的，和虚拟机是一个平的二层网络，在 OVS 来看，容器和虚拟机是在同一个网络里面的。 这样一方面没有了二次虚拟化，只有 OVS 一层虚拟化。另外容器和虚拟机网络打平的好处是，当部分应用部署容器、虚拟机时，对应用没有侵入，应用原来如何相互访问，现在还是如何访问，有利于应用逐步容器化。 OpenStack 里面有一个项目 Kuryr 可以很好地去做这件事情，完全使用开源的 OpenStack 和 Kubernetes 可以尝试集成一下。 ！完 ！ 谋胆并重
2018-06-14

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-03-01 大小: 1MB 下载: 6次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2025-12-21 大小: 189MB 下载: 2次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-03-02 大小: 1.42GB 下载: 3次
热门标签
Nacos3 Service Mesh Gemini3 Kubernetes Rocky DeepSeek OpenAi Jdk25 HarmonyOS6 SpringBoot4 Docker Redis SpringCloud

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册