SuKai

容器如何使用虚拟化网络

由 SuKai in OVN

June 25, 2022

前面文章介绍了Kube-OVN基于OVS/OVN将网络虚拟化带入云原生领域。下面我们通过下面的实验场景来看一下容器如何使用虚拟化网络的，从而了解Kube-OVN的基本工作原理。 实验环境 实验使用的是两台虚拟机：ovn-1为控制节点和计算节点，IP地址为：192.168.0.115。ovn-2为计算节点，IP地址为：192.168.0.114。 实验场景 1，两个主机上进入网络命名空间，配置不同网段进行通信 2，Docker运行容器，通过OVS internal port进行通信 3，Docker运行容器，通过veth pair进行通信 安装部署 #控制节点和计算节点 sudo apt install net-tools sudo apt-get install python-six openssl -y sudo apt-get install openvswitch-switch openvswitch-common -y sudo systemctl disable apparmor #控制节点 sudo apt-get install ovn-central ovn-common ovn-host -y #计算节点 sudo apt-get install ovn-host ovn-common -y 配置ovn 设置ovn数据库允许tcp进行连接，默认只允许socket本地访问。 #控制节点 sudo ovn-nbctl set-connection ptcp:6641:0.0.0.0 -- set connection . inactivity_probe=60000 sudo ovn-sbctl set-connection ptcp:6642:0.0.0.0 -- set connection . inactivity_probe=60000 sudo ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640:192.

继续阅读

Kube-OVN如何实现Pod和主机网络连通

由 SuKai in OVN

June 22, 2022

下面从Kube-OVN代码看一下如何实现Pod和主机网络连通的，再在实验环境中按照Kube-OVN方式进行实验。 | Kube-OVN初始化ovn0 Kube-OVN在主机上添加一个OVS的internal port：ovn0，实现主机和OVS网络的通信。 1，将ovn0连接到OVS集成网桥br-int，类型为internal port，与交换机端口关联。 2，配置ovn0的MAC, IP, MTU并启动接口。 // InitNodeGateway init ovn0 func InitNodeGateway(config *Configuration) error { ... return configureNodeNic(portName, ipAddr, gw, mac, config.MTU) } func configureNodeNic(portName, ip, gw string, macAddr net.HardwareAddr, mtu int) error { ipStr := util.GetIpWithoutMask(ip) raw, err := ovs.Exec(ovs.MayExist, "add-port", "br-int", util.NodeNic, "--", "set", "interface", util.NodeNic, "type=internal", "--", "set", "interface", util.NodeNic, fmt.Sprintf("external_ids:iface-id=%s", portName), fmt.Sprintf("external_ids:ip=%s", ipStr)) if err != nil { klog.Errorf("failed to configure node nic %s: %v, %q", portName, err, raw) return fmt.

继续阅读

Kube-OVN为KubeVirt虚拟机分配固定IP

由 SuKai in kubevirt, kube-ovn

June 19, 2022

KubeVirt虚拟机使用固定IP是生产中比较普遍的一个需求，今天我们一起看一下如何通过Kube-OVN为虚拟机提供固定IP。 配置kube-ovn-controller启动参数 Containers: kube-ovn-controller: Container ID: containerd://0f8d53403c9821c7b535c64d2c98e1ca130a15e1b2b878270cd9388c36d0e48a Image: kubeovn/kube-ovn:v1.11.0 Image ID: docker.io/kubeovn/kube-ovn@sha256:fea623e68a2a81ef78102c6cfe95b96c16c054c57f4c8b9d168bd3ff620b6779 Port: <none> Host Port: <none> Args: /kube-ovn/start-controller.sh --default-cidr=10.244.0.0/16 --default-gateway=10.244.0.1 --default-gateway-check=true --default-logical-gateway=false --default-exclude-ips= --node-switch-cidr=100.64.0.0/16 --service-cluster-ip-range=10.211.0.0/16 --network-type=geneve --default-interface-name= --default-vlan-id=100 --pod-nic-type=veth-pair --enable-lb=true --enable-np=true --enable-eip-snat=true --enable-external-vpc=true --keep-vm-ip=true 创建虚拟机 spec.template.spec.interfaces.macAddress指定虚拟机网卡MAC，每次删除重建这台虚拟机时使用同一个MAC地址，与系统的网卡配置文件/etc/netplan/50-cloud-init.yaml中MAC地址一致，不需要重新进行配置。 spec.template.metadata.annotations中添加两条记录，ovn.kubernetes.io/ip_address指定kube-ovn使用IP，ovn.kubernetes.io/mac_address告诉kube-ovn网卡的MAC地址。 --- apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: labels: kubevirt.io/vm: ubuntu-c name: ubuntu-c namespace: mail263 spec: running: true template: metadata: labels: kubevirt.io/vm: ubuntu-c annotations: ovn.kubernetes.io/ip_address: 172.16.3.203 ovn.kubernetes.io/mac_address: 00:00:00:1F:C5:8F spec: domain: cpu: cores: 4 model: host-passthrough memory: guest: 1Gi devices: disks: - name: bootdisk disk: bus: virtio - disk: bus: virtio name: cloudinitdisk interfaces: - name: default bridge: {} macAddress: 00:00:00:1f:c5:8f resources: overcommitGuestOverhead: true networks: - name: default pod: {} terminationGracePeriodSeconds: 0 volumes: - name: bootdisk dataVolume: name: ubuntuboot-c - name: cloudinitdisk cloudInitNoCloud: userData: |- #cloud-config ssh_pwauth: True chpasswd: list: | ubuntu:ubuntu expire: False 固定MAC

