重启openstack服务_如何“ Kubernetize” OpenStack服务

最新推荐文章于 2021-11-01 17:51:42 发布

cuml0912

最新推荐文章于 2021-11-01 17:51:42 发布

阅读量304

点赞数

文章标签： java kubernetes linux docker python

原文链接：https://opensource.com/article/18/10/how-kubernetize-openstack-service

版权

重启openstack服务

Kuryr-Kubernetes是一个用Python编写的OpenStack项目，用作容器网络接口（CNI）插件，该插件通过使用OpenStack Neutron和Octavia为Kubernetes容器提供联网。该项目退出了试验阶段，并在OpenStack的Queens版本（云基础架构软件的第17版）中成为了完全受支持的OpenStack生态系统公民。

Kuryr-Kubernetes的主要优点之一是，您无需在OpenStack和Kubernetes中使用多个软件开发网络（SDN）进行网络管理。它还解决了在OpenStack云上运行Kubernetes集群时使用网络数据包双重封装的问题。想象一下，使用Calico进行Kubernetes网络连接，并使用Neutron将Kubernetes集群的虚拟机（VM）进行网络连接。使用Kuryr-Kubernetes，您只需使用一个SDN（Neutron）即可为Pod和运行这些Pod的VM提供连接。

Kuryr-Kubernetes包含三个部分：

kuryr-controller观察Kubernetes资源，决定如何将其转换为OpenStack资源，并创建这些资源。有关OpenStack资源的信息将保存到相应的Kubernetes资源的注释中。
kuryr-cni是CNI运行的可执行文件，它将调用传递给kuryr-daemon 。
kuryr-daemon应该在每个Kubernetes节点上运行。它监视在主机上创建的Pod，并在收到CNI请求时根据Pod批注中包含的Neutron端口为Pod布线。

通常，CNI插件（如Calico或Nuage）的控制部分在Kubernetes集群上作为其提供网络的Pod运行，因此，自然而然，Kuryr团队决定采用该模型。但是将OpenStack服务转换为Kubernetes应用并不是一件容易的事。

Kuryr-Kubernetes要求

Kuryr-Kubernetes只是一个应用程序，并且应用程序有要求。这是环境中每个组件的需求以及如何将其转换为Kubernetes的原语。

库里尔控制器

应该只有一个kuryr-controller实例（尽管OpenStack Rocky中实现的A / P高可用性功能可能会更高）。使用Kubernetes的Deployment原语很容易实现。
Kubernetes ServiceAccounts可以使用一组精细的权限提供对Kubernetes API的访问。
不同的SDN提供对OpenStack API的不同访问。还应提供API SSL证书，例如通过在Pod中安装Secret 。
为了避免出现鸡与蛋的问题， kuryr控制器应与hostNetworking一起运行，以绕过使用Kuryr来获取IP。
提供kuryr.conf文件，最好将其安装为ConfigMap 。

最后，我们得到一个类似于以下内容的Deployment清单：


   
   
    
    
     
     apiVersion: apps/v1beta1
     
     

kind: Deployment
     
     

metadata:
     
     

  labels:
     
     

    name: kuryr-controller
     
     

  name: kuryr-controller
     
     

  namespace: kube-system
     
     

spec:
     
     

  replicas: 
     
     1 
     
     

  template:
     
     

    metadata:
     
     

      labels:
     
     

        name: kuryr-controller
     
     

      name: kuryr-controller
     
     

    spec:
     
     

      serviceAccountName: kuryr-controller
     
     

      automountServiceAccountToken: true
     
     

      hostNetwork: true
     
     

      containers:
     
     

      - image: kuryr/controller:latest
     
     

        name: controller
     
     

        volumeMounts:
     
     

        - name: config-volume
     
     

          mountPath: 
     
     "/etc/kuryr/kuryr.conf" 
     
     

          subPath: kuryr. 
     
     conf 
     
     

        - name: certificates-volume
     
     

          mountPath: 
     
     "/etc/ssl/certs" 
     
     

          readOnly: true
     
     

      volumes:
     
     

      - name: config-volume
     
     

        configMap:
     
     

          name: kuryr-config
     
     

      - name: certificates-volume
     
     

        secret:
     
     

          secretName: kuryr-certificates
     
     

      restartPolicy: Always

kuryr-daemon和kuryr-cni

这两个组件都应存在于每个Kubernetes节点上。当kuryr-daemon容器在Kubernetes节点上启动时，它会注入kuryr-cni可执行文件并重新配置CNI以使用它。让我们将其分解为需求。

kuryr-daemon应该在每个Kubernetes节点上运行。这意味着它可以表示为DaemonSet 。
它应该能够访问Kubernetes API。这可以通过ServiceAccounts来实现。
它还需要kuryr.conf文件。同样，最好的方法是使用ConfigMap 。
要在节点上执行联网操作，它必须与hostNetworking一起运行并作为特权容器运行。
由于需要注入kuryr-cni可执行文件和CNI配置，因此必须在pod上安装Kubernetes节点的/ opt / cni / bin和/etc/cni/net.d目录。
它还需要访问Kubernetes节点的netns ，因此/ proc必须安装在Pod上。（请注意，您不能将/ proc用作安装目标，因此必须使用不同的名称，并且必须配置Kuryr才能知道。）
如果它与Open vSwitch Neutron插件一起运行，则必须挂载/ var / run / openvswitch 。
为了标识在其节点上运行的Pod，应该将nodeName传递到Pod中。可以使用环境变量来完成。（广告连播名称也是如此，下面将对此进行说明。）

