楽天クラウドから始めるKubernetes
見出し画像

楽天クラウドから始めるKubernetes

柳 松 クラウドプラットフォーム技術部 クラウド技術グループ

クラウドネイティブアプリケーションとインフラストラクチャの採用が企業や組織の成長を後押ししています。

IDC Japanが2020年5月12日に発表した調査結果(*1)によると本番環境でDockerなどのコンテナ仮想技術(以下コンテナ)とコンテナオーケストレーションツールのKubernetesを本番環境で使用している企業は14.2%となり、2019年調査から5.0ポイント上昇したとのことです。CaaS(Container as a Service)などのコンテナ向けクラウドサービスやベンダーとSIerのコンテナ導入支援の充実化が、企業のコンテナ導入を後押ししているとしています。さらに導入構築/テスト/検証段階にある企業は18.6%、導入計画/検討にある企業は19.0%となり、今後本番環境で使用する企業がさらに拡大することが見込まれています。
本編が読者の皆様のコンテナ導入に少しでもお役に立てれば幸甚です。
(*1)https://www.idc.com/getdoc.jsp?containerId=prJPJ46289720

1. コンテナ & コンテナオーケストレーション

画像1

出典:https://medium.com/wardleymaps

上記の図は技術成熟度を表す時によく使われている進化曲線です。パブリッククラウドとプライベートクラウドのVM技術(例:コンピューティングサービス)は、すでに右上のCommodityになっていますが、効率よく使えているかという課題があります。例えば、作られたインスタンスのリソースの利用率はどれくらい達成しているか、アイドルしているか、また多くのアプリケーションは異なる2つのリージョンのプロダクション、ステージング、開発の4つの環境を同時に立ち上げておく必要があるなど、管理する作業が課題となります。

VM技術の課題を解決ため、昨今、コンテナ型仮想化は軽量かつ迅速に、アプリケーションの実行環境を丸ごと別のマシンへ移植できる技術に注目されています。大規模プロダクション環境を稼働するため、コンテナの展開、管理、スケーリング、ネットワーキングを自動化、数百または数千のコンテナかホストをデプロイおよび管理するツールとして、コンテナオーケストレーションの必要性が生じています。以下は例の一部です。
- Apache Mesos
- Amazon Elastic Container Service (以下Amazon ECS)
- AWS Fargate ("コンテナ向けサーバーレスコンピューティング")
- HashiCorp Nomad
- RedHat OpenShift
- Kubernetes (マネージド or セルフホスト)

Amazon ECSなどの製品は多くの組織で使用されていて、信頼性の高いオプションであることが証明されていますが、提供される機能は限られていて、拡張できないAPIしか提供されておらず、「接着剤」としてAWS Lambdaに依存しています。また、すべてのAmazon Web Service(以下「AWS」)製品と同様に、お客様にAWSのやり方にも一定のコミットが求められます。Mesosについては最近使う人が少なくなってきています。一方で、NomadはシンプルさとHashiCorp社の他の製品との良好な統合に重点を置いた素晴らしいプロジェクトと言えます。また、RedHat OpenShiftはエンタープライズ向けKubernetesコンテナプラットフォームで、セキュリティや管理などを強化し、手厚いサポートが特徴です。

2. Kubernetes紹介

Kubernetesは、最も人気のあるコンテナオーケストレーションツールの1つとなったオープンソースプロジェクトです。マルチコンテナアプリケーションを大規模にデプロイして管理することができます。Kubernetesは最も人気のあるコンテナ化プラットフォームであるDockerで最も頻繁に使用されますが、コンテナイメージとランタイムのOpen Container Initiative(OCI)標準に準拠するコンテナでも動作します。また、Kubernetesはオープンソースであり、使用方法に関する制限が比較的少ないため、コンテナを実行したいなら誰でも、ほとんどの場合、オンプレミス、パブリッククラウド、またはその両方で自由に使用できます。

Kubernetesの歴史について少し紐解いてみましょう。
Kubernetesは、Google内のプロジェクトとして始まりました。Googleが内部で使用していた初期のコンテナ管理ツールであるGoogle Borgの後継とも言えます。Googleは2014年にKubernetesをオープンソース化しました。その理由の一部はKubernetesを使用することによって、分散型マイクロサービスアーキテクチャはクラウドでのアプリケーション実行が容易になることです。Googleは、コンテナ、マイクロサービス、Kubernetesの採用により、顧客を自社クラウドサービスに誘導できる可能性があると考えています(ただし、KubernetesはAzureやAWSでも確実に稼働できます)。Kubernetesは現在、Linux Foundation傘下にあるCloud Native Computing Foundationによって管理されています。

