Go to Qiita Advent Calendar 2024 Top
LoginSignup
34
24

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

LeveragesAdvent Calendar 2017

Day 19
@tkowin株式会社MOCHI

Kubernetesを実戦投入してマイクロサービス化するまでに四苦八苦している話

Last updated at Posted at 2018-01-06

忙し過ぎて書けなかった宿題などを消化中・・・

Kubernetes入門して結構経ちましたが、やっと色々怖くなく使いこなせることが増えてきて、と思って変わった構成をやって見ると、事故ってみたいなことを繰り返してますが、せっかくなので色々書いて置こうと思いました。

gcpugの方に聞いて見たところ、とても快く教えてくださる方がいて、なんとか実戦投入することができました。

勉強は公式のドキュメントとKubernetes: Up and Running: Dive into the Future of Infrastructure+github上のIssueやネット記事を参考にして行なっていました。
後者の本は、kubernetesの全体像を掴まずにいきなり読むと、割と概念がわからずつまづく箇所が多く、公式ドキュメントをスッと入ってくることが多かったのでドキュメントである程度概念を知っておくことをおすすめします。出版されてからもうすでにマイナーバージョンが2上がっています。進化早過ぎですね。。。

色々と作業中に実行結果からの推測などが入ってしまっているので、間違ってたら、まさかりどんどんください。

最低限知っておくと良いこと

用語など

Node: podをホストするマシンのこと
Cluster: Nodeのグループのこと
Pod: コンテナのグループのこと、Node上に同種のPodや別種のPodを複数配置可能

Kube Objectについて(kindキーで設定される値)

全部覚える必要はなく最低限以外のものは必要になった都度覚えるとよいです。以下主要なものの抜粋。クラウドによってクラウド特有のオプションをmetadataなどで設定できる。

pod : 単一または複数のコンテナからなるグループの単位、鯨などの群を表す(pod)という単語からきてるらしい。
service : podへの接続設定を保持しルーティングする。typeによって、接続IPなどの扱いが異なる。
deployment : podの設定とReplicaSetの設定を同時に行うオブジェクト、deploymentによって作成されたpodは、ローリングアップデートなどの設定ができる
ReplicaSet: podの生成についてのルールを作成する。ReplicaControllerの上位互換ラベルセレクタに条件式が使える
ConfigMap: 環境変数などの設定値を設定するためのオブジェクト
Secret: 特に機密情報に関わるデータを設定するためのオブジェクト

kubeobjectは基本service+deploymentで外部からの接続が可能になる

##　kubectlについて

Kube Objectの設定を反映させるために使うCLI
クラスタに関する設定と全てのKubeObjectに対してのほとんどの設定を
kubectlから行うことが可能なので、色々叩いて何が起こるか勉強するのが
理解の近道だと思います。

*今回は単純にマイクロサービス型のクラスタを構成するまでの必要最低限のコマンドしか叩いていません。

Kubernetes初期設定と操作クラスタの切り替え

  1. 前提としてクラスタを管理しているマシン上でmaster componentsが起動している必要がある(minikubeを使うとVM上に,GKE上ではGUI・CUIでクラスタを作ると勝手に立つと思われる。これは簡潔性のために同ホストで全てのmaster componentsを立ち上げるが個別の起動や自作サービスとの共存も可能(ただしやらない方がいいと書いてある))。
    参考:
    The Kubernetes Master is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: kube-apiserver, kube-controller-manager and kube-scheduler.

  2. kubectlコマンドはmaster componentsのうちkube-apiserverを指定・経由して操作したいホスト(クラスタ)に変更を加える(REST)
    (各ホストではkubeletとkube-proxyというデーモンが操作を待ち受けている or 新たに作成されたnode上でkubele, kube-proxyを起動させる「GCPの場合は、おそらくGKEクラスタの作成時にそれぞれのnode上でkubeletを起動させている」)

  3. kubectlで操作されるホスト群(クラスタ)の設定は(デフォルトでは)$HOME/.kube/configから読まれる

  4. 以下のコマンド

gcloud container clusters get-credentials $CLUSTER_NAME --zone=$ZONE_OF_CLUSTER