继续阅读

KubeVirt虚拟机资源超卖

由 SuKai in kubevirt, vm

June 18, 2022

使用过虚拟化平台的同学都知道，虚拟化平台可以通过KVM内存ballooning技术动态调整虚拟机的内存配置，实现运行所有VM总内存可以大于物理主机实际内存。当我们在Kubernetes平台通过KubeVirt管理虚拟机时，如何实现资源超卖呢？ 基本概念 KubeVirt资源管理 Kubernetes通过Pod的Resource requests来申请占用资源，根据资源请求量Kubernetes计算主机节点资源进行Pod的调度。默认情况下KubeVirt根据虚拟机VM的资源请求从主机申请资源创建虚拟机virt-launcher Pod，Pod调度后调用libvirt创建对应虚拟机，通过这种方式达到了Kubernetes对虚拟机资源的管理和调度。 通过上面介绍，我们知道KubeVirt可以分开配置Pod的资源request与libvirt虚拟机资源，比如通过设置一个比例来达到虚拟机资源超卖。举例说明，如果我们设置内存超卖比例为150%，创建一个虚拟机内存为3072M，那么Pod请求内存资源则为2048M。假设主机内存为100G，不考虑其他组件资源开销，根据Pod请求则可以创建出内存总量为150G的虚拟机。 但由于KubeVirt目前还不支持Memory Ballooning技术，KubeVirt并没有像KVM调用libvirt获取当前内存使用量，动态调整libvirt中虚拟机分配内存。所以KubeVirt中的虚拟机内存占用了的内存无法减少来释放资源。 CPU时间 Kubernetes将CPU一个核切分为1000时间片，使用m作为单位，1m表示千分之一核milliCPU。 操作实践 KubeVirt配置资源分配比例 cpuAllocationRatio指定CPU分配比例2000%，比如虚拟机CPU核数为12核，Pod virt-launcher的CPU资源请求则为600m。memoryOvercommit指定内存分配比例为150%。 kubectl -n kubevirt edit kubevirt ... spec: configuration: developerConfiguration: cpuAllocationRatio: 20 featureGates: - HardDisk - DataVolumes memoryOvercommit: 150 ... 创建KubeVirt虚拟机 可以看到spec.template.domain下的spec.template.domain.cpu和spec.template.domain.memory指定了创建虚拟机资源。 spec.template.domain.resources.overcommitGuestOverhead配置不请求额外资源开销，管理虚拟机的基础设施组件需要的内存资源。默认为false，当创建一个虚拟机内存为1Gi时，virt-launcher Pod请求的内存资源为1Gi + 200Mi。 spec.template.domain.resources.requests这里仍然指定了requests，virt-launcher Pod将使用这个requests来请求k8s资源，这样就会不使用上面配置的比例。一般情况不需要再这里指定requests，KubeVirt使用比例计算出requests的资源量。 --- apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: labels: kubevirt.io/vm: mailserver name: ubuntu-c namespace: mail263 spec: running: true template: metadata: labels: kubevirt.io/vm: ubuntu-c annotations: ovn.kubernetes.io/ip_address: 172.16.3.203 ovn.kubernetes.io/mac_address: 00:00:00:1F:C5:8F spec: domain: cpu: cores: 12 model: host-passthrough memory: guest: 96Gi devices: disks: - name: bootdisk disk: bus: virtio - disk: bus: virtio name: cloudinitdisk interfaces: - name: default bridge: {} macAddress: 00:00:00:1f:c5:8f resources: overcommitGuestOverhead: true requests: memory: 16Gi networks: - name: default pod: {} terminationGracePeriodSeconds: 0 volumes: - name: bootdisk dataVolume: name: ubuntuboot-c - name: cloudinitdisk cloudInitNoCloud: userData: |- #cloud-config ssh_pwauth: True chpasswd: list: | ubuntu:ubuntu 查看KubeVirt的ubuntu-c虚拟机VMI资源定义

