Cluster

Kubernetesで何らかの永続データを保存する場合、通常PersistentVolumeと呼ばれる永続ストレージを使用します。Persistent VolumeはNFSなどのネットワークストレージを直接指定することもできますが、ボリュームを手動で用意する必要があり、非常に面倒です。 そのため、ブロックストレージサービスをバックエンドとしてdynamic provisioningと呼ばれる、自動でボリュームを作成する機能も用意されています。 dynamic provisioningを使用する場合、バックエンドのprovisionerをStorageClassと呼ばれるリソースに登録しておきます。クラウドでKubernetesを使用している場合はAWS EBSなどを使用するでしょう。 オンプレミスや自宅でKubernetesを使用している場合、GlusterFSやCeph RBDを使用することができます。今回はCephを使用してPersistentVolumeを作成するまでの流れを説明しましょう。 下準備 今回はOpenNebula上にCentOS 7のVM(2GB RAM/1Core CPU)を3台用意し、構築を行いました。バージョンはmimicです。/dev/vdbにCeph用のディスクがあるとします。 それぞれ、Chronyで時刻同期の設定、firewalld無効化、SELinux無効化状態で構成しました(本番ではちゃんと設定してくださいね！)。 また、ceph-1 ceph-2 ceph-3という名称でアクセスできるよう、hostsファイルを書いて、SSHの鍵もコピーしました。 インストール まずは公式サイト を参考に各サーバへリポジトリの追加をします。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 /root@ceph-N# rpm --import 'https://download.ceph.com/keys/release.asc' /root@ceph-N# cat < EOF > /etc/repos.d/ceph.repo [ceph] name=Ceph packages for $basearch baseurl=https://download.ceph.com/rpm-mimic/el7/$basearch enabled=1 priority=2 gpgcheck=1 gpgkey=https://download.ceph.com/keys/release.asc [ceph-noarch] name=Ceph noarch packages baseurl=https://download....

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からは次の様に見えます。 1 2 3 $ kubectl get svc --name external-services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ghost ExternalName <none> 192....

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....

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....

注意: 情報が古くなっています。新しい情報にあわせて記事を書いた ので、そちらをご覧ください。 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 あとは構成が終了するのを待つだけです。...