次にKubernetesの位置づけについてお話させていただきます。KubernetesはDockerのリプレースではなく、Dockerを強化するのもです。他のツールと比べると(Docker SwarmやMesos)現在、実質上の標準はKubernetesと言っても過言ではありません。もちろんまだCommodityになっていない段階なので、導入の際には考慮しなければならないところもあります。例えば、オープンソースのKubernetesの場合もちろんバグや不足している機能もあります。(https://github.com/kubernetes/kubernetes/issues?q=is:open+is:issue+label:kind/bug)また、追加の複雑さ、学習コストと運用コストに注意しないといけません。Google Kubernetes EngineAmazon EKSなどのマネージドKubernetes環境を使用することでコスト削減が可能で、クラウドプロバイダーの独自プラットフォームにすでに慣れているお客様には有効であると考えられます。また、Virtual Kubeletを使用すると、ノードを気にすることなくワークロードを実行できたり、Raspberry Piのようにリソースの少ないデバイスでも動くIoT向けK3Sなどさまざまな実現方法があります。次にGKE、EKS、OpenShiftなどKubernetes承認パートナー製品ではなく、Kubernetesを自分で構築したいお客様向けにセルフホストKubernetesを構築する方法をご紹介します。

3. Kubernetesアーキテクチャ:Kubernetes仕組みの説明

Kubernetesのアーキテクチャは、さまざまな概念と抽象化を利用しています。既存のよく知られている概念のバリエーションもありますが、その他はKubernetesに固有のものになっています。

- Kubernetesクラスター:最高レベルのKubernetes抽象概念です。Kubernetes(それ自体がクラスター化されたアプリケーション)を実行するマシンのグループと、それによって管理されるコンテナを指します。

- Kubernetesのノードとポッド:各クラスターにはKubernetesノードが含まれています。ノードは物理マシンまたはVMです。ノードは複数ポッドを実行できます。ポッドは、作成または管理できる最も基本的なKubernetesオブジェクトです。各ポッドは、Kubernetesでアプリケーションまたは実行中プロセスの単一のインスタンスを表し、1つ以上のコンテナで構成されます。

- Etcd:ポッドが起動される状態から、Kubernetesを構成する方法の詳細は、分散key-valueストアであるEtcdに保存されています。※Etcdは、プレーンテキストではなく、ノード間でシークレットを送信するときにSSL / TLSを使用するように構成する必要があります。

- Kubernetesサービス:Kubernetesサービスはアプリケーションのライフサイクルを処理するためのポッドと別の抽象化概念です。具体的に、Kubernetesサービスは複数ポッド(または他のKubernetesオブジェクト)にネットワーク上アクセスする方法を記述します。アプリケーションのバックエンドを構成するポッドは変更される場合がありますが、フロントエンドはその変更を認識したり追跡したりする必要はありません。サービスはこれを実現可能にします。

- Kubernetes Ingress:Kubernetesサービスは、クラスター内で実行されていると見なされます。ただし、これらのサービスに外部からアクセスできるようにする必要があります。Kubernetesには、NodePortやLoadBalancerなどを含め、異なるシンプルさと堅牢性(robustness)で実現するコンポーネントがありますが、最も柔軟性のあるコンポーネントはIngressです。Ingressは、クラスターのサービスへの外部アクセスを管理するAPIで、通常はHTTPを介しています。

- Kubernetes ダッシュボード:すべての他のコンポーネントの上位に管理するKubernetesコンポーネントはダッシュボードです。アプリケーションのデプロイとトラブルシューティング、およびクラスターリソースの管理に使用できるWebベースのUIです。

本番環境のソリューションを評価するときは、Kubernetesクラスターの運用のどの部分を自分で管理するか、もしくはプロバイダーにオフロードするかを検討してください。セルフホストなら、ローカルマシン、クラウド、またオンプレミスのデータセンターにKubernetesクラスターをデプロイする方法を選択できます。下記は楽天クラウド上にKubernetesを構築する方法を紹介します。

Kubernetesオフィシャルウェブサイトには3つの本番構築方法が記載されています。
- kubeadmによるクラスターのブートストラップ
- Kopsを使用したKubernetesのインストール
- Kubesprayを使用したKubernetesのインストール

Kubeadmでは、(比較的) 簡単に、実行可能な最小のKubernetesクラスターをブートストラップできます。ただし、アドオンとネットワーク設定はどちらもKubeadmの範囲外であるため、手動または別のツールを使用してインストールする必要があります。Kopsでは、実稼働レベルのKubernetesクラスターの構築と管理を、AWS上で行えます。その他のプラットフォーム移植も計画中で、例えばGoogle Compute Engine(以下「GCE」)のbetaサポート、VMware vSphereのalphaおよびその他のプラットフォームサポートが計画されているそうです。3つ目のKubesprayでは、AnsibleのDevOpsプログラムを使用して、実稼働用Kubernetesクラスターを構築、構成、管理できます。またAWS、GCE、Azure、OpenStack、またはベアメタルのIaaSプラットフォームを使用できます。

本篇はKubesprayを利用して、プロダクション環境に使えるKubernetesクラスターを構築する方法をご紹介します。

4. Kubernetes導入

楽天クラウドで、下記のVMを展開して構築します。

画像2

BastionのみフローティングIPをつけておきます。前提条件にある通り、ネットワークについて、デプロイ中の問題を回避するために、ファイアウォールを無効にしておく必要があります。安全性を考慮して、全ポート開放ではなく、セキュリティグループを使って、必要なポートのみの開放ポリシーを設定いただくことをお勧めします。

構成は下記の図を参考としてください。

画像3

下から導入に入ります。
必要なソフトウェアをインストールします。まずはPythonです。

sudo yum -y install epel-release
sudo yum -y groupinstall "Development tools"
sudo yum -y install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel libffi-devel libuuid-devel
wget https://www.python.org/ftp/python/3.8.3/Python-3.8.3.tar.xz
tar -xvJf Python-3.8.3.tar.xz
sudo mkdir /usr/local/python3
cd Python-3.8.3/
sudo ./configure --prefix=/usr/local/python3
sudo make && sudo make install
sudo ln -s /usr/local/python3/bin/python3 /usr/local/bin/python3
sudo ln -s /usr/local/python3/bin/pip3 /usr/local/bin/pip3

Pythonのインストールを検証します。

[r-user@k8s-bastion Python-3.8.3]$ python3 -V
Python 3.8.3
[r-user@k8s-bastion Python-3.8.3]$ pip3 -V
pip 19.2.3 from /usr/local/python3/lib/python3.8/site-packages/pip (python 3.8)

PIPをアップグレードします。(sudo環境でCommand not foundが提示されたら、/etc/sudoersのDefault secure_pathにpathを追加しておいてください。)

[r-user@k8s-bastion Python-3.8.3]$ sudo pip3 install --upgrade pip
Collecting pip
 Downloading https://files.pythonhosted.org/packages/43/84/23ed6a1796480a6f1a2d38f2802901d078266bda38388954d01d3f2e821d/pip-20.1.1-py2.py3-none-any.whl (1.5MB)
    |████████████████████████████████| 1.5MB 4.3MB/s
Installing collected packages: pip
 Found existing installation: pip 19.2.3
   Uninstalling pip-19.2.3:
     Successfully uninstalled pip-19.2.3
Successfully installed pip-20.1.1

次はsshキーをインベントリのすべてのノードにコピーします。

ssh-keygen
scp -i ~/.ssh/sample-key-001.pem ~/.ssh/id_rsa.pub r-user@172.18.1.111:~/.ssh
scp -i ~/.ssh/sample-key-001.pem ~/.ssh/id_rsa.pub r-user@172.18.1.103:~/.ssh
scp -i ~/.ssh/sample-key-001.pem ~/.ssh/id_rsa.pub r-user@172.18.1.120:~/.ssh

そして、各ノードにログインして、次のコマンドを実行して完成です。

cat .ssh/id_rsa.pub >> .ssh/authorized_keys

python-netaddrをインストールします。

sudo yum -y install python-netaddr

KubeSprayをクローンします。

wget https://github.com/kubernetes-sigs/kubespray/archive/v2.13.2.tar.gz
tar zxvf v2.13.2.tar.gz
cd kubespray-2.13.2

Ansibleなど他に必要なソフトウェアは、KubeSprayのrequirments.txtファイルを使って、pipコマンドでインストールします。

[r-user@k8s-bastion kubespray-2.13.2]$ sudo pip3 install -r requirements.txt
[r-user@k8s-bastion kubespray-2.13.2]$ pip3 list
Package          Version
---------------- ---------
ansible          2.9.6
certifi          2020.6.20
cffi             1.14.0
chardet          3.0.4
cryptography     2.9.2
hvac             0.10.0
idna             2.9
Jinja2           2.11.1
jmespath         0.9.5
MarkupSafe       1.1.1
netaddr          0.7.19
pbr              5.4.4
pip              20.1.1
pycparser        2.20
PyYAML           5.3.1
requests         2.24.0
ruamel.yaml      0.16.10
ruamel.yaml.clib 0.2.0
setuptools       41.2.0
six              1.15.0
urllib3          1.25.9

Ansibleを実行に必要なパスは下のように追加します。 

​export PATH=$PATH:/usr/local/python3/bin/

次の手順はファイルコピーです。

cp -rfp inventory/sample inventory/mycluster

Ansibleインベントリファイルを更新します。

declare -a IPS=(172.18.1.111 172.18.1.103 172.18.1.120)
CONFIG_FILE=inventory/mycluster/hosts.yml python3 contrib/inventory_builder/inventory.py ${IPS[@]}

上記のIPアドレスはmasterとworkerノードのIPです。

構成をカスタマイズしたい場合は下のファイルで確認します。

cat inventory/mycluster/group_vars/all/all.yml
cat inventory/mycluster/group_vars/k8s-cluster/k8s-cluster.yml

次にクラスターインストール時に利用するInventory・Playbookを書き換えます。はじめに各ファイルの内容を確認します。まずはInventoryとして利用するhosts.ymlファイルです。今回は172.18.1.111のIPアドレスを持つマシンをMasterノード、それ以外をWorkerノードとして利用するため、以下のように書き換えます。

[r-user@k8s-bastion mycluster]$ pwd
/home/r-user/kubespray-2.13.2/inventory/mycluster
[r-user@k8s-bastion mycluster]$ cat hosts.yml
all:
 hosts:
   k8s-master: # revised
     ansible_host: 172.18.1.111
     ip: 172.18.1.111
     access_ip: 172.18.1.111
   k8s-worker01: #revised
     ansible_host: 172.18.1.103
     ip: 172.18.1.103
     access_ip: 172.18.1.103
   k8s-worker02: # revised
     ansible_host: 172.18.1.120
     ip: 172.18.1.120
     access_ip: 172.18.1.120
 children:
   kube-master:
     hosts: # revised
       k8s-master:
   kube-node:
     hosts: # revised
       k8s-worker01:
       k8s-worker02:
   etcd:
     hosts: # revised
       k8s-master:
   k8s-cluster:
     children:
       kube-master:
       kube-node:
   calico-rr:
     hosts: {}

上記ファイルを眺めると、以下のような階層構造になっていることがわかります。

画像4

なおcalico-rrは通常利用することはありませんが、例えば大規模クラスターを構築し、一部ノード間での通信を許可したくない場合などに利用するようです。今回はMasterノードを1つ、Workerノードを2つ用意しましたが、HA構成を組む場合はMasterノード(etcdノード)を「奇数」個分(3、5、7・・・台)用意し、hosts.ymlに記載することはベストプラクティスです。

またInventoryとして利用できるファイルはhosts.ymlだけではありません。
Kubesprayではあらかじめinventory.iniファイルを用意しています。以下にファイルの内容を載せます。

[r-user@k8s-node-1 mycluster]$ cat inventory.ini 
# ## Configure 'ip' variable to bind kubernetes services on a
# ## different ip than the default iface
# ## We should set etcd_member_name for etcd cluster. The node that is not a etcd member do not need to set the value, or can set the empty string value.
[all]
# node1 ansible_host=95.54.0.12  # ip=10.3.0.1 etcd_member_name=etcd1
# node2 ansible_host=95.54.0.13  # ip=10.3.0.2 etcd_member_name=etcd2
# node3 ansible_host=95.54.0.14  # ip=10.3.0.3 etcd_member_name=etcd3
# node4 ansible_host=95.54.0.15  # ip=10.3.0.4 etcd_member_name=etcd4
# node5 ansible_host=95.54.0.16  # ip=10.3.0.5 etcd_member_name=etcd5
# node6 ansible_host=95.54.0.17  # ip=10.3.0.6 etcd_member_name=etcd6
# ## configure a bastion host if your nodes are not directly reachable
# bastion ansible_host=x.x.x.x ansible_user=some_user
[kube-master]
# node1
# node2
[etcd]
# node1
# node2
# node3
[kube-node]
# node2
# node3
# node4
# node5
# node6
[calico-rr]
[k8s-cluster:children]
kube-master
kube-node
calico-rr

上記ファイルを眺めると、hosts.ymlと同じようなカテゴリーが並んでいることが分かるかと思います。それぞれのカテゴリーの関係性は上記階層構造と同様になります。

続いてPlaybookとして利用するcluster.ymlファイルは以下で確認できます。
cat ~/kubespray-2.13.2/cluster.yml
出力は省略いたします。
cluster.ymlにはKubernetesクラスターを構築する手順を記載しています。
各タスクはKubesprayのrolesフォルダにて定義されています。

rolesフォルダの内容確認をします。

[r-user@k8s-bastion roles]$ pwd
/home/r-user/kubespray-2.13.2/roles
[r-user@k8s-bastion roles]$ ls -l
total 4
drwxrwxr-x  5 r-user r-user   47 Jun 19 15:43 adduser
drwxrwxr-x  4 r-user r-user   36 Jun 19 15:43 bastion-ssh-config
drwxrwxr-x  6 r-user r-user   81 Jun 19 15:43 bootstrap-os
drwxrwxr-x  7 r-user r-user   85 Jun 19 15:43 container-engine
drwxrwxr-x  6 r-user r-user   64 Jun 19 15:43 download
drwxrwxr-x  7 r-user r-user   80 Jun 19 15:43 etcd
drwxrwxr-x  9 r-user r-user  111 Jun 19 15:43 kubernetes
drwxrwxr-x 18 r-user r-user 4096 Jun 19 15:43 kubernetes-apps
drwxrwxr-x  5 r-user r-user   47 Jun 19 15:43 kubespray-defaults
drwxrwxr-x 14 r-user r-user  176 Jun 19 15:43 network_plugin
drwxrwxr-x  5 r-user r-user   66 Jun 19 15:43 recover_control_plane
drwxrwxr-x  4 r-user r-user   43 Jun 19 15:43 remove-node
drwxrwxr-x  4 r-user r-user   35 Jun 19 15:43 reset
drwxrwxr-x  4 r-user r-user   45 Jun 19 15:43 upgrade
drwxrwxr-x  3 r-user r-user   30 Jun 19 15:43 win_nodes

それでは、最後のステップはansible-playbookを使ってクラスターをデプロイします。前述の通りansible-playbookコマンドは、InventoryとPlaybookファイルを指定します。

ansible-playbook -i inventory/mycluster/hosts.yml cluster.yml --become --become-user=root -v 

各オプションは以下の用途で利用します。
 -i:Inventoryファイルを指定
 -b:--become-method。接続ユーザー以外で対象ホストを操作する
   ために使用する
 -v:詳細な情報を出力
上記コマンドを実行し、数分ほど待つと完了します。

問題なく終了の場合は出力内容が次のようになります。

PLAY RECAP **********************************************************************************************************************************************************************k8s-master                 : ok=539  changed=28   unreachable=0    failed=0    skipped=1045 rescued=0    ignored=0
k8s-worker01               : ok=343  changed=25   unreachable=0    failed=0    skipped=561  rescued=0    ignored=0
k8s-worker02               : ok=343  changed=25   unreachable=0    failed=0    skipped=560  rescued=0    ignored=0
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
Monday 22 June 2020  23:10:04 +0900 (0:00:00.062)       0:05:53.392 ***********

所要時間は6分間弱でした。以上でKubernetesクラスターの構築は完了です。

次はkubectlをインストールします。

[r-user@k8s-bastion ~]$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 41.9M  100 41.9M    0     0  55.3M      0 --:--:-- --:--:-- --:--:-- 55.3M
[r-user@k8s-bastion ~]$ chmod +x ./kubectl
[r-user@k8s-bastion ~]$ sudo mv ./kubectl /usr/local/bin/kubectl
[r-user@k8s-bastion ~]$ mkdir .kube
[r-user@k8s-bastion ~]$ scp 172.18.1.111:/etc/kubernetes/admin.conf ~/.kube/
admin.conf                                                                                                                                     100% 5464     1.0MB/s   00:00    
[r-user@k8s-bastion ~]$ mv .kube/admin.conf .kube/config
[r-user@k8s-bastion ~]$ kubectl version --short
Client Version: v1.18.4
Server Version: v1.17.7
[r-user@k8s-bastion ~]$ kubectl get nodes 
NAME           STATUS   ROLES    AGE   VERSION
k8s-master     Ready    master   22h   v1.17.7
k8s-worker01   Ready    <none>   20h   v1.17.7
k8s-worker02   Ready    <none>   20h   v1.17.7

Calico overlayネットワークの検証をします。

kubectl run myshell -it --rm --image busybox -- sh

もうひとつターミナルを開いて、実行します。

[r-user@k8s-bastion ~]$ kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
myshell   1/1     Running   0          39s
[r-user@k8s-bastion ~]$ kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE    IP             NODE           NOMINATED NODE   READINESS GATES
myshell   1/1     Running   0          116s   10.233.117.2   k8s-worker02   <none>           <none>
[r-user@k8s-bastion ~]$ kubectl run myshell2 -it --rm --image busybox -- sh
If you don't see a command prompt, try pressing enter.
/ # hostname -i
10.233.125.3

最初のターミナルに戻って、実行します。

/ # hostname -i
10.233.117.2
/ # ping 10.233.125.3
PING 10.233.125.3 (10.233.125.3): 56 data bytes
64 bytes from 10.233.125.3: seq=32 ttl=62 time=1.688 ms
64 bytes from 10.233.125.3: seq=33 ttl=62 time=1.080 ms
64 bytes from 10.233.125.3: seq=34 ttl=62 time=1.195 ms
......

2つ目のターミナルを戻して、実行します。

/ # ping 10.233.117.2
PING 10.233.117.2 (10.233.117.2): 56 data bytes
64 bytes from 10.233.117.2: seq=0 ttl=62 time=5.143 ms
64 bytes from 10.233.117.2: seq=1 ttl=62 time=1.210 ms
64 bytes from 10.233.117.2: seq=2 ttl=62 time=1.181 ms
......

問題なくpingでコンテナ間の接続が確認されました。Exitでコンテナからログアウトすると、自動的にポッドが削除されます。

5. まとめ

ここまではKubeSprayツールを使って小規模なKubernetesクラスター環境を作成しましたが、本番環境で使用するためにはいくつか注意点があります。

- セキュリティ脆弱性や攻撃の可能性を最小限に抑える必要があります。Kubernetesは急速に成長しているオープンソースプロジェクトであるため、いつでもフォローアップできるように、更新やパッチの問題にも注意を払う必要があります。

- クラスターのパフォーマンスを微調整することで、スケーラビリティを最大化できます。どの環境でもアプリケーションを拡張および管理することが可能です。これが、Kubernetesが人気のある最も根本的な理由でしょう。 Kubernetesには自動修復機能があり、インフラストラクチャを自動的に追加または削除して、拡大する企業のビジネスニーズに対応できます。多くの企業は、パフォーマンスに影響を与えることなく、クラスターの柔軟なスケーラビリティを実現したいと考えています。

- 安全なCI / CDパイプラインをデプロイして、継続的なデリバリーを実現しましょう。企業のインフラストラクチャには、開発チームが生産性と作業効率を最大化できるように、自動展開と継続的デリバリー機能が必要です。

- 可視化機能は、デプロイプロセスの重要な部分です。可視化は、システムを監視できるだけでなく、デプロイプロセス中に発生する問題に対応し、正しい決定を迅速に行うために、稼働中のすべてのサービスを一元的に把握できる必要があります。実現するために、企業は適切なプロセスとツール、およびリアルタイムのイベントアラートシステムを使用して監視する必要があります。

- 災害復旧計画を作成し、システムに高可用性があることを確認しましょう。障害が発生すると、クラスターは自動的に回復します。クラスターが完全にクラッシュした場合、GitOpsのベストプラクティスを使用して解決できます。

これからのブログには上記のようなトピックも取り上げていきたいと考えています。

また、楽天クラウドは商用化マネージドKubernetesサービスも準備中ですので、ぜひご期待ください。

楽天クラウド:https://cloud.rakuten.co.jp/


画像5

柳 松
外資系ITメーカー入社、ストレージソリューションSEから始め、アーキテクト、プレセールス、ビジネスデベロップメントを経験。インフラ系から現職のクラウド系新規サービス開発にチャレンジ中。最近の趣味は読書。特に歴史と社会に興味を持っている。理科と違って、正解のない世界を面白く感じている。



スキ、ありがとうございます!
中のひとの日常や、お客様のデジタル・トランスフォーメーションのお役に立つかもしれない?情報を発信していきます。