Tutorialの「Create a new application」を進めながら、Radiusのリソースを作成するとkubernetes側にどんなリソースが作成されるかを対応させながら試したいと思います。
まずは作業用フォルダを作成し、rad initコマンドで始めます。このとき、rad init --fullで初期設定可能なすべてのパラメーターを選択できるのですが、ターミナルの縦が狭い状態（Visual Studio CodeでWindowの一部で表示している場合など）だと正しく表示されない問題があるのでそのときは縦に広げて回避しましょう。
さて、この時点でkubernetesの名前空間を調べると、radius-systemとdefault-myapp（-の後ろはフォルダの名前）という2つ（ほかに作成したアプリがあればそれも）の名前空間が作成されていることがわかります。radius-systemがRadiusの動作に必要なリソースと思われます。
default-myappの方がこのアプリ用でまだ何も作られていません。
前回はまずrad runコマンドを実行しましたが、今回はrad deployコマンドを実行します。すると必要なkubernetesのリソースが作成されました。が、アプリにアクセスする方法がないようです。
rad runコマンドを実行すると、ログのストリーミングが始まり、ポートフォワーディングにより http://localhost:3000 にアクセスするとアプリにアクセスできるようになりました。
次の手順で、database(MongoDB)コンテナとbackend(nginx)コンテナを追加していますが、これらはレシピとよばれるものでサービスを追加できる仕組みでした。単に追加するだけであれば設定などが不要なのですが、実際どのような設定が与えられているかというのをrad recipe showコマンドで確認できます。
で、再度これらを追加したアプリをrad runするとアプリ側で参照できていることがわかります。
この状態でkubernetes側のリソースを見てみましょう。アプリ、databse、backendの3つのPodが動いており、それぞれ接続のためにClusterIPタイプのサービスが作成されています。つまりクラスタ内からこれらのコンテナにアクセスする方法はありますが、クラスタ外（インターネット）からアクセスする方法は見当たりません。rad runすることで一時的にポートフォワーディングによるアクセスを提供しているわけになります。
Radiusのリソースとしてインターネットからのアクセスを許可したい場合はgatewayとよばれるリソースを追加します。追加後rad deployするとパブリックエンドポイントが出力されます。
このようにパブリックエンドポイント経由で接続できました。
このパブリックIPはどのIPかといえば、radius-system名前空間のcontour-envoyと呼ばれるLoadbalancerタイプのサービスのExternal IPになっています。つまり、このサービス経由でクラスター内の指定したコンテナ宛てにルーティングされてアクセスできています。
前回の記事で案内していませんでしたが、作成したアプリのリソースを削除するにはrad app deleteコマンドを実行します。kubernetes側のリソースも削除されますが名前空間は残るようです。
