使用 Katacode 将容器化的 MagicOnion 应用程序在 Kubernetes 上运行试试
在写这篇文章的前一天,我们在MagicOnion学习会上做了一个有关将MagicOnion转为Linux容器镜像并在Kubernetes上运行,并使用NewRelic进行监控的演讲。这是演讲的资料。
由于LT的原因,我突然展示了它在演示中的运行情况,可能会引起一些人的疑问,他们想知道如何使其运行。因此,我想简要介绍一下在kubernetes上运行它的步骤。
我认为最大的难关是创建Kubernetes环境。像AKS、EKS和GKE这样的公共云托管Kubernetes可以使用各个公司提供的命令进行安装,但需要付费。也可以在本地安装名为minikube的工具,但仍然会有一些麻烦。因此,在寻找中,我发现了一个名为Katacoda的服务。正如博客文章中所说,它可以在浏览器中操作一个预先准备好的Kubernetes环境。所以这次我想使用Katacoda来在Kubernetes上运行MagicOnion应用。只是有一个限制,即无法将gRPC端点公开到互联网,因此客户端也需要在相同的环境上运行。
Katacode通过创建课程可以提供包含步骤的提示。我会再多做些调查,然后更加详细地制作课程内容,但首先请按照这些步骤尝试一下。
请先访问我创建的课程列表页面。
只需要一个选择,将以下内容用汉语进行原生的改述:
当出现这种屏幕时,创建帐户并登录可以保留历史记录,非常方便,但似乎无需创建帐户也可以使用。

单击 Kubernetes 沙盒下的“开始场景”按钮。然后会跳转至下一个页面。

右下的黑色画面是终端,上面的白色画面可以用作编辑器。首先,执行启动Kubernetes的命令。
launch.sh
等待一段时间,将会显示”kubernetesd started”。尝试执行显示kubernetes节点列表的命令。
kubectl get node
然后将显示节点列表,节点似乎只有一台。

接下来,我们将部署MagicOnion应用程序,并创建一个Kubernetes服务,以便可以从外部进行访问。使用编辑器创建一个名为app.yaml的空文件,并在编辑器界面中通过双击来打开它。

将以下的Kubernetes对象定义复制粘贴到编辑器中,将会自动保存。
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: magiconion
spec:
replicas: 1
template:
metadata:
labels:
app: magiconion
spec:
containers:
- name: magiconion
image: tanakatakayoshi/magiconion-server-example:latest
ports:
- containerPort: 12345
---
apiVersion: v1
kind: Service
metadata:
name: magiconion-svc
spec:
ports:
- name: magiconion
port: 12345
selector:
app: magiconion
type: NodePort
让我们在这里确认一下接下来要创建的东西。刚刚定义的文件中存在两个对象:deployment(部署)和service(服务)。在deployment中,我们指定了镜像为tanakatakayoshi/magiconion-server-example:latest,它将成为我们要运行的容器镜像。
这个容器镜像的详细信息已经在这里记录。
原始碼已在此處公開。
如果你对这个不太明白的容器图像不想要运行的话,我想介绍一下将自己编写的源代码转化为容器图像并运行的方法,请稍等一下。这个容器由MagicOnion的简单服务器、相应的客户端项目以及构建它们的Docker文件组成。
回到最初,我们将部署一个由一个指定图像的容器组成的Pod,这是Kubernetes的一个对象。Pod可以包含多个容器和称为volume的存储,但是我们刚刚定义的Pod只包含一个容器。containerPort: 12345表示这个Pod将公开容器外部的端口12345,这意味着它将与MagicOnion服务器端的代码中监听的端口相对应。
await MagicOnionHost.CreateDefaultBuilder()
.UseMagicOnion(new[] {
new ServerPort("0.0.0.0", 12345, ServerCredentials.Insecure) })
.RunConsoleAsync();
另一个创建的服务对象是用于公开对Pod的访问的对象。(由于后述原因,目前无法从该环境外访问,)它是用于外部访问的端点,当一个应用在多个Pod上进行负载均衡时,它将成为一个负载均衡器。
返回终端界面后,执行创建刚刚定义的对象定义的命令。
kubectl create -f app.yaml
显示已创建部署和服务。部署将Pod部署,但需要一些时间来完成。kubectl get命令使用-w选项可以显示更改和更新信息。因此,我们可以通过此命令来确认Pod的状态。
kubectl get po -w
只要状态显示为Running,就可以了。

接下来,我们将检查服务的情况。
kubectl get svc
将名为magiconion-svc的服务的CLUSTER-IP记下来。

好吧,现在MagicOnion服务器端应用已经成功地作为容器在kubernetes上运行了。现在我们想要连接它,但是在使用Katacode时有一个限制。这个限制是我们似乎无法从外部接受非HTTP(S)的TCP流量。之前创建的服务是NodePort类型,它可以在指定的端口上通过节点访问,并与Pod进行通信。然而,在Katacode的kubernetes中我们无法访问节点,所以不能使用这种方法。
在现有运行Kubernetes的服务器上,我们决定运行MagicOnion的客户端。由于我们已经在现有服务器上发布了与之对应的测试客户端应用程序,因此我们将在同一个Docker存储库中使用它。
稍微有点邪门,但是我们可以直接在运行 Kubernetes 的服务器上执行 Docker 镜像。我们可以通过环境变量 GRPC_HOST 来从外部传递服务器主机,因此我们在终端中执行以下命令来指定先前记录的 CLUSTER-IP 值。如果要实际运行,请用 10.99.143.216替换它。
docker run --name client-demo -e GRPC_HOST=10.99.143.216 tanakatakayoshi/magiconion-server-example:client
然后日志就会立即流动起来。使用了两个都是公开的Docker映像,只需要观看流动的日志,所以可能感觉不太像在运行,但是这样就可以在Kubernetes上运行MagicOnion的服务器应用程序了。

当然可以使用minikube或者常规的kubernetes来运行,这样就可以从kubernetes外部访问,并且可以从Unity连接。我认为Katacode非常适合用于尝试运行kubernetes,非常方便好用。我在考虑未来创建一个可以在调查中试验各种东西的课程。
先前部署定义中指定的副本数量将生成相应数量的Pod。↩
据我所查,并不完全是这样。无法确定是否确实如此。https://www.katacoda.com/docs/scenarios/displaying-ports↩