Kubernetes

TL;DR Service type: ExternalNameを使用する External Service Kubernetes では、Ingress を使用することで、ホスト名ベースのロードバランシング/リバースプロキシを行うことが出来ます。その際、プロキシ先としてKubernetes上のService を指定するのですが、場合によってはKubernetesクラスタ外のサービスをプロキシ先としたい場合があります。例えば、弊宅の環境では、次の様にプロキシしています。 基盤であるOpenNebulaのダッシュボード以外は*.web-apps.techとして、Kubernetesへとルーティングしています。 ところで、本ブログは現在Kubernetes上へ移行作業中です。今のところはまだ、Kubernetes上へ載せていません。しかし、折角プロキシの設定が減っているので、blog.web-apps.techもIngressリソースとして管理したいです。 そこで使用できるのがService type: ExternalNameです。ExternalNameとして外部サービスを登録することで、Ingressのバックエンドとして使用できるようになります。 設定 設定はごく簡単で、次の様にします。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 --- apiVersion: v1 kind: Namespace metadata: name: external-services --- apiVersion: v1 kind: Service metadata: name: ghost namespace: external-services spec: type: ExternalName externalName: 192.168.1.41 # 本ブログのローカルIP 今後も何かの拍子でKubernetesに載せたくないサービスが増える可能性もあるため、external-servicesとして名前空間を分離しました。このように設定すると、kubectlからは次の様に見えます。 ...

TL;DR ingress-nginxを使用するとオンプレでもIngressを使用出来る MetalLBと組み合わせる Ingress IngressはKubernetes の機能の一つで、L7 LoadBalancerの機能を持ちます。先日紹介した type LoadBalancerは、L4 LoadBalancerで、クラスタ内のDNSで名前解決をし、IP制限などをすることが出来ます。それに対し、Ingressでは、HTTPSの終端となることが出来、ホスト名ベース・パスベースのルーティングを行うことが出来ます。 通常、オンプレでKubernetesを構築した場合、Ingress Controllerと呼ばれる、Ingressを作成する機能が無いためにIngressを使用することが出来ません。 しかし、折角Kubernetesを使用しているのに、ホスト名ベースのルーティングをクラスタ外のロードバランサーに設定するのは面倒です。 どうせならIngress、使いたいですね？ そこで使用できるのがingress-nginx (GitHub: kubernetes/ingress-nginx )です。ingress-nginxはその名のとおり、nginxを使用したIngress Controllerです。Ingressリソースの作成時に、nginxの設定をConfigMapとして保存することでIngressの作成を実現します。 Install MetalLBをインストール している場合、次の二つのコマンドを実行することでインストールできます。 1 2 $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml 二行目のコマンドはドキュメント上では docker for macのコマンドとして記載されていますが、type: LoadBalancerが使用できるクラスタ一般で使用できます。 インストールが完了したら、ingress-nginxのサービスにIPアドレスが割当たります。 1 2 3 4 $ kubectl get svc -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default-http-backend ClusterIP 10.233.50.56 <none> 80/TCP 2d ingress-nginx LoadBalancer 10.233.47.246 192.168.1.100 80:30431/TCP,443:30017/TCP 2d 実際にブラウザでingress-nginxのIPアドレスにアクセスしてみて、default backend - 404と表示されれば正常に動作しています。 ...