继续阅读

KubeVirt通过Kube-OVN使用Underlay网络

由 SuKai in kubernetes, Kube-OVN

June 9, 2022

之前文章介绍了如何通过Kube-OVN实现Kubernetes网络租户隔离，今天我们一起看一下KubeVirt通过Kube-OVN使用Underlay网络，使虚拟机接入物理网络。 实践操作 检查Kubernetes使用的Pod网络地址段和Service网络地址段。 sukai@ubuntuserver:/etc/kubernetes/manifests$ sudo grep cidr kube-controller-manager.yaml - --allocate-node-cidrs=true - --cluster-cidr=10.244.0.0/16 sukai@ubuntuserver:/etc/kubernetes/manifests$ sudo grep range kube-controller-manager.yaml - --service-cluster-ip-range=10.211.0.0/16 检查kube-ovn-controller配置项是否正确 kube-ovn在版本v1.11.0开始支持keep-vm-ip参数，虚拟机使用固定IP地址。 Containers: kube-ovn-controller: Container ID: containerd://0f8d53403c9821c7b535c64d2c98e1ca130a15e1b2b878270cd9388c36d0e48a Image: kubeovn/kube-ovn:v1.11.0 Image ID: docker.io/kubeovn/kube-ovn@sha256:fea623e68a2a81ef78102c6cfe95b96c16c054c57f4c8b9d168bd3ff620b6779 Port: <none> Host Port: <none> Args: /kube-ovn/start-controller.sh --default-cidr=10.244.0.0/16 --default-gateway=10.244.0.1 --default-gateway-check=true --default-logical-gateway=false --default-exclude-ips= --node-switch-cidr=100.64.0.0/16 --service-cluster-ip-range=10.211.0.0/16 --network-type=geneve --default-interface-name= --default-vlan-id=100 --pod-nic-type=veth-pair --enable-lb=true --enable-np=true --enable-eip-snat=true --enable-external-vpc=true --keep-vm-ip=true 创建服务网络 指定物理服务器上访问物理网络的网卡。 apiVersion: kubeovn.io/v1 kind: ProviderNetwork metadata: name: office spec: defaultInterface: eno1 创建VLAN 创建在指定服务网络上创建一个VLAN，这里VLAN ID为0表示不属于任何VLAN。 apiVersion: kubeovn.

继续阅读

kube-ovn实现Kubernetes多租户网络管理

由 SuKai in kubernetes, ovn

June 5, 2022

Kubernetes容器平台正在成为越来越多的数据中心基础平台，我们希望Kubernetes能够满足虚拟化平台的一些基本要求，比如实现了多租户的灵活的软件定义网络SDN。工作中一个项目在使用Kubernetes平台，所以考虑通过KubeVirt来管理虚拟机，同时使用kube-ovn来实现多租户网络隔离。下面我们一起来看看如何使用kube-ovn来管理网络。 基本概念 Underlay/Overlay网络 Underlay网络是指传统IT基础设施网络，是由交换机、路由器、负载均衡等设备组成的底层物理网络。Overlay网络是通过网络虚拟化技术，在Underlay网络上构建出的虚拟的逻辑网络。 OVS/OVN Open vSwitch(OVS)是一个多层软件交换机，OVS只里一个单机软件，没有集群的信息。Open Virtual Nework(OVN)提供了一个集中式的OVS控制器，从集群的角度对整个网络设施进行编排。 使用Kubernetes后会发现，Kubernetes网络功能缺少软件定义网络SDN能力，缺少VPC, Subnet, Nat, Route, SecurityGroup等常用功能。Kube-OVN基于OVN为Kubernetes网络提供了网络编排能力。 CNI 容器网络接口(Container Network Interface)，由CoreOS提出的一种容器网络规范，主要内容是容器创建时的网络分配，和容器被删除时释放网络资源。CNI让网络层变得可插拔，只要遵循CNI的协议规范，容器管理平台就可以调用CNI插件可执行文件提供网络功能。Kubernetes网络模型采用了CNI容器网络接口规范。 macvlan macvlan是一种Linux内核的网络虚拟化技术，从一个主机接口虚拟出多个虚拟网络接口。macvlan可以在物理网卡构成的父接口上添加子接口，每个子接口都拥有独立的MAC地址和IP地址。容器可以通过绑定子接口，拥有与物理网络通信的能力。这解决了容器接入物理网络需求，比如我们需要通过docker运行gitlab服务，gitlab服务需要用到80,443,22端口，这些常用端口经常会产生冲突，那么我们可以通过docker命令创建一个macvlan驱动类型的网络来拥有独立MAC和IP地址。Kubernetes内置CNI插件包含了macvlan，配置使用macvlan CNI，可以让Kubernetes的Pod使用Underlay网络 。 Kube-OVN Kube-OVN插件将Kubernetes容器网络接入ovs网络。提供了vpc, router, switch, subnet管理能力。 Multus Multus CNI插件提供了Kubernetes Pod添加多块网卡的能力。容器同时接入多个不同的网络，解决了类似Ceph这种区分多个网络应用场景。 IPAM IP地址管理(IP Address Management)，分配和维护IP地址，DNS，网关，路由等信息。CNI插件在执行过程中调用相应的IPAM插件，IPAM插件将IP相关信息返回到主CNI插件。IPAM插件减少了CNI插件重复编写相同代码管理IP的工作，而且解决了多个CNI插件统一集中IP管理的需求。 场景需求 1，通过VPC实现网络租户隔离 2，通过NAT网关SNAT访问外网 3，通过NAT网关DNAT暴露端口给外网访问 安装部署 安装Kube-OVN curl -O https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.10/yamls/crd.yaml curl -O https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.10/yamls/ovn.yaml curl -O https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.10/yamls/kube-ovn.yaml curl -O https://raw.githubusercontent.com/kubeovn/kube-ovn/master/charts/templates/kubeovn-crd.yaml sed -i 's/\$addresses/<Node IP>/g' ovn.yaml kubectl label node ubuntuserver1 kube-ovn/role=master kubectl apply -f crd.yaml kubectl apply -f kubeovn-crd.

