なになれ

IT系のことを記録していきます

AnsibleとVagrantでKubernetesをセットアップする

Kubernetes Ansible Vagrant

以下を試してみた内容です。 kubernetes.io

2019年9月25日現在、この内容を試すとうまく動作しない部分があるので、直しつつ進めました。
なお、ローカルのOSはmacOS 10.14.6になります。
以下、Stepごとに修正点を補記します。

Step 1: Creating a Vagrantfile

変更なし

Step 2.1: Install Docker and its dependent components.

変更なし

Step 2.2: Kubelet will not start if the system has swap enabled, so we are disabling swap using the below code.

変更なし

Step 2.3: Installing kubelet, kubeadm and kubectl using the below code.

変更なし

Step 2.3: Initialize the Kubernetes cluster with kubeadm using the below code (applicable only on master node).

kubeletの設定ファイルを作成する記述を追加

    - name: Configure node ip
      lineinfile:
        create: yes # <- 追記
        path: /etc/default/kubelet
        line: KUBELET_EXTRA_ARGS=--node-ip={{ node_ip }}

Step 2.4: Setup the kube config file for the vagrant user to access the Kubernetes cluster using the below code.

変更なし

Step 2.5: Setup the container networking provider and the network policy engine using the below code.

calicoのバージョンを最新にする

    - name: Install calico pod network
      become: false
      command: kubectl apply -f https://docs.projectcalico.org/v3.9/manifests/calico.yaml  # <- 変更

Step 2.6: Generate kube join command for joining the node to the Kubernetes cluster and store the command in the file named join-command.

join-commandのコピー時に非root権限で実施する

    - name: Copy join command to local file
      become: false
      local_action: copy content="{{ join_command.stdout_lines[0] }}" dest="./join-command"

Step 2.7: Setup a handler for checking Docker daemon using the below code.

変更なし

Step 3: Create the Ansible playbook for Kubernetes node.

変更なし

Step 3.1: Start adding the code from Steps 2.1 till 2.3.

変更なし

Step 3.2: Join the nodes to the Kubernetes cluster using below code.

変更なし

Step 3.3: Add the code from step 2.7 to finish this playbook.

変更なし

Step 4: Upon completing the Vagrantfile and playbooks follow the below steps.

変更なし

全内容

gist.github.com

ISUCONに初参加しました

イベント

ISUCON9の予選が9/7,8の日程で開催されました。
会社の同僚と一緒にチームを組んで、初めてISUCONに参加しました。

isucon.net

2人チームでチーム名は「isuconなにもわからない」です。仕事ではNode.jsを使っているのでNode.jsで挑戦しました。
利用言語の比率が公開されていますが、Node.jsの利用者はそんなに多くなかったみたいです。

isucon.net

参考値ですが80番目くらいのスコアでした。

isucon.net

事前の準備

本番でやったこと

  • 効果あり

    • キャンペーンの値を0から4に変更する
    • itemsテーブルにindexを追加する
    • 複数台構成にする

  • あまり効果がなかった

    • ts-nodeからtscでコンパイルしてnode.jsでアプリを実行する
    • 外部APIをPromise.allで並列実行する
    • 無駄なFOR UPDATEを除去

  • 改善できなかった

    • POST buyのロック問題

参加してみて気づいたこと

  • 計測の設定などのセットアップをするのが遅い
    • 午前中をほとんど使ってしまった
  • アプリレベルでの計測をシュッとできるようにする
    • １つ１つconsole.timeを埋め込んで時間がかかった
  • tsc化するのに時間がかかった
    • typescriptに慣れる必要を感じた
  • 改善策がほとんど思いつかなかった
    • SQLは改善ポイントがあまりなかった
    • キャッシュする観点が思いつかなかった
    • 改善のパターンをもっと身につける必要を感じた
  • 人数は3名必要
    • 2名だとアプリとインフラで分かれることになって個人の力がないと辛い
    • 逆に1名でも本戦出場チームがそれなりにいるのですごいと思います

まとめ

準備や本番も含めて良い経験になりました。次回も参加したいと思います。

AWSでKubernetes環境を構築する際のIngressについて

AWS Kubernetes

Ingressはアプリケーションレイヤのロードバランサに当たるリソースでSSL化などが可能になります。
Ingressの実装は様々なIngress Controllerに依存します。
例えば、Nginxを利用したNginx Ingress ControllerやGKEに含まれているGKE Ingress Controllerなどがあります。
AWSでKubernetesを構築する際には、EKSにおいてもIngress Controllerは存在しないため、構築者自身がIngress Controllerを設定する必要があります。

今回は、AWSで利用可能な以下のIngress Controllerを紹介します。

AWS ALB Ingress Controller

IngressリソースによってALBが作成されるIngress Controllerです。

kubernetes-sigs.github.io

メリット

  • ALBによる高機能なロードバランサ機能を扱うことができる

デメリット

  • Ingressリソース毎にALBリソースが作成される

ALB Ingress ControllerはALBの機能を利用することができるので、可能な限り利用するのが良いと思います。
但し、Ingressリソース毎にALBが作成されてしまいます。
複数のサービスがある場合に、１つのサービスに１つのIngressリソースを作る構成だとリソース過多になってしまいます。
ALBの設定を変えて、１つのURLで複数のサービスを公開する方法も取れますが、場合によってはサービスの内部的なURLと公開されるURLが異なることで404エラーになる可能性があります。

NGINX Ingress Controller

IngressリソースによってNginxが作成されるIngress Controllerです。

kubernetes.github.io

メリット

  • URLのrewrite機能によって複数のサービスに向き先を設定できる

デメリット

  • SSL化にはSecretリソースを用意するといった準備が多い
  • ALBが使用できない

NGINX Ingress ControllerにはURLのrewrite機能によって複数のサービスに向き先を設定することができます。
但し、ALBを利用することができないのが気になります。

オススメ構成

AWS ALB Ingress Controller → NGINX Ingress Controller

各Ingress Controllerのデメリットを補える構成です。
AWS ALB Ingress ControllerでALBを利用するのと、複数のサービスを１つのALBで参照するためにNGINX Ingress Controllerを利用し、nginxのrewrite機能を利用します。

設定のポイントは以下の通りです。

  • NGINX Ingress Controllerをインストールする際にNodePortを利用する
  • ALB Ingress ControllerのIngressの向き先をNGINX Ingress ControllerのNodePortに向ける

設定例

NGINX Ingress ControllerをNodePortでインストール

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

ALB Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-alb
  namespace: ingress-nginx
  annotations:
    kubernetes.io/ingress.class: alb
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: ingress-nginx
              servicePort: 80

NGINX Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-http-svc
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /http-svc
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-http-svc2
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: http-svc2
          servicePort: 80
        path: /http-svc2

まとめ

NGINX Ingress Controllerを活用することで、AWS ALB Ingress Controllerの欠点を補うことができるようになります。

参考