apt install時のプログレスバーを非表示にする

aptを使ってパッケージをインストールする時、進捗を示すプログレスバーが表示される。しかし、Packerでイメージを作る時のように、不要な場合もある。このとき、Dpkg::Progress-Fancyオプションにfalseを指定することでプログレスバーを表示しないようにできる。

ref: https://mvogt.wordpress.com/2013/10/12/apt-0-9-12/

 

Kubernetes on OpenStack with Octaviaでスケーラブルなロードバランサーを実現する

KubernetesのCloud-ProviderはOpenStackのLoadBalancerをサポートしている。v1.9からOctaviaがサポートされたので、kubesprayで構築して試した。OctaviaについてはOpenStack Octaviaの概要を参照していただきたい。

構築自体はkubesprayのmasterなどv1.9以降が使えるもので設定して、かつcloud-configファイルのLoadBalancerセクションでuse-octavia=trueとなるようにテンプレートを修正する。その後ansibleを適用したらよいのだけど、kubernetes v1.9.1だと動かない。というのも、バグでLoadBalancer作成中に叩くAPIエンドポイントが間違っていた。

すでに修正済みかつv1.9.3に修正が含まれると思われるが、今すぐためしたかったのでv1.9.1のタグからブランチを切り、修正PRをcherry-pickし、イメージをビルドして検証を継続した。gophercloudを使ってOpenStackのAPIを叩いていれば読みやすいので助かる。hyperkubeをビルドする時、デフォルトだと全OSかつ全アーキテクチャ向けにビルドするようで滅茶苦茶時間がかかるので、Kubernetes: Build Your Custom Kubelet Imageのように環境変数で指定してあげるのがよいです。それでもイメージを作るのに15分くらいはかかる(体感)ので、なんかいい方法ないものか。

検証用には microservices-demoを使っていて、front-end ServiceのtypeをLoadBalancerに変更すればよい(portsからnodePortを消すのを忘れずに)。これで、LoadBalancerが作られる。

無事LoadBalancerが作られると、以下のようにfront-end ServiceのTYPEがLoadBlancerとなり、EXTERNAL-IPにLoadBalancerが使うFloatingIPのIPアドレスが割り振られる。このアドレスにブラウザでアクセスすると、microservices-demoのショップ画面を見ることができる。

このとき、インターネットからコンテナへの経路は以下のようになるはず。

front-end Serviceの詳細も見ておこう。とはいっても特別見る点はないが。

Octaviaによって作られたLoadBalancer自体を確認しておく。名前が分かりにくい…(当然だが、各idはダミー)

このLoadBalancerや関連リソース(listener、pool、member)はKubernetes側でリソースを消すと自動的に削除されるので便利である。

なお、デフォルトではマニフェストで許可したポートについて、0.0.0.0/0からのアクセスを許可した状態となっている。要件によってはここを制限したくなることがあると思うが、これをマニフェストから設定できるのかは今後調査したい。さらには、Kubernetes on AWS: LoadBalancer型 Service との決別のように、LoadBalancerをTerraformで作成してKubernetesと繋ぐという手段も考えられるので、そちらも検証したいところである。

香川大学工学部の特別講義で講演した

1月19日(金)に、母校である香川大学工学部の特別講義で講演してきた。内容は学部3年生がメインの聴衆ということで、自分が今している仕事の紹介や何が楽しくてやっているのか?という話。

自分が学生の頃から特別講義は存在していたのだけど、まさか自分が話す立場になるとは当時想像だにしていなかったのでなかなか感慨深い。去年の夏に帰省した時、出身学科内の学生や教員によるビアガーデン飲み会に急遽参加したのだけど、そこで話さないか?と誘われたのがきっかけだった。

エンジニアリングに興味のある学生に対してインフラやSREといった分野の魅力を少しでも伝えることができたのであれば幸いである。また、自分はエンジニアとして仕事を始めてだいたい5年くらいなのだけど、これまでのキャリアを振り返るのにもちょうどよかったのではないかな。

今回よかったことの1つが、説明のレベルが適切だったと担当教員の方にコメントをいただいたこと。

もちろんOBであったことが大きな要因ではあるが、昔から非エンジニアの方などに説明することは多かったりしたし、そういうことが結構得意なのかも?と少し自信を持つことができたかなあ。

1時間話すという経験もできたし、非常によい大学訪問でした。今後も機会があればぜひ行きたい。

Kubernetes Invitational Meetup Tokyo #2