TL;DR MetalLBを使用することでオンプレ(not on OpenStack)に構築したk8sでもtype: LoadBalancerを使用できる type: LoadBalancer kubespray 等を使用して、Kubernetes をオンプレ(on OpenStackを除く)で構築した場合、通常、type: LoadBalancer を使用することができません。これは、type: LoadBalancerは通常CloudProviderにより管理されており、オンプレ(on OpenStackを除く)でk8sを構築した場合にはCloudProvider連携が無いためです。 しかし、k8sを使用するからにはtype: LoadBalancerも使用したいですよね？NodePortなどで代用するにも、ポートがバラバラになってしまって面倒です。 そこで使用できるのがMetalLB (GitHub: google/metallb )です。 MetalLBを使用すると、type LoadBalancerの作成をフックしてアドレス割り当てとアドレスの広報を行ってくれます。 Layer 2 mode MetalLBにはLayer 2 mode(以下L2 mode)とBGP modeがあります。これらのモードはアドレス広報の仕方が違い、L2 modeではARP/NDPで、BGP modeではその名の通りBGPでアドレスの広報を行います。通常、自宅を含むオンプレ環境ではBGPを使用していないと思いますので、L2 modeについて解説します。 L2 modeでは、特定のノードへアクセスを集中させ、kube-proxyによって各サービスへトラフィックを分配します。そのため、実態としてはロードバランサーが実装されている訳ではないことに注意が必要です。単体ノードにアクセスが集中するため、これがボトルネックとなり得ますし、アクセスが集中することになるノードが何らかの理由でアクセスできなくなった場合、フェイルオーバーに10秒程度かかる可能性があります。 requirements & installation 導入は非常に簡単ですが、以下の要件を満たしている必要があります。 他にネットワークロードバランシングの機能が無いKubernetes 1.9.0以降 MetalLB対応表 に記載のあるネットワークで設定されていること これに加え、MetalLBで使用することのできるIPv4アドレスを用意しておく必要があります。 私の環境ではk8sのノードが192.168.1.0/24にあるため、192.168.1.100から192.168.1.159までの60個のアドレスをMetalLB用としました。 要件を満たしていることが確認できたら、MetalLBのインストールを行います。 MetalLBをインストールするには、次のコマンドを実行します。 1 $ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.2/manifests/metallb.yaml Helm を使用してインストールすることもできますが、Chartが最新版ではないので注意しましょう。 次に、次のようなConfigMapを作成します。 1 2 3 4 5 6 7 8 9 10 11 12 apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | address-pools: - name: default protocol: layer2 addresses: - 192.168.1.100-192.168.1.159 これでMetalLBのセットアップは完了です。パブリッククラウドで使用するように、type: LoadBalancerを作成するとアドレスプールからIPアドレスが割り当てられ、アクセスできるようになります。 アドレスプールは複数用意することができ、特定のアドレスプールからIPを割り当てたい場合はtype: LoadBalancerのアノテーションにmetallb.universe.tf/address-pool: <ADDRESS_POOL_NAME>を追加します。 ...

Kubernetes によるヘルスチェックには、Liveness ProbeとReadiness Probeと呼ばれる二つのものがあります。これらは混乱しがちな一方、日本語による情報が多くない(2018/07/26現在で、Google検索の1ページ目にヒットするのが4件ほど)ため、ここで一つ情報をまとめておきます。 共通 Liveness ProbeとReadiness Probeの設定は共通で、DeploymentやPodのマニフェスト内で、containersの中にlivenessProbeとreadinessProbeとしてそれぞれProbe spec を記述します。 次の項目を設定することが出来ます。 failureThreshold Success状態の時、何回失敗したらFailureになるか。最小で1回。 Default: 3 initialDelaySeconds コンテナが起動してからヘルスチェックを始めるまでの秒数。 Default: 0 periodSeconds ヘルスチェックの間隔。最小で1秒 Default: 10 successThreshold Failure状態の時、何回成功したらSuccessになるか。最小で1回。 Default: 1 timeoutSeconds ヘルスチェックのタイムアウト秒数。最小で1秒。 Default: 1 httpGet ヘルスチェックでアクセスするhttpエンドポイントの情報を書く。 httpGetの項目は次の様な項目を持ったobjectを書きます。 host 対象のホスト名。 Default: PodのIP httpHeaders リクエストのカスタムヘッダ指定。{name: HEADER_NAME, value: HEADER_VALUE}の形のオブジェクトの配列で書く。 port アクセスするポート番号または名称 path アクセスするパス。 scheme アクセスする際のスキーム。 Default: HTTP Liveness Probe 一つ目はLiveness Probeです。公式ドキュメント には次の様に書いてあります。 livenessProbe: Indicates whether the Container is running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy . If a Container does not provide a liveness probe, the default state is Success. ...