继续阅读

Kubernetes资源类型发现

由 SuKai in kubernetes, golang

May 2, 2022

在基于Kubernetes平台开发过程中，经常需要访问不同Kuberntes版本的集群资源，这时就需要去获取所访问集群支持的资源版本信息。下面我们一起来看一下，如何来实现Kubernetes资源类型发现？ 文章分为下面几部分为大家介绍： 1，kubectl命令查看Kubernetes集群资源 2，client-go库获取Kubernetes集群资源 3，controller-runtime动态获取Kubernetes集群资源 kubectl命令 kubectl命令行工具提供api-resources，api-versions命令来查看kubernetes集群当前支持的资源类型。 kubectl api-resources查看k8s所有资源和版本列表。 sukai@sukai:~$ kubectl api-resources NAME SHORTNAMES APIVERSION NAMESPACED KIND bindings v1 true Binding componentstatuses cs v1 false ComponentStatus configmaps cm v1 true ConfigMap endpoints ep v1 true Endpoints events ev v1 true Event limitranges limits v1 true LimitRange namespaces ns v1 false Namespace nodes no v1 false Node persistentvolumeclaims pvc v1 true PersistentVolumeClaim persistentvolumes pv v1 false PersistentVolume pods po v1 true Pod .

继续阅读

通过Karmada实现应用多Kubernetes集群管理--调度器

由 SuKai in kubernetes, Karmada

April 14, 2022

前面文章介绍了Karmada的控制器流程，了解了Karmada如何实现Kubernetes资源下发到成员集群的。今天我们一起看一下Karmada的调度器，看看Karmada如何实现Kubernetes资源下发调度的。 前面控制器流程里讲过，用户创建了Kubernetes资源对象模板，下发策略和差异策略后，由resourceDetector根据下发策略，创建ResourceBinding绑定资源与策略，再由BindingController根据ResourceBinding，查找并应用OverridePolicy，最终生成创建成员集群资源的Work，由ExecutionController在成员集群中执行Work完成Kubernetes资源操作。 在流程上，Karmada调度器工作在ResourceBinding创建生成后，BindingController控制器工作之前。在功能上，Karmada调度器主要负责Kubernetes资源对象在成员集群的分布，Karmada调度器通过算法得出在哪些成员集群上运行多少个副本数量的结果，将调度结果保存到ResourceBinding的Clusters参数中。 业务流程 1，监听事件加入队列：Informer监听资源绑定ResourceBinding, 下发策略PropagationPolicy事件，将对应的ResourceBinding资源加入工作队列。 2，取出队列中ResourceBinding对象：每秒中开启一个worker，从队列中取出ResourceBinding对象进行处理。循环处理工作队列，直到队列处理结束。 3，获取分布规则：根据ResourceBinding的Annotation中下发策略PropagationPolicy名称，获取下发策略的分布规则。分布规则包括：集群亲和，集群容忍，拓扑分布约束规则以及副本调度策略等信息。 4，判断是否进行ResourceBinding调度：比对新旧分布规则，判断是否需要进行ResourceBinding调度。 5，调度ResourceBinding，计算出成员集群分配副本数量： a，FilterPlugin过滤插件判断集群亲和和容忍是否匹配条件，得到匹配集群。 b，ScorePlugin计算匹配集群的得分，得到集群的优先级。 c，根据SpreadConstraint拓扑分布约束规则，得到最后的下发成员集群。 d，发配副本，副本调度策略类型分两种：Duplicated复制, Divided切分。如果是复制类型，每个成员集群部署与模板相同的资源副本数量。如果是切分类型，可以配置PreferenceWeighted权重优先和PreferenceAggregated聚合优先，前者会根据权重比例来进行切分，后者根据总的副本数量来判断是scaleUP还是scaleDown，再根据成员集群的最大可用副本数来分配副本数量。 6，更新ResourceBinding中的Clusters字段，设置为计算出的成员集群分配副本数量结果。 7，完成了一个ResourceBinding的处理，继续处理下一条。 代码实现 过滤和计分插件 构造调度算法实例，算法插件包括：集群亲和，污点容忍，已安装支持的资源API，已下发集群。 algorithm := core.NewGenericScheduler(schedulerCache, []string{clusteraffinity.Name, tainttoleration.Name, apiinstalled.Name, clusterlocality.Name}) 集群亲和：过滤插件，1，集群名称是否在亲和策略的排除集群列表中。2，集群的标签、字段过滤是否与亲和策略中的标签和字段过滤匹配。返回是否成功结果。 // Filter checks if the cluster matched the placement cluster affinity constraint. func (p *ClusterAffinity) Filter(ctx context.Context, placement *policyv1alpha1.Placement, resource *workv1alpha2.ObjectReference, cluster *clusterv1alpha1.Cluster) *framework.Result { affinity := placement.ClusterAffinity if affinity != nil { if util.ClusterMatches(cluster, *affinity) { return framework.NewResult(framework.Success) } return framework.NewResult(framework.Unschedulable, "cluster is not matched the placement cluster affinity constraint") } // If no clusters specified and it is not excluded, mark it matched return framework.

