皆さんこんにちは 👋Wantedly DXチームインターンの森本です。

9月にインターンが終了してしまうので、最後にインターンの総括をしようと思います。(割と自分用です)

具体的には、インフラ未経験(本当に0)の状態から最終的にCNDT2020に登壇するまでで、学んだことおよび気をつけていたことなどを書きます。インターンのプロジェクト内容は本記事では割愛しますので、こちらをご確認ください。

これからインターンを検討している方やインフラ開発(特にKubernetes)を始めようと思っている方の参考になれば嬉しいです。

目次

1. 事前知識編 (実装する前に学んだこと)
　　1-1. Kubernetes
　　1-2. Istio Request Routing
　　1-3. Telepresence
　　1-4. Kubebuilder

2. コミュニケーション編 (気をつけていたこと)
　　2-1. 直接的に要望を伝える
　　2-2. カレンダーを活用する 

3. CNDT2020登壇準備
　　3-1. スライド作成
　　3-2. 発表練習

1. 事前知識編 (実装する前に学んだこと)

インターンは前提知識を学んだり、チュートリアルを動かすところから始まりました。挙げられたキーワードを自分で調べてまとめ、認識に間違いがないかその都度確かめていただきました。

学んだことはGitHubのIssueにまとめて管理していました。それらを抜粋して掲載します。以下の内容に加えて、Wantedly独自のKubeコマンドの使い方およびDeployのフローを理解しました。これらを読めば、「インフラ開発経験あります！」と名乗れると思います(笑)

もちろんインフラ未経験なので、Kubernetesの発音を調べるところから始めます。

1-1. Kubernetes

発音

