mirror of
https://github.com/kubesphere/website.git
synced 2025-12-26 00:12:48 +00:00
update the page of live
Signed-off-by: faweizhao26 <faweizhao@kubesphere.io>
This commit is contained in:
faweizhao26
parent
ef8d09a62f
commit
38f6d7da22
|
|
@ -65,5 +65,19 @@ https://argo-cd.readthedocs.io/en/stable/operator-manual/secret-management/
|
|||
|
||||
A：helm 和 kustomize 都只是用来管理配置清单的工具；Argo CD 自身是支持 helm 的，使用方法跟 kustomize 一样。但 Argo CD 官方推荐使用 kustomize 方式编排。我认为有两个原因，第一足够简单；第二更接近原生配置清单。
|
||||
|
||||
### Q6：GitHub Argo CD 项目下的 argoproj，argo-workflows，argo-cd 三个项目分别是什么吗? argo-workflows 和 tekton 主要区别？及各自应用的场景？
|
||||
|
||||
> 其他问题请参考[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
A：
|
||||
- argoproj/argoproj： argo 所有项目的子项目
|
||||
- argoproj/argo-workflow: 流程编排引擎项目
|
||||
- argoproj/argo-cd：支持 GitOps 的持续发布工具
|
||||
|
||||
argo-workflow 是流程编排引擎，支持丰富的 pipeline 设计，而 tekton 是基于 pipeline 的一个 Gitops CICD 工具；两者的定位是不同的。
|
||||
|
||||
argo-workflow 侧重流程编排，定义流程节点主要以编写 yaml 配置清单为主，社区 Web UI 主要是查看功能，相对较弱。同类型的流程编排引擎中，腾讯蓝鲸智云的标准运维拥有交互性非常好的 Web UI，而且免费开源，推荐有兴趣的小伙伴安装体验。
|
||||
|
||||
tekton 作为 CI/CD 工具，其实跟 argocd 对标，但其强大的功能，也导致了他的设计较为复杂，使用起来上手难度有点高。CI/CD 方面，推荐使用 gitlab runner 做 CI，或者 github action 做 CI，同时使用 Argo CD 实现 CD 的部分。
|
||||
|
||||
### Q7：Operator 部署 Argo CD，请讲讲其 CR 的主要配置项？
|
||||
|
||||
A：具体配置项需要根据部署需求来添加，官方文档有非常详细的说明，可以作为参考： https://argocd-operator.readthedocs.io/en/latest/usage/basics/
|
||||
|
|
|
|||
|
|
@ -65,4 +65,10 @@ A：本地磁盘性能会好，不涉及网络开销，多副本写入强一致
|
|||
|
||||
A：有对用户做容量限制。
|
||||
|
||||
> 每期直播收集的问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
### Q6：RGW 业务量有多大呢 ？多少文件？
|
||||
|
||||
A: 50 亿+
|
||||
|
||||
### Q7：Ceph 还没有支持 K8s 的对象存储，以后会支持吗？
|
||||
|
||||
A：这个不太清楚，但是实际上还是有很多方法可以去调度，比如 pod 里直接通过 rest api 方式调用，或者直接装个 s3cmd 来使用。
|
||||
|
|
@ -44,27 +44,40 @@ B 站 http://live.bilibili.com/22580654
|
|||
|
||||
### Q1：证书上面的名字问题，比如“张三”的中文名称展示和“Zhang San”展示或者“San Zhang”展示，分别要使用哪些证件才能使用上述的 3 种名字展示？如果想和其他国际认证证书上的“San Zhang”保持一致，需要怎么做？
|
||||
|
||||
报名完成之后，会有一个Preparation Checklist ，其中有一项是verify name，需要填 first name（名） 和 latest name（姓），需要跟考试时使用证件上的英文姓名一致，以“张三”为例：first name （San）；last name（Zhang）。
|
||||
A：报名完成之后，会有一个 Preparation Checklist ，其中有一项是 verify name，需要填 first name（名） 和 latest name（姓），需要跟考试时使用证件上的英文姓名一致，以“张三”为例：first name （San）；last name（Zhang）。
|
||||
|
||||
### Q2：CKS 什么时候会有中文考试？
|
||||
|
||||
CKS 已有中文考试，可通过考试官网查看。
|
||||
A：CKS 已有中文考试，可通过考试官网查看。
|
||||
|
||||
CKA： https://www.cncf.io/certification/cka/
|
||||
|
||||
CKS： https://www.cncf.io/certification/cks/
|
||||
|
||||
### Q3：有模拟的考试环境吗？
|
||||
|
||||
可使用该[平台](https://killer.sh/)，需要付费
|
||||
A：可使用该[平台](https://killer.sh/)，需要付费
|
||||
|
||||
### Q4：有没有任务调度资源调度相关的内容？
|
||||
|
||||
有，相关内容可参考 K8s 官方文档
|
||||
A：有，相关内容可参考 K8s 官方文档
|
||||
|
||||
### Q5：CKA 会考 networkpolicy 相关的题目吗?
|
||||
有，推荐一个有助于理解 networkpolicy 的[网站](https://editor.cilium.io/)： https://editor.cilium.io/
|
||||
|
||||
A：有，推荐一个有助于理解 networkpolicy 的[网站](https://editor.cilium.io/)： https://editor.cilium.io/
|
||||
|
||||
### Q6：CKA 会不会涉及集群搭建? 搭建会不会对 CRI, CNI 有要求?
|
||||
|
||||
可能会考察集群升级或添加节点，kubeadm 的使用要熟练掌握。
|
||||
A：可能会考察集群升级或添加节点，kubeadm 的使用要熟练掌握。
|
||||
|
||||
>其他问题请参考[文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)
|
||||
### Q7：对于备考 CKA 的同学，KCNA 还需要考吗？
|
||||
|
||||
A：已经备考 CKA 的话，可以直接参加 CKA 考试。
|
||||
|
||||
### Q8：CKA会考 etcd 的搭建/备份/扩容/故障处理吗?
|
||||
|
||||
A：会考察 etcd 的备份和还原。
|
||||
|
||||
### Q9：浏览器标签页是不是有数量限制？
|
||||
|
||||
A：一般使用 chrome 进行考试，应该是没有限制的，创建一个专门的书签目录，只需要把跟考试大纲相关的链接存为书签即可，如果相关考题的内容没有存为书签，K8s 官方文档的搜索功能也是很好用的。
|
||||
|
|
@ -58,7 +58,9 @@ A：目前没有特别多的经验，有更多经验之后，我们还会继续
|
|||
### Q4：作为一个 FaaS 平台，采取了什么优化措施，可以减少从用户源码到部署到响应请求整个关键路径上的时间延迟，当服务结束后，会从内存中卸载函数/容器（不严谨说一个函数对应起一个容器）吗？如果过一段时间之后用户又再次进行同样的请求呢，需要重新起容器吗？此外对于横向扩展，即当请求暴增时，有没有优化措施，在其它工作节点快速部署服务，减少时间延迟？
|
||||
|
||||
A：大部分回答 和 回答2 比较类似，不过我们默认函数触发是没有触发不启动，可以理解为 replica 为 0，有需要的我们支持设置默认replica 为 1，还可以延长函数冷却、scaleToZero时间 ；卸载函数/容器 是这样的，每个函数 我们会启动容器，容器里只会有一个函数在运行，运行完之后才接收下一个，不会存在1个容器里同时处理 两个 甚至更多函数，这样会对用户造成比较大的延迟 和 环境污染问题。
|
||||
|
||||
目前没有做类似 cdn 的缓存，我理解的是 请求同一个函数，同样的参数，把结果直接返回这种，因为我们不确定用户是不是幂等接口，所以没有考虑。
|
||||
|
||||
请求暴增的时候，我们目前做的比较多的是限制它不能超过 limit，以防止对被人造成影响，至于函数快速启动，就是 冷启动做的优化了，目前来看一个函数 从没有代码、镜像到启动，6s 左右，还可以接受，没有更多的优化策略。
|
||||
|
||||
|
||||
|
|
@ -69,5 +71,3 @@ A：需要明确的是 FaaS 不是万能的钥匙，对延迟敏感、逻辑复
|
|||
### Q6：CloudIDE 多个用户的函数怎么隔离？
|
||||
|
||||
A：我们的场景是每个用户单独拥有函数，如果你想公开函数，可以选择一个版本，进行公开，但是如果别人使用你的公开模板，这个函数就是他自己的了；CloudIDE 我们采用的是 code server，我们做的比较简单，在镜像里集成一些自己的命令比如 cli，启动的时候挂载每个用户在共享存储上的 path 到 /home/coder；用户打开界面的时候我们会用 agent 做 proxy，需要注意的是 proxy 过程中 使用 argon 设置 cookie 即可，类似 key=$argonxxxxxxxxxx。
|
||||
|
||||
> 每期直播收集的问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
|
@ -59,6 +59,22 @@ A：学习成本不高，只需要懂 yaml 文件即可，极狐GitLab的官方
|
|||
|
||||
A：金丝雀部署的方式有很多种，比如典型的采用 istio 来做，还有 nginx ingress（我记得最新版本是支持的），flagger等都可以。原理大概就是，根据用户配置的流量配置，将来自不同用户的流量根据不同的配置（比如 istio 的 destinationrule，virtualservice 等）导流至后端的服务。
|
||||
|
||||
### Q6：私有化部署可以一直使用吗？
|
||||
答案：私有化部署是自主管理的，用户自行下载安装使用即可，但是用户需要及时更新版本，除了能获取更多新的特性外，还能保证软件的安全性。
|
||||
|
||||
> 其他问题请参考[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
### Q7：离线要怎样部署？
|
||||
|
||||
A：如果是使用 Omnibus 的安装方式，则需要通过某些手段（比如硬盘拷贝）把极狐GitLab 安装包拷贝至离线环境进行安装即可；如果是采用容器化的方式，则需要将所需的镜像导入离线环境，然后安装即可。
|
||||
|
||||
### Q8：CD 是怎么做的？
|
||||
|
||||
A：既可以使用极狐GitLab CI/CD 的 push 模型来完成 CD，也可以借助极狐GitLab的 GitOps 功能来实现 pull 模型下的 CD。
|
||||
|
||||
### Q9：如何实现做 A/B 部署？
|
||||
|
||||
A：没有 A/B 部署的说法，应该是蓝绿部署或者 A/B 测试。A/B 测试是一种测试手段，在测试范畴，但是其前提其实是需要 A B 两套环境，对应不同的版本，可以利用极狐GitLab CI/CD 来完成 A B 两套环境的部署（可以使用极狐GitLab的 Environment 功能来对部署环境做标记，方便部署），然后开展 A/B测试。
|
||||
|
||||
### Q10：Gitlab 是否支持多地私有化部署, 如何解决异地数据同步的问题, 需要注意的有哪些点?
|
||||
|
||||
A：极狐GitLab 在私有化部署下的 GEO 架构，可以实现多地域部署，在保证高可用的同时，还能提高不同操作（clone，push等）的效率。
|
||||
|
||||
|
|
|
|||
|
|
@ -61,5 +61,3 @@ A：默认没有支持这种负载均衡，不过可以自己扩展支持。
|
|||
### Q2：请教一下多数据中心缓存一致性该如何设计，全局单元中的缓存？
|
||||
|
||||
A：多数据中心缓存我认为是可以根据本数据中心建缓存的，因为多数据中心本来就需要路由到特定数据中心取数据，就是把一致性留在本数据中心。只是一个思路哈。
|
||||
|
||||
> 其他问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
|
@ -41,31 +41,68 @@ B 站 http://live.bilibili.com/22580654
|
|||
|
||||
## Q & A
|
||||
|
||||
### Q1：KubeSphere 默认的网关是怎么来的，是 KubeSphere 后端做的吗？在 K8s 资源中未查到，不是很清楚这个默认的网关能解决的问题场景是什么。这个资源怎么查呢？
|
||||
### Q1：KubeSphere默认的网关是怎么来的，是kubesphere后端做的吗？在k8s资源中未查到，不是很清楚这个默认的网关能解决的问题场景是什么。这个资源怎么查呢？
|
||||
|
||||
A：KubeSphere 的网关实际上就是 Nginx Ingress Controller，用户每开启一个新的项目网关，在系统项目（namespace） kubesphere-controls-system 中就可以看到自动生成一个新的 kubesphere-router-xxx 开头的 Deployment 资源，这个 Namespace 包括了集群中所有的网关资源。
|
||||
|
||||
提到网关解决的问题，比如一个典型的例子就是作为一个集群或 Namespace 下不同应用、微服务的统一流量入口对外暴露服务以及管理用户请求，用法跟 Nginx Ingress Controller 类似。
|
||||
|
||||
### Q2：OpenELB 和 MetaLB 区别和优缺点？
|
||||
|
||||
### Q2：OpenELB 和 MetalLB 的区别和优缺点各是什么？
|
||||
A：MetalLB 在近期也加入了 CNCF Sandbox，该项目在 2017 年底发起，经过 4 年的发展已经在社区被广泛采用。OpenELB 作为后起之秀，采用了更加 Kubernetes-native 的实现方式，虽然起步更晚但得益于社区的帮助，已经迭代了 12 个版本并支持了多种路由方式。这篇文章中我们详细介绍了两者对比： https://kubesphere.io/zh/blogs/openelb-joins-cncf-sandbox-project/
|
||||
|
||||
A：MetalLB 在近期也加入了 CNCF Sandbox，该项目在 2017 年底发起，经过 4 年的发展已经在社区被广泛采用。OpenELB 作为后起之秀，采用了更加 Kubernetes-native 的实现方式，虽然起步更晚但得益于社区的帮助，已经迭代了 12 个版本并支持了多种路由方式。这篇文章中我们详细介绍了 [OpenELB 和 MetalLB 的对比](https://kubesphere.io/zh/blogs/openelb-joins-cncf-sandbox-project/)：https://kubesphere.io/zh/blogs/openelb-joins-cncf-sandbox-project/
|
||||
### Q3：MetalLB 使用 ConfigMap 来配置 IP 池, OpenELB 使用 eip 来配置 IP 池的目的，我用 MetalLB 可以很明显看到和使用虚拟 IP(VIP) 访问比较简单不用外置硬件路由器，看 OpenELB 演示还是使用了域名或硬件路由，核心路由协议 BGP，在离线环境无硬件路由下怎样考虑架构。哪个协议性能更好？
|
||||
|
||||
### Q3：能不能简单介绍一下这几种暴露服务的方式在不同业务场景下的使用区分？
|
||||
A: OpenELB 是 K8s LB Service 的实现，它不依赖域名。如果选择 BGP 模式,则需要外部路由器支持 BGP 协议,且需要支持 bgp additional-paths 属性. 如果没有硬件路由的情况，目前只能配置 Layer2 协议。未来 OpenELB 社区会支持更多的协议。
|
||||
|
||||
A：ClusterIP 用于集群内部的服务暴露与通信，适用于开发测试；NodePort 用在四层网络，Ingress 用在七层，而 LoadBalancer 可以结合网关（Ingress Controller）对外暴露 80/443 端口，适合生产环境。具体可以参考文章 [Understanding Kubernetes LoadBalancer vs NodePort vs Ingress](https://platform9.com/blog/understanding-kubernetes-loadbalancer-vs-nodeport-vs-ingress/)。
|
||||
### Q4：能不能简单介绍一下这几种暴露服务的方式在不同业务场景下的使用区分？
|
||||
|
||||
### Q4：KubeSphere 网关默认的 Nginx ingress controller 方案可以替换成其它网关方案吗？比如 APISIX、Traefik、Kong。
|
||||
A: ClusterIP 用于集群内部的服务暴露与通信，适用于开发测试；NodePort 用在四层网络，Ingress 用在七层，而 LoadBalancer 可以结合网关（Ingress Controller）对外暴露 80/443 端口，适合生产环境。具体可以参考文章 [Understanding Kubernetes LoadBalancer vs NodePort vs Ingress](https://platform9.com/blog/understanding-kubernetes-loadbalancer-vs-nodeport-vs-ingress/)。
|
||||
|
||||
A：可以替换成其它网关方案，参考文章：[在 Kubernetes 中安装和使用 Apache APISIX Ingress 网关](https://kubesphere.io/zh/blogs/use-apache-apisix-ingress-in-kubesphere/)。
|
||||
### Q5： 路由表在哪里？上层 BGP 路由在哪里，后期会做可视化路由吗？
|
||||
|
||||
### Q5：通过应用商店部署一个应用，怎么通过 OpenELB 暴露服务？
|
||||
A: 路由表存在于 BGP Peer 上，也就是你的上级路由器，如果路由器不支持 BGP 的话，建议使用 L2 模式。OpenELB 是通过调用 GoBGP 来实现的 BGP 协议，因此可以用过 [GoBGP CLI](https://github.com/osrg/gobgp/blob/master/docs/sources/cli-command-syntax.md) 查看，后期社区会根据用户需求的规模情况来支持可视化路由，也欢迎大家参与这部分的开发贡献。
|
||||
|
||||
A：在创建和配置服务时，外网访问勾选 LB 类型，然后参考官网文档配置修改 OpenELB 的 annotations 即可，本次示例有演示，可观看视频回放。
|
||||
### Q6：Layer 2 模式下，K8s 集群节点虚机的网卡名称不一致，网卡项怎么配置？地址池可以枚举吗？
|
||||
|
||||
A: 可以考虑将 interface 配置为 can_reach:192.168.1.1，这里的 192.168.1.1配置为你的网关地址。具体可以参考官网 [EIP 配置](https://openelb.github.io/docs/getting-started/configuration/configure-ip-address-pools-using-eip/) ；地址池可以枚举。
|
||||
|
||||
### Q7：KubeSphere 网关默认的 Nginx ingress controller 方案可以替换成其它网关方案吗？比如 APISIX、Traefik、Kong？
|
||||
|
||||
A：可以替换成其它网关方案，参考[在 Kubernetes 中安装和使用 Apache APISIX Ingress 网关](https://kubesphere.io/zh/blogs/use-apache-apisix-ingress-in-kubesphere/)。
|
||||
|
||||
### Q8：开启 service 的 LB 类型，选择 OpenELB，service 的注解是必输入项？
|
||||
|
||||
A: 不是必须的，当存在默认的 eip 时，OpenELB 自动处理没有任何主机的 LB 类型的 Service。可以通过给 eip 增加注解 `eip.openelb.kubesphere.io/is-default-eip: true` 将其设置为默认 eip。
|
||||
|
||||
### Q9：配置地址池绑定接口是每个节点都需要绑定吗，还是绑定在某个节点？如果绑定到每个节点 L2 模式下节点接口处于某个 vlan 中，但是各个节点的接口可能不处于同一 vlan 同一个网段。
|
||||
|
||||
A: 可以参考官网 [EIP 配置](https://openelb.github.io/docs/getting-started/configuration/configure-ip-address-pools-using-eip/)。
|
||||
|
||||
### Q10：L2 层不是 mac 地址嘛？和 EIP 有啥关系？
|
||||
|
||||
A: 没有关系。Layer2 模式使用了 ARP 协议；EIP 在配置中可以指定使用的协议，默认情况使用 BGP 协议，可以参考官网 [EIP 配置](https://openelb.github.io/docs/getting-started/configuration/configure-ip-address-pools-using-eip/) 。
|
||||
|
||||
### Q11：OpenELB 需要安装并且创建地址池才能使用，那其他租户或者其他 Namespace 可以使用吗？后续是否考虑将 OpenELB 作为自带应用融入呢？
|
||||
|
||||
A: 其它租户或 Namespace 是可以共用的；在 KubeSphere 3.3.0 中将深度集成 OpenELB，用户在暴露服务时可以直接在界面选择是否使用 OpenELB 来暴露 LB 服务，更加方便易用。
|
||||
|
||||
### Q12：通过应用商店部署一个应用，怎么通过 OpenELB 暴露服务？
|
||||
|
||||
A: 在创建和配置服务时，外网访问勾选 LB 类型，然后参考官网文档配置修改 OpenELB 的 annotations 即可，本次示例有演示。
|
||||
|
||||
### Q13：金丝雀发布和蓝绿发布下，是怎么验证新发布版本的可用性是否有问题的呢？
|
||||
|
||||
A：金丝雀发布和蓝绿发布只是灰度发布的几种技术方案，能够按照不同的发布策略让不同的目标用户人群访问不同版本，但最终的测试方案还是需要开发测试团队来评估，可能需要结合一些第三方的测试工具对不同版本的应用进行接口或 Web 测试，不同类型的应用有不同的测试方法。
|
||||
|
||||
### Q14：手绘图用什么软件做的？
|
||||
|
||||
A：参考 https://excalidraw.com/
|
||||
|
||||
### Q15：公司项目是 vue + java 的，前后端分离，然后使用 KubeSphere，而且私有化的项目下，默认配置的比较单一，这方面会有什么好的建议吗？就是只用内网 IP 的方式访问服务即可，看默认的网关好像还走了 Master 节点，主要对集群稳定性会不会不太好呢，不是需要控流吗，还是会消耗节点资源的吧?
|
||||
|
||||
A：一个项目网关就是一个 Nginx ingress controller，毕竟是无状态应用，资源消耗几乎可以忽略，它跟 Master 节点没有关系，网关也不会影响集群的稳定性；可以通过 KubeSphere 界面的集群网关去监控一下流量和请求的情况。
|
||||
|
||||
> 其他问题请参考[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
||||
## 相关内容参考的链接：
|
||||
|
||||
|
|
|
|||
|
|
@ -70,4 +70,59 @@ A：RemoteTask 包含 Hosts 数组，主要用于 ssh 连接至远程宿主机
|
|||
LocalTask 不包含 Hosts 数组，主要用于运行 kk 的工作节点执行一些本地，不需要连接远程机器的逻辑，如：在终端上显示一个用户确认窗口。
|
||||
两者均实现了TaskInterface这个接口，之后可以再次进行提取抽象。
|
||||
|
||||
> 其他问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
> 其他问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
||||
### Q1：内置负载均衡会考虑 kube-vip 吗？当时未选择 kube-vip 的原因是什么？
|
||||
|
||||
A：内置负载均衡第一版是由 kube-vip 实现的，但是之后发现只能实现高可用，vip 绑定到具体一台 master 节点，所有流量也均会进入这台 master，不能实现负载均衡。
|
||||
|
||||
### Q2：KubeKey 部署的 K8s 集群安装路径（比如 kubelet，kubectl，kubeadm）和a pt get 安装默认路径不一样，后期手工升级有影响，这个差异是预期还是有其他考虑？
|
||||
|
||||
A：建议通过 KubeKey 升级 K8s 集群。与apt默认安装路径不同也是为了使 KubeKey 方便统一管理，尽可能不受环境其他因素影响。
|
||||
|
||||
### Q3：Module、task 是串行还是并行？支持 Module 之间有 DAG 依赖的情况？只能按照 task 数组执行吗？
|
||||
|
||||
A：Module 目前分为包含 task 的 taskModule 和 通过协程启动的 GoroutineModule，但是目前 KubeKey 的流水线中只使用了 taskModule。从设计上来将可以实现 Module 可以实现串行和并行。task 通过 parallel 字段可以控制是否并行执行。DAG 依赖以后考虑可能会支持。目前只能通过 Module 只能按照 task 数组执行，可以通过控制语句或 task 中的 prepare 控制该 task 是否执行。
|
||||
|
||||
### Q4：KubeKey 是否支持一个部署文件可以部署多个 K8s 集群？例如定义一个 K8s 集群集合，指定每个 K8s 集群的配置，是否考虑定义一个 ClusterSet CRD？
|
||||
|
||||
A：KubeKey 未来会考虑结合 cluster-api 来重构 operator 模式，之后会设计集群级别，node 级别等不同的 CRD。
|
||||
|
||||
### Q5：v1.2.0 是否会支持 centos/redhat 8，计划支持时间节点？是否有 Web 界面支持计划？部署后是否有考虑将集群巡检加入 KubeKey 的计划吗？
|
||||
|
||||
A：对于 v1.2.0 版本，我们考虑之后只会 patch 一些修复 bug 的 PR，新的 feature 将仅添加至 v2.0.0 之后的版本。Web 界面和 KubeSphere 社区的集群巡检工具 KubeEye 之后都会考虑集成进 KubeKey。
|
||||
|
||||
### Q6：当一个待部署的集群中同时存在 X86 和 ARM64 机器时，KubeKey 在部署 K8s、Istio 等服务时候是如何处理镜像的？不同机器架构需要不同的 Docker 镜像？
|
||||
|
||||
A：KubeKey 会下载不同架构的二进制文件和镜像，并推送到对应架构的机器。
|
||||
|
||||
### Q7：会出一期关于搭建配置 KubeKey 的开发环境的教程吗，例如早期的搭建 KubeSphere 的教程？
|
||||
|
||||
A：可能之后考虑在 SIG 例会上分享 KubeKey 相关的开发环境配置。
|
||||
|
||||
### Q8：如何参与 KubeKey 开发何在本地进行开发、测试与 debug？
|
||||
|
||||
A：以 Goland 为例，最好有一台 linux 云服务器、虚拟机或者 WSL 作为安装 K8s 的机器。Goland 配置 sftp ，这样可以在保存时将代码同步至 linux 中。linux 上可安装这个远程 debug 工具： https://github.com/go-delve/delve。在 linux 上编译 KubeKey，并通过 debug 工具执行 kk 命令，Goland 上配置 go remote 连接 linux 上的 delve debug 服务，这样将可以在 Goland 中进行断点调试。
|
||||
|
||||
### Q9：RemoteTask 与 LocalTask 有什么区别? 他们的结构体定义重复度很高,是否提取统一?
|
||||
|
||||
A：RemoteTask 包含 Hosts 数组，主要用于 ssh 连接至远程宿主机上执行 linux 命令。
|
||||
|
||||
LocalTask 不包含 Hosts 数组，主要用于运行 KubeKey 的工作节点执行一些本地，不需要连接远程机器的逻辑，如：在终端上显示一个用户确认窗口。
|
||||
|
||||
两者均实现了 TaskInterface 这个接口，之后可以再次进行提取抽象。
|
||||
|
||||
### Q10：如何修改 KubeKey 安装下载的容器镜像？
|
||||
|
||||
A：配置私有仓库，KubeKey 安装集群时指定通过私有仓库进行安装。
|
||||
|
||||
### Q11：precheck 是什么处理逻辑呢？
|
||||
|
||||
A：Task 执行流程主要有三步：
|
||||
1. 初始化。主要是为 runtime 连接对应的宿主机。
|
||||
2. 执行 prepare。若prepare为空则跳过，不为空则执行 prepare 中 PreCheck() 的逻辑。当 PreCheck() 方法返回 true，且error为空时，该 task 接着执行，否则该 task skipped 或 KubeKey 报错退出。
|
||||
3. 执行 action。执行 action 中 Execute() 的逻辑。
|
||||
|
||||
### Q12：如果用 operator 部署，那和 kubeVela 有什么区别？
|
||||
|
||||
A：目前考虑的是 KubeKey 更注重对集群和节点进行管理和操作。
|
||||
|
|
|
|||
|
|
@ -45,12 +45,14 @@ B 站 http://live.bilibili.com/22580654
|
|||
## Q & A
|
||||
|
||||
### Q1：相对于 multus 和 ovs-cni 插件下的 pod 多网卡方案有什么区别？
|
||||
|
||||
A：Kube-ovn 提供了更多高层的功能，例如 subnet，VPC，集群互联等.。
|
||||
|
||||
### Q2：跨主机的 pod 网络与 vxlan 方式效率提升有多少？
|
||||
|
||||
A：我们没有具体测过 vxlan。但是考虑到目前 kube-ovn 的性能几乎和 Calico 持平，而 Calico 是事实优于 flannel/vxlan 的。我认为 Kube-ovn 优化过后的性能会更好些。
|
||||
|
||||
### Q3：使用 Quagga 等软路由软件模拟路由协议 bgp 啥的互联基于 ovn 效果如何？
|
||||
|
||||
A：我们目前优化的是数据面的性能。而 BGP 事实是在做控制面的路由，稳定情况下并不会影响到数据面的情况。
|
||||
|
||||
> 每期直播收集的问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
|
@ -43,7 +43,7 @@ B 站 http://live.bilibili.com/22580654
|
|||
|
||||
## Q & A
|
||||
|
||||
### Q1：EMQ X 的稳定性这块可以更加详细讲讲吗
|
||||
### Q1：EMQ X 的稳定性这块可以更加详细讲讲吗？
|
||||
|
||||
A：高并发和高可用是 EMQ X 的设计目标，为了实现这些目标 EMQ X 中应用了多种技术，比如：利用 Erlang/OTP 平台的软实时、高并发和容错；全异步架构；连接、会话、路由、集群的分层设计；消息平面和控制平面的分离等。EMQ X 支持多节点集群，集群下整个系统的性能会成倍高于单节点，并能在单节点故障时保证系统服务不中断。
|
||||
|
||||
|
|
@ -59,9 +59,14 @@ A：我们数套生产环境均使用 EMQ X 作为 MQTT Broker，使用稳定。
|
|||
|
||||
A：数套生产环境使用下来能够满足我们需求。
|
||||
|
||||
|
||||
### Q5：基于Emqx的扩展和Hook这块用的是什么方案能分享下么？
|
||||
|
||||
A比如我们使用了 CoAP 扩展，在某系弱网络场景下使用 CoAP 作为通信协议；比如使用各种认证机制增强认证能力等。钩子使用详见 [EMQ 文档](https://docs.emqx.cn/enterprise/v4.4/advanced/hooks.html#%E5%AE%9A%E4%B9%89)。
|
||||
|
||||
其他问题请参考[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
### Q6：EMQ X 和 KubeSphere 是什么关系呢？
|
||||
|
||||
A：我们使用 EMQ X 作为 MQTT Broker，使用 KubeSphere 作为集群管理工具。
|
||||
|
||||
### Q7：你们公有云上用的全是 AWS 那套，私有部署是用的开源替代的那套？
|
||||
|
||||
A：不完全是，公有云不仅仅是 AWS，我们还有其他公有云厂商的解决方案；私有部署取决于客户现场情况。
|
||||
|
|
|
|||
|
|
@ -70,6 +70,5 @@ A：
|
|||
|
||||
从您发的错误信息看，报错是因为 operator 依赖的 cert-manager 没安装，如 [guide](https://github.com/vesoft-inc/nebula-operator/blob/master/doc/user/install_guide.md) 里提及，，几个必须的依赖需要先安装，否则一些 CRD 没法识别。
|
||||
|
||||
这里安利一下我写的 [nebula-operator-KIND](https://github.com/wey-gu/nebula-operator-kind)，可以一键把所有需要的东西部署在一个 k8s in docker 内部。
|
||||
这里安利一下我写的 [nebula-operator-KIND](https://github.com/wey-gu/nebula-operator-kind)，可以一键把所有需要的东西部署在一个 K8s in Docker 内部。
|
||||
|
||||
> 其他问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
|
@ -54,4 +54,3 @@ A: OpenFunction 会包含将用户函数转换为可运行应用和将应用构
|
|||
|
||||
A: Functions framework 其实是和 builder 共同协作完成用户函数到应用的转换过程，所以这其中不能靠 functions-framework 单独解决的问题可以交给 builder 协同完成。我们之前在关于 nodejs 函数的 functions-framework 实现中也遇到了这个问题，已经有大致的实现方案。
|
||||
|
||||
> 每期直播收集的问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
|
@ -65,4 +65,14 @@ A：这个看应用场景，ROOK 或者 Ceph 的目的并不是取代传统存
|
|||
|
||||
A：可以通过 rook-ceph-tools 工具容器，使用 ceph 命令创建自定义的 pool。
|
||||
|
||||
> 其他问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
### Q5：rook--ceph 有成熟的压测方案吗？
|
||||
|
||||
A：可以参考红帽相关产品的测试性能方案，关键字搜索 OpenShift Container Storage 或者 OpenShift Data Foundation。
|
||||
|
||||
### Q6：Rook 有成熟的灾后数据恢复方案吗？在 Ceph 中如何取出存储在内的文件？
|
||||
|
||||
A：灾后恢复分为在线恢复和离线恢复，在线恢复建议参考红帽 ROOK 项目的商业开源方案中的 OpenShift Data Foundation 的 Metro-DR 特性，离线恢复可以使用 velero 或其他商业方案。
|
||||
|
||||
### Q7：Ceph和 seaweedfs 比较
|
||||
|
||||
A：Ceph 的发展历史、技术成熟度和支持的接口丰富，是其核心优势！并且，Rook 是 CNCF 的毕业项目。
|
||||
|
|
@ -84,5 +84,3 @@ A：首先源于 KubeSphere 开源社区是一个非常活跃、非常向上的
|
|||
其次我们比较看中 KubeSphere 能够根据企业使用 K8s 管理平台的痛点持续更新新功能。比如从 2.0 到现在最新的 3.1.1 版本，期间演进了很多面向企业级应用的功能，包括多集群管理、多租户、监控、CI/CD 等等，同时对 K8s 周边生态整合非常好。
|
||||
|
||||
另外 KubeSphere 界面简单易上手，无论对于运维还是开发，使用交互都非常方便，可以让企业（尤其是开发人员）更专注于自身业务研发，无需关心集群管理。
|
||||
|
||||
> 其他问题请参考[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
|
|
@ -66,5 +66,3 @@ Kubebuilder 中提供了一个 [EventHandler](https://pkg.go.dev/sigs.k8s.io/con
|
|||
### Q4：Operator 一直监听 CR 的资源还是一直监控的操作 CR 的事件，如果整个 CR 未达到期望状态，但 CR 的资源又一直没有发生改变，此时还会进入 Reconcile 方法吗？
|
||||
|
||||
A：Operator 一直监听 CR 的资源事件。如问题 2 中所述，Kubernetes 除了资源发生改变时会触发事件，还会定时进行同步，即定时触发一个更新事件，此时即使整个 CR 未达到期望状态且 CR 的资源也没有发生改变，还是会进入 Reconcile 方法促使 CR 状态去逼近期望状态。
|
||||
|
||||
> 其他问题请参考[文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)
|
||||
|
|
@ -46,7 +46,7 @@ B 站 http://live.bilibili.com/22580654
|
|||
|
||||
### Q1：Webassembly 会取代 Docker 吗？
|
||||
|
||||
**A：** Webassembly 不会取代 Docker 。我们刚刚讲了，Docker 模拟的是操作系统，WebAssembly 模拟的是进程。这是不同层面的问题。
|
||||
A：Webassembly 不会取代 Docker。我们刚刚讲了，Docker 模拟的是操作系统，WebAssembly 模拟的是进程。这是不同层面的问题。
|
||||
|
||||
WebAssembly 会在什么场景取代 docker 呢？就是今天 docker 不适合，但是又必须要隔离的场景。比如微服务、边缘计算、汽车。Docker 不适合在实时操作系统上运行。但是这个场景需要隔离，需要容器化，目前没有更好的做法。WebAssembly 在这种场景下会取代 docker，在边缘计算上会取代 Docker。
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ WebAssembly 会在什么场景取代 docker 呢？就是今天 docker 不适合
|
|||
|
||||
### Q2：有哪些大型项目目前在使用 WebAssembly？
|
||||
|
||||
**A：**
|
||||
A：
|
||||
要看你怎么定义大型项目，基本上所有的微服务或服务网格项目都有在调研 WebAssembly。
|
||||
|
||||
国外上 production 的有 Fastly、cloudflare、shopify。如果大家对这个议题有兴趣的话，可以来参加 KubeCon North America 的 Cloud Native Wasm Day ，来看看世界范围内的公司怎么使用 WebAssembly。
|
||||
|
|
@ -67,7 +67,7 @@ WebAssembly 会在什么场景取代 docker 呢？就是今天 docker 不适合
|
|||
|
||||
### Q3：Wasm 程序的内存是如何管理的？Dapr 结合的 Wasm 有源码 demo 吗？
|
||||
|
||||
**A：**
|
||||
A：
|
||||
Dapr-Wasm 的源代码： https://github.com/second-state/dapr-wasm。
|
||||
|
||||
Wasm 里的内存管理是比较复杂的问题。其实 Java 当年出来的时候，就是号称用 JVM 在 runtime 解决了内存管理的问题。但是这也带来了很多问题，比如 JVM 非常复杂，实时性很差。
|
||||
|
|
@ -78,7 +78,7 @@ Wasm 里的内存管理是比较复杂的问题。其实 Java 当年出来的时
|
|||
|
||||
### Q4：WasmEdge 是包活的还是每次 fork 的？这里面说的 wasm 隔离性，可以理解为可以限制 cpu、memory 的使用量吗？上面说的图像处理、AI处理，是不是用 serveless 更合适呢？
|
||||
|
||||
**A：**
|
||||
A：
|
||||
在 dapr 这个场景是每次fork ，因为是从 rust 和 go 起的。之所以可以这么干，就是因为 Wasm 启动时间非常短，启动时间是毫秒级的。如果用 docker 的话，程序的响应时间以秒计，但是 WebAssembly 是以毫秒计。
|
||||
|
||||
Wasm 的隔离性是有多种多样的。一个是运行 Wasm 的进程是需要隔离的。在 dapr 这个例子，他提供了一些隔离，一些安全隔离，我可以告诉他，这些进程可以 acess 哪些文件系统，有没有网络。
|
||||
|
|
@ -96,4 +96,33 @@ Wasm 的隔离性是有多种多样的。一个是运行 Wasm 的进程是需要
|
|||
**A：**
|
||||
直接起个进程，要明确进程里跑什么。要么是 Native Client 或是 node.js 或者是 python，那他的区别就在于对语言的选择、安全性以及隔离性的区别。WebAssembly 最终还是一个容器，提供了容器提供的优点，可以管理，可以隔离，有安全性。最重要的是对资源和安全性有了隔离。那如果是直接在进程里跑业务的话，这些东西是没有的。比如说直接在进程里起一个 native application ，如果这个应用出现了什么问题的话，会把系统 crush 掉，而且也能看到其他应用的内存，把其他应用也 crush 掉。
|
||||
|
||||
> 其他问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
### Q6：袁老师讲的这个例子似乎没有用到 Dapr 比较核心的能力，仅仅是启动了一个Dapr service innvocation 的 sidecar 转发了一下 rest 请求到 go 或 rust 程序？
|
||||
|
||||
A：是的，这个 demo 主要是展示在 Dapr 的 sidecar 里怎么去起 WebAssembly runtime，而不是来讲 Dapr 本身应该怎么用。Dapr 有很多 features 与服务可以开一系列专门的讲座来研究讨论。
|
||||
|
||||
### Q7：目前 wasm 调用 js 代码性能牺牲大吗？
|
||||
|
||||
A：这个问题涉及到了我们今天没有讲到的一个问题，怎么在 wasm 里支持 JavaScript。我们把 QuickJS 编译成 WebAssembly 在 WasmEdge 里面支持 JavaScript. https://www.secondstate.io/articles/run-javascript-in-webassembly-with-wasmedge/
|
||||
|
||||
关于 JavaScript 的性能：
|
||||
没有人能和开了JIT的 V8 比 JavaScript 的性能。V8 是我们这个行业的珠穆朗玛峰。但是，现在有一个很有意思的观点，如果把 V8 放到服务端运行，就是 Node 和 Deno 的用法，是不应该开 JIT 的。微软出一个报告，尽管 V8 是最快的 JavaScript 引擎，但是 V8 的安全问题有一大半都是与 JIT 有关的。
|
||||
|
||||
如果把 V8 的 JIT 关了，那就和我们选的 quickjs 性能差不多了。V8在服务端还有一个问题，既不提供管理，也不提供隔离。V8没有现在容器的这一套。容现在在微服务用 V8，都是要套两层，一层是node.js，一层是 docker，把这两层套上来，性能会差很多。
|
||||
|
||||
我不能说 WasmEdge + QuickJS 是最快的 JS 引擎，V8 + JIT 比 WebAssembly 快很多，但是 V8 因为安全问题不开 JIT，并且在外面套上 Node 与 Docker，那速度就和在 WasmEdge 差不多了。
|
||||
|
||||
### Q8：WASI 发展的好慢，为什么？
|
||||
|
||||
A：当年 Java 最重要的标准叫做 EJB 发展也很慢。因为一旦要到制定标准的 groups 去吵架，那就会发展很慢。有兴趣的话可以看下这些 proposal 的 discussion，因为这里有各种各样的公司，不同的人有不同的想法。
|
||||
|
||||
这也是我们为什么要做 WasmEdge 的原因，因为我们等不了。在这个行业里，比我们有名的项目有 wasmtime，这是根正苗红的项目，是 Mozilla 发起的。但是这个项目就发展很慢，因为他们要考虑社区的，他们要在 W3C 的标准里面做，他们做的每件事都要成为社区的标准，所以 wasmtime 对往前走的路，特别小心。比如在 WASI 里面支持网络，这是非常重要的一个 feature，但是一直支持不了。因为大家都在谈论要怎么做。
|
||||
|
||||
我们觉得所谓“标准”是大家做出来的，是社区选择的结果。我们做 WasmEdge 就是想做各种尝试，然后把成功的做法变成标准。
|
||||
|
||||
### Q9：一个进程内能同时跑多个 Wasm 模块么？
|
||||
|
||||
A：理论上是可以的，需要在一个进程里面起多个 Wasm 的线程。wasm 模块之间有一定的隔离，比如可以静态分布内存，可以对网络和文件资源系统进行隔离。比如我可以在一个进程跑三个 Wasm 模块，其中一个 Wasm 模块是有网络的，另外一个模块是不能写文件的，第三个模块是可以写文件，这都是可以的。
|
||||
|
||||
但这里面还有一些技术细节，比如说今天的 WebAssembly 标准不保证线程安全。在一个进程里的多个 Wasm 线程有可能互相干扰。
|
||||
|
||||
答案是可以用，但是不是特别推荐，如果你想这么用的话，欢迎线下讨论场景是什么，我们怎么来更好地支持这件事。
|
||||
|
|
@ -50,5 +50,3 @@ A：这个取决于 Webhook 的类型，`MutatingAdmissionWebhook` 是先于`Val
|
|||
### Q2：Initializers 和 AdmissionWebhook 二者都能实现动态可扩展载入 admission controller，有何区别？
|
||||
|
||||
A：相比之下 AdmissionWebhook 的效率更高，虽然 Initializers 和 `MutatingAdmissionWenhook` 都是串行执行，但是 `ValidatingAdmissionWebhook` 是并行执行的，官方也更推荐使用 AdmissionWebhook。在一些高并发场景 Webhook 会更可靠。
|
||||
|
||||
> 每期直播收集的问题请查看[问题收集文档](https://docs.qq.com/doc/DQ1VMUlhwVVFCY1J0)。
|
||||
Loading…
Reference in New Issue