本文共 6258 字,大约阅读时间需要 20 分钟。
重启openstack服务
是一个用Python编写的OpenStack项目,用作容器网络接口(CNI)插件,该插件通过使用OpenStack 和为Kubernetes容器提供联网。 该项目退出了试验阶段,并在OpenStack的Queens版本(云基础架构软件的第17版)中成为了完全受支持的OpenStack生态系统公民。
Kuryr-Kubernetes的主要优点之一是,您无需在和使用多个软件开发网络(SDN)进行网络管理。 它还解决了在OpenStack云上运行Kubernetes集群时使用网络数据包双重封装的问题。 想象一下,使用Calico进行Kubernetes网络连接,并使用Neutron将Kubernetes集群的虚拟机(VM)进行网络连接。 使用Kuryr-Kubernetes,您只需使用一个SDN(Neutron)即可为Pod和运行这些Pod的VM提供连接。
Kuryr-Kubernetes包含三个部分:
通常,CNI插件(如Calico或Nuage)的控制部分在Kubernetes集群上作为其提供网络的Pod运行,因此,自然而然,Kuryr团队决定采用该模型。 但是将OpenStack服务转换为Kubernetes应用并不是一件容易的事。
Kuryr-Kubernetes只是一个应用程序,并且应用程序有要求。 这是环境中每个组件的需求以及如何将其转换为Kubernetes的原语。
最后,我们得到一个类似于以下内容的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
这两个组件都应存在于每个Kubernetes节点上。 当kuryr-daemon容器在Kubernetes节点上启动时,它会注入kuryr-cni可执行文件并重新配置CNI以使用它。 让我们将其分解为需求。
这将产生一个更复杂的清单:
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
这部分花费了我们最长的时间。 我们经历了四种不同的方法,直到一切正常。 我们的解决方案是将Python应用程序从容器中注入到容器的主机中,并注入CNI配置文件(但后者很简单)。 大多数问题与Python应用程序不是二进制文件而是脚本这一事实有关。
我们首先尝试使用将kuryr-cni脚本制作为二进制 。 尽管此方法运行良好,但存在严重的缺点。 一方面,构建过程很复杂-我们必须使用PyInstaller和Kuryr-Kubernetes创建一个生成二进制文件的容器,然后使用该二进制文件构建kuryr-daemon容器映像。 同样,由于PyInstaller的怪癖,我们最终在kubelet日志中产生了许多误导性的回溯,也就是说,在例外情况下,我们可能会在日志中得到错误的回溯。 决定因素是PyInstaller更改了包含的Python模块的路径。 这意味着中的失败,并破坏了我们的持续集成(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”应用程序更易于管理和分发。
在11月13日至15日在柏林举行的介绍 。
翻译自:
重启openstack服务
转载地址:http://dqdzd.baihongyu.com/