AWSのmanaged Kubernetesで、これまでプライベートベータだったElastic Container Service for Kubernetes がGAになった ということなので、さくっとクラスタを作成してみました。1 参考にしたのはAWS公式、EKSのGetting Started Guide です。 まずはEKSのページを見てみようとしたところ・・・ ぶっ壊れてますね！これはなんかアレですね。 gettext的なのが上手くいっていないように見えるので、画面下から英語にしてみます。 無事、正しいと思われるページが表示されました。 なんか、How it worksの説明の図がちょっとぼやけて見えるのは環境のせいでしょうか。 扨、ここからGetting Startedしていきます。 まずはEKS用のIAMロールを作っていきます。 IAMロール作成画面のサービスリストにEKSが追加されていますので、これを選択します。 ユースケースは一つしかなく、選択済みになっています。 フムー。 IAMロールが出来ました。 CloudFormationでクラスタを組んでいきます。 今のところ、EKSが使えるリージョンはUS West(Oregon) (us-west-2)とUS East(N.Virginia) (us-east-1)の二カ所です。今回はUS Eastでやっていきます。 CloudFormationでCreate Stackをやっていきましょう。 S3 template URLが用意されていますので、これを入力します。 template URLはhttps://amazon-eks.s3-us-west-2.amazonaws.com/1.10.3/2018-06-05/amazon-eks-vpc-sample.yamlです。 Viewしてみるとこんな感じです。なるほど。 細かい設定的なところは全くいじらず、さくさく進めていきます。Stack nameはGettingStartedにしました。 できた。 Outputのタグを選択して、SecurityGroupsとVpcIdとSubnetIdsを(一応)メモっておきます。2 次にkubectlの設定をしておきます。 最新のkubectl(1.10以降)をインストールしておいてください。まだインストールしていない場合はEKS側でも配信しているようなのでそれを使ってもOKです。 EKSでは認証にheptio-authenticator-awsを使用するようなので、こちらもドキュメントに従い導入します。 私はいろいろ考えるのが面倒だったため、go getしました。 1 $ go get -u -v github.com/heptio/authenticator/cmd/heptio-authenticator-aws ヘルプを表示して、正常に導入出来たかざっくり確認します。 1 $ heptio-authenticator-aws help ここで注意なのですが、ガイドではDownload and Install the Latest AWS CLIのところにOptionalってついてるんですが、これはほぼ必須です。 AWS CLIがないとクラスタに接続出来ないので、AWS CLIをインストールしておきます。 ...

Japan Container Days v18.04 で表題のセッションを聞いたので、まとめました。 スライド資料 Kubernetesのセキュリティのベストプラクティス(SpeakerDeck) APIサーバへの攻撃を防ぐ RBACでPodに付与される権限を絞る Podにはシークレットが自動でマウントされるため、不正アクセスにより読み込まれてしまうと危ない FirewallでAPIサーバへのアクセスについてIP制限を付与する いざ、シークレットが漏れた場合でも、APIサーバにアクセスされてしまわないように、ファイアウォールでIP制限をかけておくと良い NetworkPolicyでDBへの接続が許可されるPodを制限する 大体の場合、重要なデータはDBに有るため、DBへのアクセスを絞ることで安全性を上げる example: 1 2 3 4 5 6 7 8 9 10 11 12 13 kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: redis spec: podSelector: matchLabels: name: redis ingress: - from: - podSelector: matchLabels: name: guestBook ホストへの攻撃を防ぐ 次の三つを併用すると良い non-rootユーザでPodを実行する example: 1 2 3 4 5 6 7 kind: Pod apiVersion: v1 metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 読み込み専用ファイルシステムを使用する example: 1 2 3 4 5 6 7 kind: Pod apiVersion: v1 metadata: name: security-context-demo spec: securityContext: readOnlyRootFilesystem: true no_new_privs forkしたプロセスが強い権限を持てないようにする ...

3ヶ月ほど前に、kubesprayを使用してkubernetes clusterを構築する という、kubespray とkubespray-cliを使用してKubernetesクラスタを構築する記事を書きました。 しかし、kubespray-cliはすでにdeprecatedだということなので 、kubespray-cliを使用せずにkubesprayでクラスタを構築する手順をまとめておきます。 要件 kubesprayを使用してkubernetesクラスタを構築するための要件は以下のようになっています。 ansible 2.4以降とpython-netaddr (python-netaddrを忘れがちなので注意) pip install ansible netaddr Jinja 2.9以降(ansibleの依存でインストールされると思います) 構築先サーバがインターネットに接続できること 構築先サーバでswapが無効化されていること 構築先サーバでIPv4 forwardingが有効になっていること sysctl -w net.ipv4.ip_forward=1する(再起動するまで) /etc/sysctl.confにnet.ipv4.ip_forward = 1と記入する(再起動後) Ansibleを実行するマシンから構築先サーバにSSH鍵が渡されていること ファイアウォールが無効化されていること ファイアウォールの設定をしっかりできる人は有効でも また、kubesprayには(kubespray-cliのような)inventory生成ツールが付属されており、これを利用する場合はpython3系である必要が有ります。 構成 前回の記事同様、以下のIPを持った三台のサーバを対象として構築してみます。 192.168.1.11 192.168.1.12 192.168.1.13 それぞれ、IPv4 forwardingが有効化され、firewalldを無効化し、Python 3をインストール済みのCentOS 7のサーバとします。また、kubesprayを実行するローカルマシンから、各サーバのrootユーザにSSH鍵を配置1済みとします。 手順 準備 まず、kubesprayをダウンロードします。 1 2 $ git clone https://github.com/kubernetes-incubator/kubespray $ cd kubespray リポジトリのクローンが完了したら、ansibleなどの依存モジュールを導入します2。 1 kubespray$ pip install -r requirements.txt 次に、ansible用のインベントリを作成します。 1 2 3 kubespray$ cp -rfp inventory/sample inventory/mycluster kubespray$ declare -a IPS=(192.168.1.11 192.168.1.12 192.168.1.13) CONFIG_FILE=inventory/mycluster/hosts.ini python3 contrib/inventory_builder/inventory.py ${IPS[@]} IPSは対象サーバのIPに合わせて定義をします。 また、環境によっては、python3コマンドではなく、pythonコマンドでPython 3が実行される場合も有ります。適宜読み替えてください。 ...

