概要

• オフライン参加のハンズオンイベントは気付いたときには締切になっていました…
• 代わりにハンズオンの教材がGitHubに公開されているのを見つけたので1人ハンズオンセッションをしてみました
• 紹介記事：https://kaigi.cloudnativedays.jp/blog/handson-1/
• あと全然終わらなかったので続きを別の機会にやります

実行ログ

事前準備 (所要時間：0.5 hr)

• VMを作成する
  • 参考リンク：https://github.com/cloudnativedaysjp/cnd-handson/tree/main/chapter_setup
  • AWSアカウントは実験用に個人のアカウントを持っていたので、そちらで構築
  • AWS CLI v2からは aws login でCLIの認証を済ませられる
  • 基本的には手順通り進めていく
    • Security GroupのIngress設定でポート番号の開放をしている
      • IP制限かけたい気もするが一旦進める
    • EC2のインスタンスタイプはt2.xlarge
      • vCPU 4, メモリ 16 GiB, ネットワーク帯域 ~5Gbps
      • 大きめだがKubernetesのクラスタを動かすならこれくらい必要ということか
    • EBSのボリュームも50GiBと余裕を持たせている
  • VMにパッケージインストール
    • ここは書いていなかったがSSH接続して行う
    • chmod 400 cnd-handson-key.pem をしてから ssh -i cnd-handson-key.pem ubuntu@<確認したパブリックIPアドレス>
  • /etc/hosts を書き換えて各構築サービスにアクセスできるよう名前解決の設定
  • VMにレポジトリをクローン

クラスタの作成 (所要時間：1.5 hr)

• 参考リンク：https://github.com/cloudnativedaysjp/cnd-handson/tree/main/chapter_cluster-create
• Control Plane 1, Worker Node 2の構成で作る
• 以下のツールを使う
  • kindはローカルにクラスタ構築できるツール
    • Kubernetes in Dockerの略
  • kubectlはKubernetes APIを使えるコマンドラインツール
  • Ciliumはクラスタ管理・トラブルシュート用？
  • Helmはパッケージマネージャ
• ファイルの更新を監視するinotifyのリソース設定がデフォルトでは枯渇するので上限を引き上げる
• kind-config.yamlでホスト上のポートからControl Planeのポートにマッピング
  • kind create cluster --config=kind-config.yaml
  • Cililumの利用時にはCNIのデフォルト無効化・kube-proxyの無効化を設定
    • デフォルトではkindnetdがルーティング設定を行うがポリシーの適用などにもCiliumは使える
    • kube-proxyはLinux標準のiptablesを使うが、パケットの照合が線形である一方、CiliumはeBPFを採用してハッシュ表を用いた照合が可能
      • 今回の規模では大きな違いはなさそうだが、スケールするなら重要
• kind create cluster --config=kind-config.yaml が通らない
  • install-tools.shでdockerグループにユーザ追加していると記載があるが実際はない
  • sudo usermod -aG docker $USER をしてから newgrp docker で完了
• いよいよデプロイ
• 以下の3つのネットワークツールをデプロイする
  • Gateway API: クラスタ外から内側へのトラフィックを管理する定義
  • Cilium: CNI (Container Network Interface) の一種でPod間通信を担う
  • Ingress NGINX Controller: インターネットからkind上のServiceへのHTTPリクエストをURLパスに基づいてルーティング
  • kubectl apply —server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.1/standard-install.yaml
  • kubectl apply —server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.1/experimental-install.yaml
  • helmfile sync -f helm/helmfile.yaml
• それぞれデプロイが完了すると以下で参照できる
  • kubectl get crd,cilium
  • kubectl get ingress-nginx
• アプリケーションのデプロイもしてみる

kubectl create namespace handson
kubectl apply -f manifest/app/serviceaccount.yaml -n handson -l color=blue
kubectl apply -f manifest/app/deployment.yaml -n handson -l color=blue
kubectl apply -f manifest/app/service.yaml -n handson
kubectl apply -f manifest/app/ingress.yaml -n handson

• 無事完了
  • 

Dockerコンテナ（所要時間：<0.5 hr）

• 参考リンク：https://github.com/cloudnativedaysjp/cnd-handson/blob/main/chapter_docker
• dockerコマンドの確認
  • docker pull IMAGE
  • docker images
  • docker run -p PORT IMAGE
  • curl -I localhost:8888で200 OK
  • docker ps
  • docker stop CONTAINER_ID
• Dockerfileを用いたイメージのビルド
  • Dockerfileのあるディレクトリで以下を実行
    • docker build -t TAG .
    • TAGはUSER/REPOSITORY:latestなどのように使える
• Dockerベストプラクティスの確認
  • 一時的な環境として使う
    • 重要なデータやログは外に置く
  • .dockerignoreで機密情報や不要な情報は除く
  • マルチステージビルドを活用する
    • コンパイル用とコンパイル済みの実行ステージを分けてイメージサイズ削減
    • ビルド結果の不要な部分を消すとかでも良いのかもしれない
  • 不要なパッケージを入れない
    • セキュリティリスク
  • アプリケーションの分離性
    • 一つの用途で一つのコンテナ
  • 不要な特権の使用を避ける
    • コンテナ内の実行もUSER権限で
  • 信頼できるベースイメージかを確かめる
• 基本的なことが多いが、改めて気を付けたい