メルカリで開催されたKubernetes Invitational Meetup Tokyo #2に行ってきた。CNCF周辺で仕事してる人が多いので刺激になるし、久しぶりに会う人もいたのでよかった。LTがめちゃくちゃあって、CRI-Oやrkt、kubecon、Certified Kubernetes Administrator 、自宅k8s、spinnakerはいいぞ話、辛い話、memcached operatorなどの話を聞いた。kubeadmを使ってself-hostedな環境を作れるという話を聞いたのでチャレンジしたい(前も言ったな)。後、既にk8s上でバリバリマイクロサービス動かしていて、どう継続的デリバリーするかとか、カオスエンジニアリングしていけばいいか、という話も結構聞いて、k8s前提の世界だなあという印象。自分はまだまだそこまで行けてないなあ。

すげー広いイベント会場ができててすごかった

 

kubesprayを使ってOpenStack上にKubernetesを構築する

kubernetes-incubator/kubesprayは複数の環境(AWS、GCE、Azure、OpenStack、Baremetal)に対応したKubernetesクラスタのデプロイツールです。kubespray自体はAnsibleやTerraform用のコードで構成されています。今回はkubersprayを使い、OpenStack上にKubernetes環境を構築します。

Terraformでクラスタ用のインスタンスを作成する

まずはクラスタ用のインスタンスを作成します。kubesprayにはTerraformでインスタンスを建てるためのconfigurationファイルが付属しているので、これを使ってみます。なお、Configurationはv1.0以降ではRemovedな機能を使っているので、v0.9.11を使います。

添付されているConfigurationはかなりよくできていて、tfvarsで設定を変えるだけでいろいろな構成のクラスタを構築できます。今回はk8s-masterを3台、k8s-nodeを2台(内1台はFloatingIPを持たない)という構成にするので、terraform.tfvarsは以下のようになりました。

terraform apply 前の注意点として、作成されるセキュリティグループに 0.0.0.0/0 からのアクセスを許可するルールが2つあるのでここを修正しておくのがよいかもしれません。リソースを作成し終わると以下のようにインスタンスが作られています。

Ansibleを適用し、Kubernetesクラスタを作る

各インスタンスにSSHでアクセスできるかチェックする

インスタンスを作成できたので次はAnsibleを適用します。まず、各インスタンスにSSHでアクセスできるのかどうかを確認します。以下のコマンドで疎通確認が可能です。ansible_python_interpreter を指定しているのは、各インスタンスのOSであるubuntu-16.04には /usr/bin/python がなく、/usr/bin/python3 であるためです。

ここで、アクセス先のIPアドレスを全く指定していないことに気づくかもしれません。AnsibleにはDynamic Inventoryという機能があり、ファイルやAPIから自動的に適用先の情報を取得することができます。ここでは、Terraformのtfstateファイルから適用先を取得しているというわけです。また、FloatingIPがついていないalpaca-k8s-node-nf-1 へSSHするため、terraform apply 時点で踏み台の設定も生成しています。contrib/terraform/openstack/group_vars/no-floating.yml というファイルがそれで、no-floating グループであればこの設定を用い、踏み台経由でSSHするというわけです。非常によくできているなーと思います。

Ansibleを適用する

各インスタンスにSSHでアクセスできることを確認したので、Ansibleを適用します。

extra-varsをpretty printしたものは以下の通りです。

実行したら30分〜40分ほどかかるので、コーヒーを飲んだりして待ちます。

終わったら artifacts/admin.conf にkubectl用のコンフィグが生成されているので、~/.kube/config へ配置します。

また、admin.conf内のアクセス先がhttps://kubernetes.default:6443となっているはずです。 /etc/hosts に設定して、アクセスできるようにします。

さて、いよいよノード一覧を見てみましょう。6台のノードが全てReadyになっているはずです。

サービスを動かしてみる

Kubernetes環境ができたので、試しにサービスを動かしてみます。今回はmicroservices-demo/microservices-demo にします。まず、ネームスペースを作成します。

その後は各種サービスを一気に作成します。

ポッド一覧。

サービス一覧。

front-endサービスからアクセスするのだけど、これはデフォルトではNodePortとなっています。ノードにアタッチされているFIPの30001番ポートにアクセスするとsock-shopを利用できるはずです。

front-endポッドはalpaca-k8s-master-2 にいるので、そのFIPにアクセスして、HTMLが帰ってくればOKです。

まとめ

複数の環境に対応したKubernetesクラスタのデプロイツールであるkubersprayを用いて、OpenStack上にKubernetesクラスタを構築しました。また、その上でmicroservices-demo/microservices-demo を動かし、NodePort経由でアクセスできることを確認しました。

Kubernetes v1.9では、OpenStackのOctaviaがサポートされたようです。LBaaSとしてOctaviaを使っている場合、これを使うことで外部ネットワークとうまくやりとりできるのではないか、と期待します。