# Rudr 初体验

[OAM（开放应用模型）](https://github.com/oam-dev/spec) 是一次对应用运行及其支撑环境进行抽象的有意思的尝试，与之对应的控制器 [Rudr](https://github.com/oam-dev/rudr) 也在同一时间诞生。有了 Rudr，OAM 就不是一个简单的标准，而是一个可以尝试落地的原型了。官方仓库提供了很好的[入门文档](https://github.com/oam-dev/rudr/blob/master/docs/tutorials/deploy_and_update.md)，借此文档的帮助，能够很好的理解规范中莫名其妙的概念。这里就按照官方教程走一通，看看这种方法让应用部署运行过程发生了什么变化。

## 安装

Rudr 需要 Kubernetes 1.15 以上的版本，并且使用 Helm 3 进行安装。

~~~shell
$ git clone https://github.com/oam-dev/rudr.git
正克隆到 'rudr'...
remote: Enumerating objects: 49, done.
...
$ cd rudr
...
$ helm install rudr charts/rudr
...
NOTES:
Rudr is a Kubernetes controller to manage Configuration CRDs.

It has been successfully installed.
~~~

> 非常谦虚的一个 Note。

## 部署一个 Component

Component 是 OAM 中的一个运行单位，代表一种运行负载，其类型可能有 Server、Job 等。下面使用示例代码创建一个 Component 对象：

~~~shell
$ kubectl apply -f examples/helloworld-python-component.yaml
componentschematic.core.oam.dev/helloworld-python-v1 created
$ kubectl get component
NAME                   AGE
helloworld-python-v1   35s
~~~

查看这个源文件，其中声明了一个 `Server` 类型的组件，用参数的方式定义了两个环境变量 `TARGET` 和 `PORT`。

## 查看 Traits

接下来看看 Kubernetes + Rudr 为应用提供了哪些运行支撑能力：

~~~shell
$ kubectl get traits
NAME             AGE
autoscaler       13m
empty            13m
ingress          13m
manual-scaler    13m
volume-mounter   13m
~~~

熟悉 Kubernetes 的同学应该看得出，除了奇怪的 `empty`，其他都是常见的部署元素。

~~~shell
$ kubectl get traits autoscaler -o yaml
apiVersion: core.oam.dev/v1alpha1
kind: Trait
...
spec:
  appliesTo:
  - core.oam.dev/v1alpha1.Server
  - core.oam.dev/v1alpha1.Task
  properties: |
    {
      "$schema": "http://json-schema.org/draft-
...
~~~

这里可以看到，HPA 适用于 Server 和 Task 两种组件，定义了最大实例数、最小实例数以及 CPU/内存消耗阈值。

## 运行应用

有了 Component 和 Trait，接下来可以用 `Configuration` 启动应用了：

~~~shell
$ kubectl apply -f examples/first-app-config.yaml
applicationconfiguration.core.oam.dev/first-app created
$ kubectl get pods
NAME                                              READY   STATUS    RESTARTS   AGE
first-app-helloworld-python-v1-855479556f-6qvk8   1/1     Running   0          38s
...
$ kubectl get ingress
NAME                                           HOSTS         ADDRESS   PORTS   AGE
first-app-helloworld-python-v1-trait-ingress   example.com             80      12m
~~~

Pod 已经启动，Ingress 对象也已经建立起来，可以看看他的运行结果：

~~~shell
$ export POD_NAME=$(kubectl get pods -l "oam.dev/instance-name=first-app-helloworld-python-v1,app.kubernetes.io/name=first-app" -o jsonpath="{.items[0].metadata.name}")
...
$ kubectl port-forward $POD_NAME 9999:9999 &
Forwarding from [::1]:9999 -> 9999
$ curl http://127.0.0.1:9999
Hello Rudr!
~~~

## 修改配置

使用 `kubectl edit` 修改上一步的配置，把 target 参数修改为 `World`：

~~~yaml
...
    parameterValues:
    - name: target
      value: World
...
~~~

应用之后，会看到 Pod 被重建，重新执行上面的测试步骤，返回信息变成 `Hello World`。

## 结论

实际上单就这个例子来说，对比入门的 Deployment + Service + Ingress 三件套来说，复杂度并没有什么区别。然而 Component 对象的工作负载类型除了 Server 之外，还有 Job、Serverless 等复杂类型，用 Traits 可以描述多种运维能力，更不要说还有暂未浮出水面的 Application Scope 对象，猜测这个模型在公有云、多云以及混合云下，可能会有相当大的想象空间。