继续阅读

通过Karmada实现应用多Kubernetes集群管理--控制器

由 SuKai in kubernetes, Karmada

April 13, 2022

Karmada是华为云开源的，提供应用的跨云多集群统一管理和部署。今天一起来看一下Karmada的控制器，怎么来完成集群纳管和Kubernetes应用工作负载在成员集群创建的。 基本概念 Cluster 在Karmada集群管理中，将Kubernetes集群分为两种：控制面集群，成员集群。控制面集群是Karmada管理组件所在的集群。成员集群为纳管的业务集群。Cluster自定义资源指的是成员集群，指定成员集群的API地址，访问密钥，伪装身份，同步模式。同步模式分为Push和Pull，控制面集群能够主动建立与成员集群的连接，创建资源的为Push模式，控制面集群不能与成员集群主动建立连接的，成员集群建立与控制面集群的连接，监听控制面集群的资源事件，创建资源的为Pull模式。 PropagationPolicy Namespaced下发策略，Kubernetes资源对象下发到成员集群的策略，指定资源对象，成员集群。ClusterPropagationPolicy，非Namespaced下发策略。PropagationPolicy只能下发自己所在命名空间的资源，ClusterPropagationPolicy能够下发集群范围的除了系统保留命名空间外的任意命名空间的资源。 OverridePolicy Namespaced差异策略，Kubernetes资源对象下发到某些集群时，使用指定的参数值。ClusterOverridePolicy，非Namespaced差异策略。 ResourceBinding 根据下发策略生成ResourceBinding，指定具体版本的Kubernetes资源对象与下发策略PropagationPolicy绑定。ClusterResourceBinding绑定Kubernetes资源与ClusterPropagationPolicy。 Work 下发到成员集群的资源列表，可以为Deployment, Configmap, Service, Role, CRD等Kubernetes资源。控制面集群通过Work来实现对成员集群的资源控制。Push模式下，控制面集群监听Work资源事件，执行对成员集群的资源对象操作。Pull模式下，成员集群Agent监听Work资源事件，并在成员集群里执行资源对象的操作。 Karmada用户操作 1，添加成员集群，创建Cluster自定义资源的实例对象 2，创建Kubernetes的资源，这里就是Kubernetes原生的Deployment, Statefulset, Daemonset, Job, Configmap, Secret, Service等。 3，创建下发策略PropagationPolicy，指定资源对象部署到哪些集群中。 4，创建差异策略OverridePolicy，指定资源对象在哪些集群中覆盖哪些参数值。 Karmada用户操作完成后，由Karmada控制器进行资源调谐，最终完成在指定的成员集群中创建Kubernetes资源对象。 Karmada控制器 ClusterController 负责调谐Cluster自定义资源，创建集群对应的execution命名空间。Cluster为纳入管理的业务成员集群。 ClusterStatusController 负责调谐Cluster子资源Status，检测并更新成员集群的健康状态、资源使用信息、集群版本信息、集群主机资源信息以及支持的APIResource。 HpaController Pod水平自动扩展控制器，负责调谐HorizontalPodAutoscaler自定义资源。在成员集群创建对应的HorizontalPodAutoscaler。 BindingController 包括两个控制器，ResourceBindingController监听Work, OveridePolicy, ClusterOverridePolicy资源的事件，调谐ResourceBinding负责创建对应的Work，指定要创建的Kubernetes工作负载Workload。ClusterResourceBindingController主要调谐ClusterResourceBinding。 ExecutionController 负责调谐Work自定义资源，在指定集群创建用户定义的Kubernetes工作负载Workload。 WorkStatusController 负责调谐Work的子资源Status，将引用的资源信息保存到Status中。 NamespaceController 监听Cluster自定义资源事件，创建Work，指定创建namespace。 ServiceExportController 监听Work事件，启动对应集群的Informer，监听serviceexports，endpointslices事件，将事件处理后放入worker队列。 EndpointSliceController 监听Work事件，根据Work定义，创建对应的EndpointSlice。 ServiceImportController 调谐ServiceImport资源，创建Kubernetes Service资源对象。 UnifiedAuthController 监听Cluster, ClusterRole, ClusterRoleBinding资源事件，生成Work指定创建ClusterRole, ClusterRoleBinding资源对象。 FederatedResourceQuotaSyncController 调谐FederatedResourceQuota，监听Cluster事件，创建Work指定创建ResourceQuota资源。 FederatedResourceQuotaStatusController 调谐FederatedResourceQuota子资源Status，更新Status信息。 Karmada控制器执行流程 1，创建一个成员集群Cluster资源实例 2，ClusterController创建成员集群对应的执行命名空间executionNamespace。 3，UnifiedAuthController生成创建成员集群ClusterRole, ClusterRoleBinding的Work。 4，ExecutionController根据Work中的集群和资源对象，在成员集群中执行对应操作，比如创建ClusterRole, ClusterRoleBinding等。 5，ClusterStatusController更新成员集群的健康状态，集群及主机信息。 6，成员集群加入成功后，用户创建Kubernetes资源对象模板，下发策略PropagationPolicy，差异配置策略OverridePolicy。