这将产生一个更复杂的清单：


   
   
    
    
     
     apiVersion: extensions/v1beta1
     
     

kind: DaemonSet
     
     

metadata:
     
     

  name: kuryr-cni
     
     

  namespace: kube-system
     
     

  labels:
     
     

    name: kuryr-cni
     
     

spec:
     
     

  template:
     
     

    metadata:
     
     

      labels:
     
     

        Name: kuryr-cni
     
     

    spec:
     
     

      hostNetwork: true
     
     

      serviceAccountName: kuryr-controller
     
     

      containers:
     
     

      - name: kuryr-cni
     
     

        image: kuryr/cni:latest
     
     

        command: 
     
     [ 
     
     "cni_ds_init" 
     
     ] 
     
     

        env:
     
     

        - name: KUBERNETES_NODE_NAME
     
     

          valueFrom:
     
     

            fieldRef:
     
     

              fieldPath: spec. 
     
     nodeName 
     
     

        - name: KURYR_CNI_POD_NAME
     
     

          valueFrom:
     
     

            fieldRef:
     
     

              fieldPath: metadata. 
     
     name 
     
     

        securityContext:
     
     

          privileged: true
     
     

        volumeMounts:
     
     

        - name: bin
     
     

          mountPath: /opt/cni/bin
     
     

        - name: net-conf
     
     

          mountPath: /etc/cni/net. 
     
     d 
     
     

        - name: config-volume
     
     

          mountPath: /etc/kuryr/kuryr. 
     
     conf 
     
     

          subPath: kuryr-cni. 
     
     conf 
     
     

        - name: proc
     
     

          mountPath: /host_proc
     
     

        - name: openvswitch
     
     

          mountPath: /var/run/openvswitch
     
     

      volumes:
     
     

        - name: bin
     
     

          hostPath:
     
     

            path: /opt/cni/bin
     
     

        - name: net-conf
     
     

          hostPath:
     
     

            path: /etc/cni/net. 
     
     d 
     
     

        - name: config-volume
     
     

          configMap:
     
     

            name: kuryr-config
     
     

        - name: proc
     
     

          hostPath:
     
     

            path: /proc
     
     

        - name: openvswitch
     
     

          hostPath:
     
     

            path: /var/run/openvswitch

注入kuryr-cni可执行文件

这部分花费了我们最长的时间。我们经历了四种不同的方法，直到一切正常。我们的解决方案是将Python应用程序从容器中注入到容器的主机中，并注入CNI配置文件（但后者很简单）。大多数问题与Python应用程序不是二进制文件而是脚本这一事实有关。

我们首先尝试使用PyInstaller将kuryr-cni脚本制作为二进制文件。尽管此方法运行良好，但存在严重的缺点。一方面，构建过程很复杂-我们必须使用PyInstaller和Kuryr-Kubernetes创建一个生成二进制文件的容器，然后使用该二进制文件构建kuryr-daemon容器映像。同样，由于PyInstaller的怪癖，我们最终在kubelet日志中产生了许多误导性的回溯，也就是说，在例外情况下，我们可能会在日志中得到错误的回溯。决定因素是PyInstaller更改了包含的Python模块的路径。这意味着os.vif库中的某些检查失败，并破坏了我们的持续集成（CI）。

我们还尝试注入一个包含CPython二进制文件， kuryr-kubernetes软件包及其所有要求的Python虚拟环境（venv）。问题在于Python venvs并非设计为可移植的。即使virtualenv命令行工具中有--relocatable选项，它也不总是有效。我们放弃了这种方法。

然后，我们尝试了我们认为的“正确”方式：向主机注入在kuryr-daemon容器上执行docker exec -i的可执行脚本。由于kuryr-kubernetes软件包安装在该容器中，因此可以轻松执行kuryr-cni二进制文件。所有CNI环境变量都必须通过docker exec命令传递，这是从Docker API v1.24开始实现的。然后，我们只需要确定应该在哪里执行的Docker容器即可。

首先，我们尝试从kuryr-daemon容器的入口点调用Kubernetes API以获取其自己的容器ID。我们很快发现这会导致竞争状况，有时入口点会在Kubernetes API使用其容器ID更新之前运行。因此，我们没有调用Kubernetes API，而是使注入的CNI脚本在主机上称为Docker API。然后，使用Kubernetes添加的标签很容易识别kuryr-daemon容器。

得到教训

最后，我们有了一个易于部署和管理的工作系统，因为它在Kubernetes上运行。我们已经证明Kuryr-Kubernetes只是一个应用程序。尽管花费了大量时间和精力，但结果值得。 “ Kubernetized”应用程序更易于管理和分发。

MichałDulko将在11月13日至15日在柏林举行的OpenStack峰会上介绍如何使用OpenStack服务制作Kubernetes应用。

翻译自: https://opensource.com/article/18/10/how-kubernetize-openstack-service

重启openstack服务

cuml0912

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
重启openstack服务_如何“ Kubernetize” OpenStack服务

开启openstack服务 Kuryr-Kubernetes是一个用Python编写的OpenStack项目，用作容器网络接口（CNI）插件，该插件通过使用OpenStack Neutron和Octavia为Kubernetes容器提供联网。该项目退出了试验阶段，并在OpenStack的Queens版本（云基础架构软件的第17版）中成为了完全受支持的OpenStack生态系统公民。 Kur...
复制链接

扫一扫