を実行するとkubectlの操作対象をGKE上のクラスタに設定できる - ここの設定は、.kubeを見る限りkubectlのREST先を切り替えている。minikube startを使うとリクエスト先がVMになる。)

  1. .kube/configに一度設定したクラスタはcontextというkeyのデータに格納される。
kubectl config use-context $CLUSTER_NAME

で操作対象のクラスタを自由に変えることができる。

参考(https://github.com/kubernetes/kubernetes/issues/25383)

手動でkubectlの操作先を決定する最小の設定方法

$ kubectl config set-cluster --server=xxx
$ kubectl config set-credentials xx --username=xxx password=xxxx
$ kubectl config set-context xxx --cluster=xxx --user=xxx --namespace=xxxx
$ kubectl config use-context xxxx

gcloud container clusters get-credentials は、以上のコマンドを簡略化してくれていると思われる

現在kubectl実行環境に設定されているcontextのリストを確認する方法

kubectl config view -o jsonpath='{.contexts[*].name}'

また、kubectlのcontextの向き先を設定すればgoogle cloud console上のkuberctlでも操作が可能

設定情報を見る

dash_boardを使うと一覧できる。
gcp上のkubenetesの設定を確認したい場合は認証情報が必要なため、クレデンシャルを設定した端末でkubectl proxyを実行し、

$host:8001/ui

でアクセスすることにより本番環境の設定情報にもアクセスできる。gcp上の端末だとIPなどで弾かれるのでローカルマシンのkubectl proxyからlocalhostで接続するのが無難。ただGKEの場合これを使わずGKEのダッシュボード見ろとの噂・・・。

Kubernetes Ingressとは

簡単にいうと,Kubernetes上に(L7)ロードバランサーを作成する機能

複数のサービスにルーティングする

kubectl get ing

kind : Ingress で、設定ファイルを作成する
pathsでL7ロードバランサーからルーティングができる。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: hoge-ip
spec:
  tls:
    - secretName: tls-certs-1709
  rules:
  - http:
      paths:
      - path: / 
        backend:
          serviceName: hoge-service
          servicePort: 80

複数のサービスをホスティングする

Service Type:LoadBalancerで指定されるロードバランサーを使用する場合、パスによる、ルーティングはおそらくできない(L4ロードバランサーなので),portフォワーディングによるサービス振り分けは可能。

よって、複数サービスを単一ホストのサービスに見せかけるにはIngress(L7ロードバランサー)を使うのが良い。

固定IPを作成

# 設定
gcloud compute addresses create ${ipName} --global

# 確認 
# kubctl create(or apply or replace ) -f hoge-ingress.ymlを使用したときに
# 以下のコマンドで IN USE担っていることを確認する
gcloud compute addresses list
# 後表示されているaddressからブラウザアクセスできるか確認
# backendに対応するservice objectとpodsが正しく設定されていれば、global static ipでサービスに接続できる

ingress-> nginx-service -> nginx-pod -> nuxt-service->nuxt-podを自己署名証明書で、https接続するところまでできたので、手順をまとめておく。
また、なぜうまくいくのかを理解しておくことで、この構成を再現できる人を増やしたい。
なお、kubernetes objectの作成順番が変わってもいいもの、悪いものにがあるは、手順に従っていれば、大丈夫なように書かれている。

やった手順

前提:あらかじめ、GKEクラスタをGCPコンソールあるいは、gcloudコマンドから作成しておく。

gcloud container clusters create $clusterName --zone $region --project $gcp-project

クラスタ作成初回は時間がかかるので注意。
get-credentialsでgkeの権限とgcrの権限を手に入れておく。

  1. nginxのdeployment,serviceを作成
  2. nuxtアプリケーションのdeployment,serviceを作成
  3. static ipを作成し、ingressに紐づける
  4. この状態でcurlなどでingressにアクセスし、nuxtサービスからレスポンスが帰ってくるか確かめる
  5. secrets.yamlにbase64で暗号化したパラメータを設定し、ingressのtlsにsecretsオブジェクトの識別子(name)を入れる

nginxの設定

nginxはどの環境でもほぼ同じように使えるため、
抽象度を高めて汎用化するのが良い。

nginx-service.yml

kind: Service
apiVersion: v1
metadata:
  labels:
    name: nginx 
  name: nginx-service
  namespace: default
spec:
  type: NodePort
  ports:
    - port: 80
      protocol: TCP
  # Label keys and values that must match in order to receive traffic for this service.
  selector:
      app: nginx

ここで、deploymentに使うイメージをbuildする。

./docker-nginxなどわかりやすいディレクトリ名を作り、Dockerfileと
imageに含めたいファイルなどを用意しておく。
シンプルにnginxの設定ファイルだけ用意すれば良いので、

FROM nginx:latest

ADD server.conf /etc/nginx/conf.d/server.conf

server.conf

# for staging
server {
  listen 80 default_server;
  location / {
      proxy_pass "http://hoge-service.default.svc.cluster.local:8080";
  }
}

を用意し、

$ docker build . -t gcr.io/$gcp_project/hoge-nginx:$label
$ gcloud docker -- push gcr.io/$gcp_project/hoge-nginx:$label

でgcrにpushする、タグは gcr.io/$projectName/$image:$versionの
命名規則に従う必要がある。

  • server.confの設定について　

ingressからnginxに接続した時に、kubeDNSのデフォルトの
命名規則から、サービスへとルーティングを行う。

Service Objectを生成した時にkubeDNSは

{$serviceName}.{$nameSpace}.svc.cluster

というdnsレコードを自動で作成する。これはクラスタのど
こからでも、参照できるため、ロードバランサを通って来た
リクエストをnginxで振り分ければ、好きなkubernetesサービスへ、
ルーティングすることができる。なお、ingress-nginxの
設定は、この処理を自動化しているように見える。

nginx-service.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    name: nginx 
  name: nginx-deployment
  namespace: default
spec:
  replicas: 3 
  selector:
    matchLabels:
      name: nginx 
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 100%
      maxUnavailable: 50%
  template:
    metadata:
      creationTimestamp: null
      labels:
        name: nginx 
        app: nginx
    spec:
      containers:
      - image: gcr.io/$gcpproject/nginx:latest
        name: nginx
        ports:
        - containerPort: 80
          name: nginx 
          protocol: TCP

nginxから接続するService Objectの設定は以下の通り

kind: Service
apiVersion: v1
metadata:
  labels:
    name: hoge
  name: hoge-service
  namespace: default
spec:
  type: NodePort
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 8080
  # Label keys and values that must match in order to receive traffic for this service.
  selector:
      app: hoge

{$serviceName}.{$nameSpace}.svc.clusterの命名規則から
resolverとしてkube-dns.kube-system.svc.cluster.localを使用することで、hoge-service.default.svc.cluster.localというDNでアクセス可能。deploymentはnameがhogeのコンテナで8080ポートでアプリケーションを待ち受けていれば、どんなWebサービスでも接続可能なので省略。

ingressを接続する前に以上のオブジェクトを生成しておく。

$ kubectl create -f nginx-deployment.yml  -f nginx-service.yml # -f ...other objects setting

ingressの接続

ingressに対するstatic-ipを作成しておく。

$ gcloud compute addresses create hoge-ip --global

以下のように、annotations.kubernetes.io/ingress.global-static-ip-name
に設定しておくことで、作成されたstatic-ipを指定することで、ingressに
httpアクセスができるようになる。

nginx-ingress.yml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: hoge-ip
spec:
  tls:
  - secretName: test-secret
  rules:
    - http:
        paths:
        - backend:  
            serviceName: nginx-service
            servicePort: 80

httpだけで運用するつもりであれば、tlsはなくてもよい、疎通ができるまでに不安がある場合
tlsパラメータを設定する前にcurlでingressにアクセスし、nuxtサービスからレスポンスが帰って
くるか確かめることもできる。

  • loadbalancerで接続できていない場合、
    curlを行っても、404が帰ってくる
  • nginxで接続できていない場合、
    backend service not foundが返ってくる
  • nginxからアプリケーションに接続できていな い場合
    curlで301が返ってくることで確認できる
  • nginxからアプリケーションに接続できてるばあい(http)
    curlで普通にコンテンツサーブされる、アプリケーション側でTLSを有効にしていなければ、ブラウザだとhttpsにリダイレクトされて接続できない

なお、ingressの反映はダウンタイムがないが、rolling updateは遅いため,アクセスしてうまくいかないなーと思っていても、時間をおくとうまくいってることがあるため、5,6分は様子を見ること。

https対応にする場合、アプリケーション側のミドルウェアに証明書をおく、nginxにおく、ロードバランサーにおくなど、いくつかの方法がありますが、ロードバランサーに設定するのが一番簡単かつ汎用性が高い。

$ kubectl create secret generic test-secret --from-file=tls.crt=$cert_path --from-file=tls.crt=$key_path

で、証明書を包含したSecretObjectを設定し、前述のnginx-ingress.ymlのtls.secretsName[*]にsecretの識別子を設定して、
ingressに反映させると、443でもingressに接続できるようになる。また、以上の設定は、secrets.ymlでも設定を行うことができる。

ここでは、練習のために自己署名証明書を発行して、設定ファイルで行う方法も記述する。

自己署名証明書で、動作確認を行う

2048bit RSAで自己署名証明書を作成する。期限は適当で良い。

$ openssl genrsa 2048 > server.key;
$ openssl req -new -key server.key > server.csr
$ openssl x509 -days 3650 -req -signkey server.key < server.csr > server.crt

$ cat server.crt | base64  
$ cat server.key | base64

の出力結果を以下の$server.crt
$server.keyにセットする。

apiVersion: v1
data:
  tls.crt: $server.crt 
  tls.key: $server.key
metadata:
  name: test-secret
  namespace: default
type: Opaque

なお、これらのファイルはバージョン管理に含めない方が良い。

$ kubectl replace -f nginx-service.yml

などで、ingressに反映させ,数分置いたのち、 curl $ingress-ip -kLあるいは、ブラウザからhttps でアクセスを行うと、サービスに接続できることを確認できれば、めでたく、ルーティングでマイクロサービスを自由に振り分けられる状態になったことになる。
なお振り分けられているipは

$ gcloud compute addresses list

$ kubectl get ing

で確認が可能。

urlの負荷分散について

マイクロサービスを増やした際にnginx側の設定に追加が必要なのは構成管理の手間的に推奨されない。通常はGCPUGの方に教えてもらったようにサブドメインで対応して

proxy_pass "http://${version}.{env}.svc.cluster.local:80";

汎用化する方がよい。もしくは/ルートを使わず第一urlをキャプチャすればいけるかも。proxyの設定は必要に応じて。

resolver kube-dns.kube-system.svc.cluster.local valid=5s;

# for staging
server {
  listen 80 default_server;
  location /hoge/ {
      proxy_pass "http://hoge-service.default.svc.cluster.local:8080/";
  }
  location / {
      proxy_pass "http://http-test-service.default.svc.cluster.local:8000";
      proxy_set_header        Referer                 $http_referer;
      proxy_set_header        Host                    $host;
      proxy_set_header        X-Real-IP               $remote_addr;
      proxy_set_header        X-Forwarded-Host        $host;
      proxy_set_header        X-Forwarded-Server      $host;
      proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Ssl         on;
      proxy_set_header        X-Forwarded-Proto       https;
  }
}

*色々作業中のものが残ってしまっていますが、DockerImageはlatestタグは管理しにくいため都度ラベルを割り振った方がいいようです。

一回デプロイした後は

イメージプッシュするたび

kubectl set image deployment/hoge-deployment hoge=hoge:$label

でデプロイメントで指定されているimageをすげ替えるだけでdeploymentに指定されている通りのupdateの仕方で更新が走ります。簡単にblue-green canary リリースができて便利、auto healingももちろん設定できます。

CDを使う

CIの機能に組み込まれているものや単体のCDツールを使って,image pushおよび、kubectl set imageまでの作業もリリースタグを切るなどのトリガーを用いて自動化できます。
Circle CI, Wercker, Spinnaker あたりが良いようです。Spinnakerは特に推されている印象があります。

34
24
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
34
24

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?