<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>rudr | 伪架构师</title>
    <link>/tags/rudr/</link>
      <atom:link href="/tags/rudr/index.xml" rel="self" type="application/rss+xml" />
    <description>rudr</description>
    <generator>Source Themes Academic (https://sourcethemes.com/academic/)</generator><language>zh</language><lastBuildDate>Wed, 04 Dec 2019 21:20:35 +0800</lastBuildDate>
    <image>
      <url>/img/logo-wide.png</url>
      <title>rudr</title>
      <link>/tags/rudr/</link>
    </image>
    
    <item>
      <title>Rudr 初体验</title>
      <link>/post/rudr-at-a-glance/</link>
      <pubDate>Wed, 04 Dec 2019 21:20:35 +0800</pubDate>
      <guid>/post/rudr-at-a-glance/</guid>
      <description>

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

&lt;h2 id=&#34;安装&#34;&gt;安装&lt;/h2&gt;

&lt;p&gt;Rudr 需要 Kubernetes 1.15 以上的版本，并且使用 Helm 3 进行安装。&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;$ git clone https://github.com/oam-dev/rudr.git
正克隆到 &#39;rudr&#39;...
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.
&lt;/code&gt;&lt;/pre&gt;

&lt;blockquote&gt;
&lt;p&gt;非常谦虚的一个 Note。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;h2 id=&#34;部署一个-component&#34;&gt;部署一个 Component&lt;/h2&gt;

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

&lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;$ 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
&lt;/code&gt;&lt;/pre&gt;

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

&lt;h2 id=&#34;查看-traits&#34;&gt;查看 Traits&lt;/h2&gt;

&lt;p&gt;接下来看看 Kubernetes + Rudr 为应用提供了哪些运行支撑能力：&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;$ kubectl get traits
NAME             AGE
autoscaler       13m
empty            13m
ingress          13m
manual-scaler    13m
volume-mounter   13m
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;熟悉 Kubernetes 的同学应该看得出，除了奇怪的 &lt;code&gt;empty&lt;/code&gt;，其他都是常见的部署元素。&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;$ 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: |
    {
      &amp;quot;$schema&amp;quot;: &amp;quot;http://json-schema.org/draft-
...
&lt;/code&gt;&lt;/pre&gt;

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

&lt;h2 id=&#34;运行应用&#34;&gt;运行应用&lt;/h2&gt;

&lt;p&gt;有了 Component 和 Trait，接下来可以用 &lt;code&gt;Configuration&lt;/code&gt; 启动应用了：&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;$ 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
&lt;/code&gt;&lt;/pre&gt;

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

&lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;$ export POD_NAME=$(kubectl get pods -l &amp;quot;oam.dev/instance-name=first-app-helloworld-python-v1,app.kubernetes.io/name=first-app&amp;quot; -o jsonpath=&amp;quot;{.items[0].metadata.name}&amp;quot;)
...
$ kubectl port-forward $POD_NAME 9999:9999 &amp;amp;
Forwarding from [::1]:9999 -&amp;gt; 9999
$ curl http://127.0.0.1:9999
Hello Rudr!
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;修改配置&#34;&gt;修改配置&lt;/h2&gt;

&lt;p&gt;使用 &lt;code&gt;kubectl edit&lt;/code&gt; 修改上一步的配置，把 target 参数修改为 &lt;code&gt;World&lt;/code&gt;：&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-yaml&#34;&gt;...
    parameterValues:
    - name: target
      value: World
...
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;应用之后，会看到 Pod 被重建，重新执行上面的测试步骤，返回信息变成 &lt;code&gt;Hello World&lt;/code&gt;。&lt;/p&gt;

&lt;h2 id=&#34;结论&#34;&gt;结论&lt;/h2&gt;

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