继续阅读

Clusterpedia安装与使用

由 SuKai in clusterpedia, golang

April 8, 2022

今天我们一起来安装一下Clusterpedia，看看Clusterpedia的功能。 安装 Clusterpedia代码目录deploy下提供了kubectl安装Clusterpedia的YAML文件。部署数据库，安装CRD自定义资源，安装apiserver和clustersynchro，注册apiservice。 cd ./deploy/internalstorage/postgres export STORAGE_NODE_NAME=sukai sed "s|__NODE_NAME__|$STORAGE_NODE_NAME|g" `grep __NODE_NAME__ -rl ./templates` > clusterpedia_internalstorage_pv.yaml kubectl create -f . cd ../../.. kubectl apply -f ./deploy/crds kubectl apply -f ./deploy 两个组件的deployment里可以修改镜像地址为： m.daocloud.io/ghcr.io/clusterpedia-io/clusterpedia/clustersynchro-manager:v0.1.0 m.daocloud.io/ghcr.io/clusterpedia-io/clusterpedia/apiserver:v0.1.0 导入集群 创建Clusterpedia的CRD PediaCluster资源实例，syncResources指定Clusterpedia需要同步的资源。 apiVersion: cluster.clusterpedia.io/v1alpha2 kind: PediaCluster metadata: name: cluster-sukai spec: apiserver: "https://192.168.0.111:6443" caData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1ESXdOakE1TXpjek1Wb1hEVE15TURJd05EQTVNemN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSnUzCjlvS0MwUjVQYkgyUTZCa2ZCSzIwYzRVNkJpQmJpdW14akI5VVBZaExja2VhTkIwVHFLY2xXTjNzV2Y4QVBGM0sKYlFyb1F5UzdhNEVGWVU3WFJRcWFWTHdlSGhWZWZnMU1nZ3gzMXpsNS8wR3NqdFRlc1hyTmR4RXBvTnBvVWtrWAp1Uy8wWXZoNjZSUklPMks5WmNLKytvK1YycDl3UFZLTHYvUm45WDZpRVRlVjJSeCt0RDFXbEpDRSs0UGhublJNCm1jYUJyWkxkazVONGtCb1JDMTV0alhWRkpNSVJIejNaUVhwS1RydzVEZ3pvS0MyUUpCcnl1L2kxS0pSWGNIUm8KcXd6dzExWkRMemFXU3VnQ1hMT3pCeXVvblhoOGVpWW5jbldJa0NKZzlUblczamRXU3hZTHBtZUJFaXd5TDNNegpEWUIxWTVpaVVZV0pvbERCQjNNQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZJK2NhY0psbW1oUElPZGJaRjV1LzMzaDVNRUtNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBQkdVanNacEZuKy9LR2VpRnpUNApKaEtITno3Yzl5NjF3eEUvNzYvcFd2eGU1RVRyT1FWbjdTQk54SUQ1OXNBKzUrcEtyNnk5TUxrUUxDZmhhZFdKCmd4WklEVmlHTmV4ejFsSlNKZ2h0L0lTOUtKbnl5YmQ1QUV4cTZ2ZkxrT1VKZkxaYnJMWUNGYUVIWXg1Q055TXEKUGdtdG1Tb1NlOVVKMGpEZlFvanJGakVIbWJpT0hHV0o3R2dHaStKUzhSbFZwc3pyK215c05FcitiMCtiR2hWWApNR3NDNTVCQndOTVZhSHFXZWZmRjB0ZGlSaVY4SW1xa0loSVdNSXA0RFdvbjBJc2xFYTZ0RWNrTGhaM0dsR2lrCmRvcCtGTmJZRmVZWXpPU05yRkpCZitKSnd4U1lSWGlTTXVCc29nd2NYcFZ1S0lza2hoVjU0dUEwUTcxSUNLN3IKN3VnPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== tokenData: certData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJVENDQWdtZ0F3SUJBZ0lJV2YrWkJSK1I0SFF3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpBeU1EWXdPVE0zTXpGYUZ3MHlNekF5TURZd09UTTNNelJhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXVhOHAvUnBITmUzemhGOWkKZEFZUFlBalJIaTlBYTlGc1FhdzY4NzJoOUhBVVpneUNnU3JxUmIwc1hBOUZ4aSsybHJsSWIzUE9sRGd3bnJwZApacmI1VnQyZHRuVGhXZitJYVV4bGNraGs1VWdNQnUwa1VFVGpUTFZtY1RvczVZWGJWejk5aUEwQ3h4LzViYzcwCnJKRWRyWkJQYngrdFN1Mk5kN1paeTE5SExWYVh6a256R3NRZ1o0Z1piT09oeFVNd201OFd4a2hDeDdyczhLQnIKdmNOWXFVMC9UNXVydFJPcEJabCtYMTFnNGcyeXkwSTdBc2R1cnVCMmhiOG1RUW1MRzg5VmdqZHQzOEdrUTJhMApZMGNLay9aeVQzUVUxeGZkUTlvb2FYbWN1SnBkUmJpeTU5a1VBNzVSc3V2L1V3UXZucDgrUzNLR2dFVkJBTkpqCjFCNTljd0lEQVFBQm8xWXdWREFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JTUG5HbkNaWnBvVHlEblcyUmVidjk5NGVUQgpDakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBUk8xVldObW40N1A4ajl3THkrZUdiMVB6WjBnUTg1WlQvOVU1Ck5yVHZ1YXFCVW80bUxvNzBISHRtVDAreVlMSmhWV0kxSW9IT3dqc3gwcUhJWXc3U0lIWS90K3VqOHh4TDJnakgKSVdWT0NwSW5xeDF1TTQwQ0xORGtmbUM1b2JYbEtUbCt0d0hETDBuQzV3am8wdE5TV0x0SERqWjVoRVF2VWlieQoxdmpHZnhDS3YxNXdqVFlvTjZ3OS9nS1ZHQm5scjJjNm1kTmUwSktmUEdHeHRKMmN3R0daQXRYQ1EvcUNRZmpoCnVVM3ZSSTlXSFp5THhJWWF2RjdpRlVlaGdqYVBKc3lwQ0xHejRPVjA3dlFEbHdBQlp3Mjk1WGI3c1FVK1FOMVoKMEwzWHIyVzIydE52ZHBiNlRNSjRMaFN2Z2RLOHFWUDREK0RscWY2ajFUUHFwOFVucGc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== keyData: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdWE4cC9ScEhOZTN6aEY5aWRBWVBZQWpSSGk5QWE5RnNRYXc2ODcyaDlIQVVaZ3lDCmdTcnFSYjBzWEE5RnhpKzJscmxJYjNQT2xEZ3ducnBkWnJiNVZ0MmR0blRoV2YrSWFVeGxja2hrNVVnTUJ1MGsKVUVUalRMVm1jVG9zNVlYYlZ6OTlpQTBDeHgvNWJjNzBySkVkclpCUGJ4K3RTdTJOZDdaWnkxOUhMVmFYemtuegpHc1FnWjRnWmJPT2h4VU13bTU4V3hraEN4N3JzOEtCcnZjTllxVTAvVDV1cnRST3BCWmwrWDExZzRnMnl5MEk3CkFzZHVydUIyaGI4bVFRbUxHODlWZ2pkdDM4R2tRMmEwWTBjS2svWnlUM1FVMXhmZFE5b29hWG1jdUpwZFJiaXkKNTlrVUE3NVJzdXYvVXdRdm5wOCtTM0tHZ0VWQkFOSmoxQjU5Y3dJREFRQUJBb0lCQUVCcUdxZmFDT0FWaHdmaAp5eGF5ejN5aU1tRkZSUlRpRnFzRm80SFF4REUyL0d5V1pHT0l6cktZdUozTEVvcDVITjlXc1dFd2pIWndzN1VzCnM2QWhVNGdsNDBOYmNwMjAvczZBbVNTM0pvRS9xQ1J5K2NqNnpOdGNob2c3QlQ0dVhIUDg2NEJaK3grMjRPR08KRE9VY2htNGloTnZvNGtYKytMZVJ3NzdBYzhHdkUwYWU0akt6ZHZRb0hXNmNkcGxBWGdqRG1EVGVGOVZ6Q2o1SgplaC90OWQvN0V4by83SXJHdWROWnpwcTRZaktrTUdhdVdwcEt0N0FmUXpVU2pTOEh1R0ROL2VpUDhzRXlLdlZmCmwvVmdMb3FzUlRUUzZZNjFkU1FVaHlWSE80Z1VKamV2VVFyMzJFaDF3R2VxMXVDUE9iUjdzd2pnWjhET2kwcDgKam81eFR2a0NnWUVBOUM4Mm1zeDJjdUhLUjZoS2VYbTdhSFJKR0d4MXY1czVMY2lYN0ljMTltM1NROUZHODFBcAp3VjFBOUxydVhpVnoyTFRHV1ZDY2V1ZzZCc0FpTVNXSkF5eGx4TUhEbFVBbXZzT0dLT2N2ZXdlOHRPaUFlQkU0Clo5WWlUcUovZDdxdmdrN1RFdElDTHRDVStKcXRWZmUxVVFnK3FvUHY3Q09GRHplZ1ZrSTF5cDBDZ1lFQXdxdEsKZ3JTQktjaGQvUnlIdG9sbnlkbzYvZk9aWHRIbHkvcGdXQm9ZekZDcFRra3V3TnFjL2J6cE96dFhzL3VZNTlPaQprWUZJcFVLM0cvVnRNRno0UkY1R25mbnFMK0I4cndjcGNJRjJLSXFWYStsR2h5cy9mNWNveWFURHRDWnlSRTRpCmdEb2gyZmhUcEl0ZHN5QkNNdVZGMFRnNE15N1c5aUVTVlNhZm8wOENnWUFaYmVWSTM2d2lNS05wTFB4OGhCSGgKUWVMdTJUUzEvSXRLMms0QUF1QzZ4aHNVbHZIRm12Nk9OWkR6SzVoeFU0TXArVUdDd2FOYUpWOE5udXF3cFpFTQpOSTV3bkNFckpPQWtFNmFnRWR0ZSs2SktVTUE0UU1yWC9YUGJMbzhKdi9aUklyWldpbXBSeDhVTDBzZmtZUVNQCjZNVGw2eEdNVFBLcGNBaVJreG1ZL1FLQmdRQ3ZqSUNZOWVZMG83ZitkU2Y5ZUZQY042eFRMc1gwT0J5ZW9aOFkKVkJCZ3o2eWVLR2k5Q1dmaGVlWnB2ODRMUkt4VEF3cnJaRWI2b1BzM2YwK0QrWkw1Tkh0Q0l3a0pPOHUwbXlUSApqRGZkdjN1WDRMbjFVdzdrSkpCbnB1bkZINWFUK2xJcWlFSFdxcFhqSUxyU3VoaDRoVUU4dHhJWE5mb3I0dzhCCk10OXJDUUtCZ0VLNVZrM21sK1Bsbm1wVmpHMU5wOUFtSDY1c2N0eGhYb0ZkU2VVSUZJSTZLU3plRUZnTlllc0YKajRzRnBQeFhkNk5IaS8wYlZTckJBejFveXI2cXlXK3Iwa2hyV3krb1NRakFqV3ZQdlNiWEwwNE5YcDdDci81MAp6L29OTDRXUVI0eGJyWHlUU1FhbFp4R3EvOEV0MjM0amdnbTl3UWRhTkR6anNtaEZPQ2hRCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg== syncResources: - group: apps resources: - deployments - group: "" resources: - pods 查看集群状态，APIService，api资源包括：CRD和Aggregator两种方式注册的资源。 sukai@sukai:~$ kubectl get pediacluster NAME APISERVER VERSION STATUS cluster-sukai https://192.

继续阅读

搜索

分类

标签