DockerCon EU 2017で、DockerがKubernetesを統合・サポートすると発表されました が、本日ついにKubernetesサポート版Docker for macが(Edgeリリースですが)リリースされました！ これにより、macを使用している場合は(おそらく過去最も簡単に)開発用Kubernetesクラスタを起動することができるようになりました！ この記事では、Docker for macでKubernetesを立ちあげる手順をまとめておきます。 Kubernetesの起動手順 Docker for macのStable版を利用している場合、Edge版をインストールする必要があります。 Install Docker for mac のページから、Edge Channelのインストーラをダウンロードし、インストールします。 Dockerを終了させておけば、Stable版を自分でアンインストールする必要はありません1。 Edge版をインストールし、Dockerの設定画面を開くと、以下の様にKubernetesタブが追加されています！！ Kubernetesタブで、Kubernetesの有効化・無効化を簡単に切り替えることができます。 Enable Kubernetesにチェックを入れ(Show system containersはお好みで)、Apply & Restartボタンを押すと、「Kubernetesの初回インストールは少し時間かかるけど、インストールする？」という確認画面が出るので、Installを押します。 一応プログレスバーが出るのですが、余り意味はありませんでした・・・ 数分でインストールが終わります。 無事インストールが終了したら、Closeを押したあと、設定画面を閉じます。 この時点で、DockerメニューにもKubernetesのステータスが表示されています。 今回私はShow system containersをオンにしたので、docker ps2するとKubernetesの動作に必要なコンテナが起動しています。 DNS、API Server、Etcd、Scheduler、Proxyと最小限の構成ですね。 kubectlが自動でインストールされるのかどうかは・・・・わかりませんでした。(すでにインストール済みだったため) kubectlがインストール済みの場合、自動でコンフィグが追加され、以下のコマンドでcontextを選択することで操作できるようになります。 $ kubectl config use-context docker-for-desktop kubectl get nodesすると、確かに1ノード構成でクラスタが立ち上がっているのがわかります。 Edge版の初回起動時にアンインストールされます ↩︎ docker container lsと打つのは面倒ですね ↩︎

注意: 情報が古くなっています。新しい情報にあわせて記事を書いた ので、そちらをご覧ください。 kubespray はproduction readyなkubernetes(k8s)クラスタを構成できるツールです。 Ansible をベースに作られているため、任意のサーバでk8sクラスタを構成できます。 今回は、3台のVMを用意してクラスタを構成してみます1。 検証環境 今回用意したVMは以下の構成です。 2Core 8GB RAM 80GB HDD CentOS 7 IPアドレスは以下の様になっているものとします。 192.168.1.11 192.168.1.12 192.168.1.13 また、kubesprayを実行するローカルの環境はmacOS Sierraです。 各ホストのrootユーザに対してSSH鍵は配置済み、firewalldは無効化されているとします。 requirements 実行する環境に、Ansible が必要なため、pipでインストールします。23 1 $ pip install ansible install kubespray-cli kubespray自体もpipでインストールします。 1 $ pip install kubespray prepare 設定ファイルを生成するため、kubespray prepareを使用します。 1 $ kubespray prepare --nodes node1[ansible_ssh_host=192.168.1.11] node2[ansible_ssh_host=192.168.1.12] node3[ansible_ssh_host=192.168.1.13] deploy 以下のコマンドでk8sクラスタをデプロイします。 1 $ kubespray deploy -u root -n flannel 今回はflannel ネットワークプラグインで構成しました。 kubesprayは、次のネットワークプラグインを使用してクラスタを構成することができます。 flannel 4 calico 5 canal contiv 6 weave 7 あとは構成が終了するのを待つだけです。 ...