クーバネイテスと呼んでいた。(参考 : koo-ber-nay'-tace) 調べるとクバネティスと出てくる。

なにができる？

複数のサーバーを用いた運用が行いたい時に

• sshを用いてそれぞれのサーバーを遠隔操作した場合
• • どのサーバーでどのプロセスが動くか固定されてしまい柔軟性や拡張性が低い
• Kubernetesを使った場合
• • どのプロセスをいくつ走らせたいか、理想の状態を宣言をすることで、サーバーを有効活用して適切にプロセスを割り当ててくれる、壊れた時なども常に理想の状態を保ってくれる

以下の記事がとても参考になります。 (2016年の記事とは...すごい...)

Kubernetesクラスタのアーキテクチャ

• Kubernetesクラスタはノード(プロセスを実行するサーバー)の集合である
• ノードにはマスターとワーカーが存在する
• マスターがワーカーにプロセスを割り当てる

参考 : https://kubernetes.io/ja/docs/concepts/overview/components/

Kubernetesの代表的なリソース

• Pod
• • コンテナ(イメージの1インスタンス)の集合
  • ワーカーノードでは複数のPodが動いている

参考 : https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/explore/explore-intro/

• ReplicaSet
• • Podの作成や削除を担当する

参考 : https://kubernetes.io/ja/docs/concepts/workloads/controllers/replicaset/

• Deployment
• • ReplicaSetの作成を行う
  • Deployment → ReplicaSet → Pod の流れ
  • ReplicaSetを直接扱うよりもDeploymentを使うことが推奨されている

参考 : https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/

• Service
• • Podの集合を定義して、(クラスタ内部からの)リクエストを受け取り適切なPodにリクエストを送る
  • Serviceに対してIPアドレスが割り当てられ、DNSが更新される (参考 : https://kubernetes.io/ja/docs/concepts/services-networking/dns-pod-service/)
  • PodのIPアドレスは変動するが、ユーザーはPodのIPアドレスを意識せずに、単一のエンドポイントを使って通信ができるようになる
  • ServiceはIPテーブルであり、ServiceはPodを継続的に監視し、対象のPodのIPアドレスを記録し続ける

参考 : https://kubernetes.io/ja/docs/concepts/services-networking/service/

1-2. Istio Request Routing

Istio とは？

IstioはEnvoyの拡張版を使用したフレームワーク

参考 : https://istio.io/latest/docs/ops/deployment/architecture/

Envoy とは？

マイクロサービス向けのL7(アプリケーション層)プロキシ(代理サーバー)およびバス(通信経路)

参考 : https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy

Request Routing とは？

Istio(Envoy)を用いると、KubernetesのServiceではできなかったL7(リクエストの中身を見た)制御が可能になる

参考 : https://istio.io/latest/docs/tasks/traffic-management/request-routing/

Request Routing に用いるリソース

• Virtual Service
• • 1つ以上のホスト(KubernetesのService)に対してリクエストのルーティングを指定できる
  • 実際にルーティングを行っているのはEnvoyであり、Envoyにルーティングのルールを伝えている
  • 一般的な使用方法はServiceまたはServiceの部分集合(Destination Rule)にルーティングすることである

参考 : https://istio.io/latest/docs/concepts/traffic-management/#virtual-services

• Destination Rule
• • 名前付きのServiceの部分集合を定義する
  • Serviceを利用する場合と違いEnvoyのトラフィックポリシーをカスタマイズできる

参考 : https://istio.io/latest/docs/concepts/traffic-management/#destination-rules

1-3. Telepresence

なにができる？

• ローカルのマシンをKubernetesクラスタの一部であるかのように動作させる
• Podに双方向のリクエストに対応したプロキシを追加しルーティングを行う
• Kubernetesの環境変数やSecrets等にローカルからアクセスができる

参考 : https://www.telepresence.io/discussion/overview

特徴 : デプロイが速い

• Telepresenceは高速なデプロイを提供する
• Deploymentを再デプロイすると変更をDockerイメージにビルドする必要があり体感で数分かかってしまう

参考 : https://www.telepresence.io/tutorials/kubernetes-rapid

デプロイ方法

• new-deployment
• • Telepresence起動中のみ一時的に新規のServiceとDeploymentを用意する
  • 新しくServiceを用意しているので、既存のクラスタのルーティングに影響を与えない
• swap-deployment
• • 既存のDeploymentをTelepresenceのPod(プロキシ)に一時的に置き換える
  • 既存のServiceのルーティング先であるDeploymentを上書きしているので、クラスタのルーティングを直接変更していることになる

参考 : https://www.telepresence.io/reference/connecting

1-4. Kubebuilder

なにができる？

• Kubernetesの独自リソースを宣言すると、KubernetesAPIとコントローラーを構築してくれる
• 独自リソースに対してKubernetesAPIが追加されるので、DeploymentsやPodsなどのKubernetesリソースと同じように、YAMLファイルを用いて宣言的な管理ができるようになる

参考 : https://kubernetes.io/blog/2018/08/10/introducing-kubebuilder-an-sdk-for-building-kubernetes-apis-using-crds/

使い方

• init
• • kubebuilder init --domain my.domain
• create api
• • kubebuilder create api --group webapp --version v1 --kind HogeHoge
  • kindに作成したい独自リソースの名前を指定する

参考 : https://book.kubebuilder.io/quick-start.html#create-a-project

Kubebuilderで生成されるファイル

• hogehoge_types.go
• • Specに独自リソースの持つフィールドを宣言する

参考 : https://book.kubebuilder.io/cronjob-tutorial/new-api.html

• hogehoge_controller.go
• • SetupWithManagerメソッドでCRUDを監視したいリソースを指定する(Forをつなげることで複数のリソースを指定できる)
  • Reconcileループに指定したリソースがCRUDされたタイミングでの処理を記述する

参考 : https://book.kubebuilder.io/cronjob-tutorial/controller-overview.html?highlight=controller#whats-in-a-controller

• role.yaml
• • コントローラーにコメントの形式でRBAC(アクセス制御)を追加すると、role.yamlが変更される

参考 : https://book.kubebuilder.io/reference/markers/rbac.html?highlight=rbac#rbac

2. コミュニケーション編 (気をつけていたこと)

今回のインターンは完全リモートでした。皆さんのサポートのおかげで苦労したことはありませんでしたが、気をつけていたことや大切だと思った点を少し紹介します。

2-1. 直接的に要望を伝える

個人的にはこれが一番大切だなと思っています。

例えば、メンターさんに1on1をお願いしたい時に

私: 「今日は忙しそうですかね...」
メンターさん: 「どうしたの〜〜」
私: 「1on1してもらいたくて...」
メンターさん: 「じゃあ17時からやろうか〜〜」

などと、やんわり頼むよりも

私: 「1on1お願いしたいんですけど、今日時間ありますか？？」
メンターさん: 「じゃあ17時からやろうか〜〜」

このように、しっかり要望を伝えた方が無駄の会話の往復が少なくて済みますし、誤解も生まれません。

今回のインターンで社内ブログを書いたり、CNDTに登壇するに至ったのも、アウトプットを重視したい！という要望をしっかり伝えられていたからです。

(どうしても間接的になってしまうこともあるので、今後とも意識したいです)

2-2. カレンダーを活用する

とりあえずカレンダーに勝手にスケジュールを予約してしまうのもありだと思います。参加者が時刻を自由に変更できるように権限を与えておけば、

私: 「今日の17時から1on1予約させてもらいました。都合が悪かったら時刻ずらしてください。」
メンターさん: 「はい〜〜」

先ほどのコミュニケーションがもっと楽になります。

1on1の予約だけじゃなくて、他のチームのエンジニアの方、営業や広報の方をランチに誘ったりも、カレンダーを有効に使えばできそうです。

3. CNDT2020登壇準備

今回はメンターさんと共同で登壇をさせていただきました。発表の構成やスライドの内容は割と任せていただき、フィードバックを元に2人でブラッシュアップを繰り返しました。登壇資料はこちらからご覧いただけます。

3-1. スライド作成

資料だけを見ても内容が理解できるように何度も修正を重ねました。特に気をつけた点は 1. スライドそれぞれのタイトルとサブタイトルに要点をまとめる 2. 口頭だけの補足説明はできる限りなくす 3. 前のスライドとの流れや話の切り替わりがわかるようにすることでした。こちらの資料を参考にしました。

今回はリモート開催だったので、オンラインならではの工夫も必要でした。オンラインではアニメーションは思った通りに動かないので、半透明の図形などを用いて話の流れを表現しました。また2人での登壇だったので、今誰が喋っているのか伝えるために、右上に発表者のアイコンを載せるようアドバイスをいただきました。

3-2. 発表練習

たくさんの方からアドバイスをいただいて練習を繰り返しました。最初のうちは、理解しているはずなのに何も喋れなくなってしまって、かなりご心配をおかけしました。どうしたら緊張が解れるだろうとメンターさんと考えた結果、対談形式のプレゼンに挑戦することにしました。オンライン開催を活かした発表形式だったと思います。

対談形式にしたもののまだ調子は上がらず、思い切って社外の知り合いの方に練習をお願いしました。違うバックグラウンドの方に対して話すことで、とりあえず相手に理解してもらいたい！というマインドを持てました。自分が綺麗に上手く話すことに意識が向きすぎて、肝心な部分を忘れていたことに気づきました。

そこからは発表の構成やスライド内容の議論も、より主体的にできたのではないかと思います。自分の言葉で伝えようとすることで、理解が足りていない部分にも改めて向き合うことができました。

最後に

今回のインターンでは、実装と同じくらいの時間を、事前知識の学習やアウトプット(技術ブログ執筆と登壇)に費やしました。そのことで、プロジェクトの意義(現状の課題や理想の状態)を言語化して説明すること・適切な技術選定・アイデアを形にするための地盤作りの大切さを学ぶことができました。特にこのプロジェクトをインターン生に任せられる土台が整っていることの凄さを改めて感じています。

メンターの大坪さんをはじめ、皆さんの暖かいサポートのおかげで、無事登壇まで走り抜けることができました。最高でした！本当に！本当に！ありがとうございました！！