|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
WebOTX Operator for Kubernetes の運用管理に関して説明します。
以降、WebOTX Operator for Kubernetes を Operator と表記します。
以降の手順は、Operator をインストールした際に展開されるファイルを使用します。インストールの詳細は、以下のインストールガイド（Linux）を参照してください。
Operator を Kubernetes 上に展開するまでの流れは次の図のようなイメージとなります。
コンテナイメージ生成の手順は次の通りとなります。
cd <Operatorインストールディレクトリ>
docker build -t <Dockerレジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:10.4 docker
公開イメージの利用
WebOTXでは、Linux環境の Operator のコンテナイメージをDocker Hub <https://hub.docker.com/u/webotx> で公開しています。 Docker Hubに公開されたWebOTX Operatorのコンテナイメージを利用する手順を説明します。
| コンテナイメージ <コンテナイメージ名:タグ> |
製品名 | ベースイメージ |
|---|---|---|
| webotx/webotx-operator-ubi7-minimal:10.40.00.00 | WebOTX Operator for Kubernetes V10.4 (Linux 版) | registry.access.redhat.com/ubi7/ubi-minimal |
<コンテナイメージの取得>
コンテナエンジンに Docker を使用する場合のコンテナイメージの取得について説明します。
$ login: root
# docker pull <コンテナイメージ名:タグ>
# docker images REPOSITORY TAG IMAGE ID CREATED <コンテナイメージ名> <タグ> ************ ** **** ago
(*) *** 部分の表記は環境または取得日によって異なります。
取得したコンテナイメージが表示されれば、取得完了です。
次のコマンドを実行して、Operator イメージを Docker レジストリに登録します。
docker push <Dockerレジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:10.4
Operator の展開は、マニフェストファイル (YAML) を編集して、Kubernetes クラスタへ登録することで行います。 マニフェストファイルは、Operator をインストールしたディレクトリの manifest 配下に格納されています。
Operator の展開の手順は次の通りとなります。
必要に応じて Operator を動作させたい Namespace を作成してください。
kubectl create namespace <Namespace名>
カスタムリソース定義とは、WebOTX Application Container のカスタムリソースをどのように記述するかを 定義したものです。 カスタムリソースを登録するために、予めカスタムリソース定義を登録しておく必要があります。
kubectl apply -f manifest/webotx_crd.yaml
Operator が動作するために必要なサービスアカウントの作成、権限の付与を行います。
kubectl apply -f manifest/service_account.yaml -n <Namespace名>
WebOTX AS コンテナの起動に必要なスクリプトや Logstash でのログ収集に必要な定義ファイルを管理する ConfigMap を登録します。
kubectl apply -f manifest/configmap.yaml -n <Namespace名>
operator.yaml にある下記の設定項目を変更してください。
| 設定項目 | 置換文字 |
|---|---|
| Operator イメージ名 | REPLACE_WEBOTX_OPERATOR_IMAGE |
| Operator ライセンスキー | REPLACE_LICENSE_KEY |
apiVersion: apps/v1
kind: Deployment
metadata:
name: webotx-operator
spec:
：
replicas: 1
template:
spec:
container:
name: webotx-operator
image: REPLACE_WEBOTX_OPERATOR_IMAGE # この設定値を Operator のコンテナイメージ名に変更してください。
：
env:
- name: LICENSE_KEY
value: REPLACE_LICENSE_KEY # この設定値を Operator のライセンスキーに変更してください。
：
Docker プライベートレジストリを利用する場合
Operator のコンテナイメージを Docker プライベートレジストリに登録している場合、認証情報を登録した Secret を作成して、
operator.yaml で imagePullSecrets の設定を追加する必要があります。
kubectl create secret docker-registry <Secret名> \
--docker-server=<レジストリサーバーのホスト名またはIPアドレス>:<ポート番号> \
--docker-username=<ユーザー名> \
--docker-password=<パスワード> \
--docker-email=<Emailアドレス> \
-n <Namespace名>
imagePullSecrets に設定
operator.yaml の次の太字の 2 行のコメントを解除して、REPLACE_REGISTRY_AUTH_SECRET_NAME を上記で作成した Secret の名前に変更します。
spec:
# Set when pulling an image from the private registry.
#imagePullSecrets:
# - name: REPLACE_REGISTRY_AUTH_SECRET_NAME
serviceAccountName: webotx-operator
volumes:
- name: share-volume
emptyDir: {}
設定例 :
ここでは、docker-registry-auth という名前の Secret を作成しています。
spec:
# Set when pulling an image from the private registry.
imagePullSecrets:
- name: docker-registry-auth
serviceAccountName: webotx-operator
volumes:
- name: share-volume
emptyDir: {}
次のコマンドを実行して Operator を展開します。
kubectl apply -f manifest/operator.yaml -n <Namespace名>
次のコマンドを実行して Operator の Pod の STATUS が「Running」、READY が「1/1」となることを確認します。
kubectl get pod -n <Namespace名>
出力例 :
NAME READY STATUS RESTARTS AGE webotx-operator-9fb75f759-fjf5s 1/1 Running 0 40s
公開マニフェスト(YAML)の利用
WebOTXでは、Linux環境の Operator のマニフェスト(YAML)をGitHubで公開しています。 GitHubに公開されたWebOTX Operatorのマニフェスト(YAML)を利用する手順を説明します。
<マニフェスト(YAML)の構成>
manifest
|-template
|-operator.yaml
|-webotx_cr_advance.yaml
|-webotx_cr_simple.yaml
|-configmap.yaml
|-operator.yaml
|-service_account.yaml
|-webotx_cr.yaml
|-webotx_crd.yaml
<マニフェスト(YAML)の取得>
マニフェスト(YAML)の取得について説明します。
Zip でダウンロードする場合
<https://github.com/webotx/operator>
Git でローカルにコピーする場合
Caution Git がインストールされていない場合、Git をインストールする必要があります。
$ login: root
# git clone https://github.com/webotx/operator.git
Operator の設定は operator.yaml 内の ConfigMap にて設定します。 ConfigMap に設定できる値については、 [リファレンス] > [設定] > [WebOTX Operator for Kubernetes] > [Operator 設定項目] を参照してください。
設定の反映方法について、説明します。
次の設定例では、太字の箇所を変更しています。
設定例 :
apiVersion: v1 kind: ConfigMap metadata: name: webotx-operator-config data: LOG_LEVEL: "ERROR" LOG_ROTATION: "5" LOG_FILESIZE: "10" PPROF_ENABLED: "FALSE" PPROF_INTERVAL: "10" PPROF_ROTATION: "144" METERING_ENABLED: "TRUE" METERING_INTERVAL: "1" METERING_TIMEOUT_SCRAPE: "10" METERING_TIMEOUT_READ: "60" METERING_TIMEOUT_WRITE: "30" --- apiVersion: apps/v1 kind: Deployment metadata: name: webotx-operator spec: ：
kubectl apply -f manifest/operator.yaml -n <Namespace名>
変更した設定を Operator に反映するには、Operator を再起動する必要があります。
次のコマンドを実行して Operator を再起動します。
kubectl set env deployment/webotx-operator RELOAD_DATE="$(date)" -n <Namespace名>
Operator 設定の確認手順
設定の変更を反映するには Pod の再起動が必要です。
このため、ConfigMap の設定と展開済の Operator の設定は一致するとは限りません。
展開済の Operator の設定を確認したい場合は、次のコマンドで、ログに出力されている設定の内容を確認します。
kubectl get pod -n <Namespace名>
Namespace 名が不明瞭なときの Pod 名の確認方法 :
kubectl get pod --all-namespaces
次に、取得した Pod 名を指定して次のように kubectl logs を実行します。 設定情報は Operator 起動時に出力されるので、パイプ（|）で head コマンドで出力を渡すと見やすくなります。
kubectl logs <Pod名> -n <Namespace名> | head -n <表示行数>
出力例 :
2020-03-27 01:03:04 UTC INFO launcherOTX33050002: WebOTX Operator Settings.
LOG:
LOG_LEVEL: INFO
LOG_ROTATION: "5"
LOG_FILESIZE: "1"
PPROF:
PPROF_ENABLED: "FALSE"
PPROF_INTERVAL: "10"
PPROF_ROTATION: "144"
METERING:
METERING_ENABLED: "TRUE"
METERING_INTERVAL: "1"
TIMEOUT:
METERING_TIMEOUT_SCRAPE: "10"
METERING_TIMEOUT_READ: "60"
METERING_TIMEOUT_WRITE: "30"
Operator を Kubernetes 上から削除するためには、次のコマンドを実行します。
kubectl delete -f manifest/operator.yaml -n <Namespace 名>
kubectl delete -f manifest/configmap.yaml -n <Namespace 名>
kubectl delete -f manifest/service_account.yaml -n <Namespace 名>
kubectl delete -f manifest/webotx_crd.yaml
Caution カスタムリソースの定義(CRD)は、Namespace 毎ではなく、Kubernetes Cluster 全体で 1 つ登録します。 このため、カスタムリソース定義(CRD)を削除すると、 全ての Namespace で展開されている WebOTX Application Server が削除されますので、注意してください。
メータリング機能とは、Operator を利用して展開した WebOTX Server にて公開されているメトリックスを収集して、REST-API として公開する機能です。
メータリング機能を利用するには、以下の設定を行う必要があります。
operator.yaml 内の、以下の設定を修正し、Operator の展開を行います。
METERING_ENABLED ・・・ メータリング機能の有効/無効の設定（TRUE: 有効, FALSE: 無効）
METERING_INTERVAL ・・・ WebOTX Server からメトリックスを収集する間隔（分）
設定例 :
METERING_ENABLED: "TRUE" METERING_INTERVAL: "1"
カスタムリソース単位に、メトリックスを収集を収集するかどうかを設定します。
カスタムリソースのマニフェストファイル（webotx_cr.yaml）に、以下の設定を行い、WebOTX Server の展開を行います。WebOTX Server を展開する手順は「WebOTX Application Server の展開」を参照してください。
enabled ・・・ WebOTX Server からメトリックスを収集の有無の設定（true: する, false: しない）
scheme ・・・ WebOTX Server でメトリックスを公開しているエンドポイントの URI スキーム
port ・・・ WebOTX Server でメトリックスを公開しているエンドポイントのポート番号
※scheme、port については、Operator で展開する WebOTX Server コンテナの設定に合わせてください。
設定例 :
：
spec:
# WebOTX related settings
webotx:
# Metering related settings
metering:
# Enable / disable metric collection.
enabled: true
# Set the URL scheme for retrieving metrics.
scheme: https
# Set the port number when retrieving metrics.
port: 8443
：
REST-API のエンドポイントは以下の通りです。
| エンドポイント | パラメータ | 説明 |
|---|---|---|
| https://<pod-ip>:8989/metrics | なし | 全てのカスタムリソースで展開された WebOTX Server から収集したメトリックスを出力します。 |
| https://<pod-ip>:8989/metrics/<パラメータ> | カスタムリソース名 | パラメータにカスタムリソース名を指定することで、特定のカスタムリソースで展開された WebOTX Server から収集したメトリックスのみ出力します。 |
REST-API では、JSON フォーマットと Prometheus フォーマットをサポートしています。
JSON フォーマット
Accept ヘッダに、「application/json」を指定した場合、JSON フォーマットで応答します。
{
""<カスタムリソース名>": [
{
"name": "<メトリックス名>",
"help": "<メトリックスの説明>",
"type": "<メトリックスタイプ>",
"metrics": [
{
"labels": {
"applicationserver": "<ラベル：カスタムリソース名>",
"pod": "<ラベル：Pod名>"
},
"value": "<メトリックス値>"
},
{
"labels": {
"applicationserver": "<ラベル：カスタムリソース名>",
"pod": "<ラベル：Pod名>"
},
"value": "<メトリックス値>"
},
：
]
},
：
"<カスタムリソース名>": [
{
：
}
Prometheus フォーマット
Accept ヘッダに、「application/json」以外を指定した場合、Prometheus フォーマットで応答します。
# TYPE <メトリックス名> <メトリックスタイプ>
# HELP <メトリックス名> <メトリックスの説明>
<メトリックス名>{applicationserver="<ラベル：カスタムリソース名>", pod="<ラベル：Pod名>"} <メトリックス値>
Operator の監視を Prometheus で行うことができます。
Prometheus と連携を有効にするには、operator.yaml のアノテーションの設定を行います。
| 設定項目 | 説明 | 既定値 |
|---|---|---|
| prometheus.io/scrape | Prometheus で監視を行うかどうかを設定します。 設定値は true または false で設定し、true を設定した場合は有効となります。 |
true |
| prometheus.io/scheme | 監視する URI スキームを指定します。 | http |
| prometheus.io/path | 監視するパスを指定します。 | /metrics |
| prometheus.io/port | 監視するポート番号を設定します。 | 8383 |
例えば、メータリング機能で出力するメトリックスを Prometheus で監視したい場合は、以下のように設定します。
設定例 :
apiVersion: apps/v1
kind: Deployment
：
template:
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/scheme: "https"
prometheus.io/path: "/metrics"
prometheus.io/port: "8989"
spec:
：
<補足>
Prometheus の Service Discovery の機能を使用することで、Kubernetes クラスタ上で 動作している Operator の Prometheus 情報を自動的に収集することができます。
次に Service Discovery 機能を利用して動的に監視する場合の Prometheus の設定例を示します。
Prometheus の設定例 :
global:
：
scrape_configs:
：
- job_name: 'kubernetes-pods'
tls_config:
insecure_skip_verify: true
kubernetes_sd_configs:
- role: pod
api_server: "https://kubernetes.default.svc.cluster.local:443"
tls_config:
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: ${1}:${2}
target_label: __address__
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
Prometheus で収集したメトリックスを確認する場合は、Prometheus の管理コンソールから、クエリを実行することで確認できます。
Operator では、WebOTX Application Server を Kubernetes 上に展開するために、 Docker レジストリからそのイメージを取得します。 このため、予め WebOTX Application Server のイメージを作成し、Docker レジストリに 登録しておく必要があります。
次の図に、Operator が WebOTX Application Server を展開するまでの流れを示します。
上図のように WebOTX Application Server のカスタムリソースのマニフェストファイル（webotx_cr.yaml）を編集して、 kubectl コマンドにて Kubernetes Cluster 上に適用します。 Operator ではカスタムリソースの作成、または変更を検知して設定を読み込みます。 読み込んだ後、指定された WebOTX Application Server イメージを Docker レジストリより取得して、 WebOTX Application Server の Pod と公開用の Service を作成します。
カスタムリソースのマニフェストファイル（webotx_cr.yaml）を修正し、カスタムリソースを登録します。webotx_cr.yaml は Operator をインストールしたディレクトリに展開されます。
マニフェストファイル内に記載している次の置換文字を実際の値に修正してください。
| 設定項目 | 置換文字 |
|---|---|
| カスタムリソース名 | REPLACE_APPLICATIONSERVER_NAME |
| WebOTX Application Server の Docker イメージ名 | REPLACE_WEBOTX_AS_IMAGE |
Operator は、WebOTX Server に配備したアプリケーションを公開するための Service を作成します。
webotx_cr.yaml では、NodePort タイプの Service を作成して、WebOTX Server コンテナの 8080、8443 ポートを Kubernetes ワーカーノードの 30080、30443 へポートフォワードするように設定されています。WebOTX Server に配備したアプリケーションの設定やサービスの公開方法などに合わせて、設定を編集してください。（設定項目については、
[リファレンス]
> [設定]
> [WebOTX Operator for Kubernetes]
> [カスタムリソース設定項目]
を参照してください。）
：
# Service manifest definition settings
service:
# Configure NodePort service.
type: NodePort
ports:
- name: http
protocol: TCP
targetPort: 8080
port: 8080
nodePort: 30080
- name: https
protocol: TCP
targetPort: 8443
port: 8443
nodePort: 30443
sessionAffinity: ClientIP
sessionAffinityConfig:
clientIP:
timeoutSeconds: 10800
externalTrafficPolicy: Cluster
次のコマンドを実行し、WebOTX Server 用のカスタムリソースを適用します。
kubectl apply -f manifest/webotx_cr.yaml -n <Namespace名>
次のコマンドを実行し、WebOTX Server の Pod の STATUS が「Running」、READY が「2/2」となることを確認します。
kubectl get pod -n <Namespace名>
出力例 :
NAME READY STATUS RESTARTS AGE webotx-for-container-57964fffbc-bsldj 2/2 Running 0 3m21s
Operator の動作
WebOTX Application Server 用のカスタムリソースを kubectl コマンドで適用すると、
Operator が検知し、WebOTX Application Server の Pod を生成します。
このとき Pod 内には「図 WebOTX Application Server イメージの展開」のように、ログ収集のためのサイドカーとして Logstash コンテナが含まれます。
WebOTX Application Server の Pod を生成するまでの流れを次に示します。
WebOTX Application Server を更新する場合は、変更を行った WebOTX Application Server の Docker イメージを作成した後、 カスタムリソースのマニフェストファイルを編集して再度、適用します。
WebOTX Application Server の設定変更の流れを次に示します。
作成した Docker イメージは予め Docker レジストリ登録しておく必要があります。 次のコマンドで登録先の Docker レジストリに Docker のイメージ名を書き換えてから、 登録を行います。
docker tag <イメージ名> <Dockerレジストリのホスト名>:<ポート>/webotx/webotx-for-container:10.4
次のコマンドで Docker レジストリに Docker イメージを登録します。
docker push <Dockerレジストリのホスト名>:<ポート>/webotx/webotx-for-container:10.4
kubectl apply -f webotx_cr.yaml -n <Namespace名>
展開に使用したカスタムリソースを削除することで WebOTX Server が削除されます。
カスタムリソースを削除するには、次のコマンドを実行します。
kubectl ApplicationServer <カスタムリソース名> -n <Namespace名>
展開された WebOTX Application Server の Pod には、サイドカーとして Logstash コンテナが起動しており、この Logstash から WebOTX Application Server および、アプリケーションログを任意の Elasticsearch へ送信することができます。
Elasticsearch に送信しておくことで、Pod が削除された後もログを確認することができ、障害解析などに役立てることができます。
ログの収集する場合、以下の設定を行います。
webotx_cr.yaml の spec.webotx 配下に、以下の設定を追加します。
spec:
# WebOTX related settings
webotx:
：
application:
logs:
- <収集対象とするログファイルの絶対パス>
- <収集対象とするログファイルの絶対パス>
：
webotx_cr.yaml の spec.deployment: 配下に、以下の設定を追加します。
spec:
：
deployment:
：
logstash:
elasticsearch:
host: <Elasticsearch のホスト名 or IPアドレス>
port: <Elasticsearch のポート番号>
：
Memo
上記の設定を行わない（Elasticsearchへ送信しない）場合は、Logstash コンテナの標準出力に出力されます。
以下のように設定することで、WebOTX Application Server コンテナに環境変数を設定することが出来ます。
以下の形式で環境変数を定義したファイルを作成します。
環境変数名=値 環境変数名=値 環境変数名=値 ：
次のコマンドを実行して ConfigMap または、Secret を作成します。
# ConfigMap の場合 kubectl create configmap <ConfigMap名> --from-env-file=<環境変数を定義したファイルパス> -n <Namespace名> # Secret の場合 kubectl create secret generic <Secret名> --from-env-file=<環境変数を定義したファイルパス> -n <Namespace名>
webotx_cr.yaml に作成した ConfigMap(Secret) の設定を追加します。
spec:
# WebOTX related settings
webotx:
：
envFrom:
# ConfigMap の場合
configMaps:
- <ConfigMap名>
- <ConfigMap名>
：
# Secret の場合
secrets:
- <Secret名>
- <Secret名>
：
Kubernetes 上で動作する WebOTX Application Server コンテナでは、ホスト名や IP アドレスが
変動的であるため、ホスト名や IP アドレスを指定したセッションレプリケーションをすることが
できません。
この場合に利用できるのが、Infinispan のデータグリッド連携機能（※）による
セッションレプリケーションです。
Caution Infinispan のデータグリッド連携機能は WebOTX Application Server の Standard でのみ サポートしています。
次の図に WebOTX Application Server をセッションレプリケーションした際のイメージを示します。
Infinispan は、WebOTX Application Server が動作している各 Pod に配置され、 Kubernetes の Pod Network 上にある Infinispan が自動的に連携します。
Operator では、この Infinispan を利用したセッションレプリケーションが容易にできるよう 設計されており、カスタムリソース内で次のように sessionReplication の enabled、useJmxAgent、 useAllProcessGroups の設定を行うだけで、複数の Pod 間で自動的にセッションレプリケーションが 行われます。
カスタムリソースの設定例 :
spec:
# WebOTX related settings
webotx:
:
# Session replication related settings
sessionReplication:
# Enable / disable session replication.
# optional
enabled: true
# Sets whether the data grid is loaded by the agent process.
# optional
useJmxAgent: true
# Set whether the data grid is loaded in all process groups.
# optional
useAllProcessGroups: true
# Deployment manifest definition settings
deployment:
# Setting pod multiplicity.
replicas: 1
# WebOTX AS container image name setting.
image: <WebOTX AS コンテナイメージ名>
# The name of the ServiceAccount used to run this pod.
# Default to default.
# optional
serviceAccountName: <サービスアカウント名（※）>
# Indicates whether the service account token should be automatically
# mounted.
# optional
automountServiceAccountToken: true
:
※Infinispan を利用してセッションレプリケーションを行うには、Kubernetes API へのアクセス権限を付与されたサービスアカウントで WebOTX AS コンテナを起動する必要があります。
任意のサービスアカウントへ Kubernetes API へのアクセス権限を付与する手順は次の通りです。
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
name: webotx-infinispan-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: webotx-infinispan-binding
subjects:
- kind: ServiceAccount
name: <サービスアカウント名>
roleRef:
kind: Role
name: webotx-infinispan-role
apiGroup: rbac.authorization.k8s.io
kubectl apply -f <作成したマニフェストファイルパス> -n <Namespace 名>
kubectl delete -f <作成したマニフェストファイルパス> -n <Namespace 名>
Amazon EKS クラスタの作成と管理に必要なバイナリのインストールと設定の手順は次の通りです。
<Windows の場合>
以下の場所より、インストーラファイルをダウンロードします。
<https://awscli.amazonaws.com/AWSCLIV2.msi>
ダウンロードした MSI インストーラを実行し、画面の指示に従います。
<Linux の場合>
以下のコマンドを実行します。
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install
環境変数 PATH に、インストールした AWS CLI を追加します。
Memo
通常、以下の場所へインストールされます。
Windows の場合：C:\Program Files\Amazon\AWSCLIV2
Linux の場合：/usr/local/bin
Amazon EKS へ接続する為の 認証情報の設定を行います。
aws configure AWS Access Key ID [None]: <IAM ユーザーのアクセスキー> AWS Secret Access Key [None]: <IAM ユーザーのシークレットアクセスキー> Default region name [None]: <リージョンコード> Default output format [None]: <出力形式>
| 設定項目 | 説明 |
|---|---|
| AWS Access Key ID | IAM ユーザーまたはロールに関連付けられる AWS アクセスキーを指定します。 詳細については、AWS ユーザーガイドの「AWS CLI の設定」をご参照ください。 |
| AWS Secret Access Key | アクセスキーに関連付けられるシークレットキーを指定します。 詳細については、AWS ユーザーガイドの「AWS CLI の設定」をご参照ください。 |
| Default region name | リクエストを送信する AWS リージョンを指定します。 詳細については、AWS リファレンスガイドの「AWS サービスエンドポイント」をご参照ください。 |
| Default output format | AWS CLI コマンド実行結果の出力形式を指定します。 json 、text 、 table の何れかを指定します。 詳細については、AWS ユーザーガイドの「AWS CLI からのコマンド出力の制御」をご参照ください。 |
<Windows の場合>
下記のサイトを参考に、Chocolatey をインストールしてください。
chocolatey install -y eksctl aws-iam-authenticator
<Linux の場合>
curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
Memo
AWS CLI および、eksctl インストールの詳細については、AWS のユーザーガイドを参照してください。
AWS Command Line Interface ユーザーガイド
Amazon EKS ユーザーガイド
下記の２種類のクラスタを作成する手順について説明します。
・Amazon EKS on EC2
・Amazon EKS on Fargate
eksctl create cluster \ --name <クラスタ名> \ --region <AWS リージョン> \ --version <Kubernetes バージョン番号> \ --nodegroup-name <ノードグループ名> \ --node-type <ワーカーノードのEC2インスタンスタイプ> \ --nodes <ワーカーノードのノード数> \ --nodes-min <ワーカーノードのスケーリング最小サイズ> \ --nodes-max <ワーカーノードのスケーリング最大サイズ> \ --node-ami <ワーカーノード起動 AMI>
コマンド例 :
eksctl create cluster \ --name eks-ec2-cluster \ --region ap-northeast-1 \ --version 1.18 \ --nodegroup-name standard-workers \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --node-ami auto
| オプション名 | 説明 |
|---|---|
| --name | Amazon EKS クラスタの名前を指定します。 |
| --region | Amazon EKS クラスタを作成するリージョンを指定します。 詳細については、AWS リファレンスガイドの「AWS サービスエンドポイント」をご参照ください。 |
| --version | Kubernetes バージョン番号を指定します。 |
| --nodegroup-name | ノードグループの名前を指定します。 |
| --node-type | ワーカーノードのEC2インスタンスタイプを指定します。 詳細については、「Amazon EC2 インスタンスタイプ」をご参照ください。 |
| --nodes | ワーカーノードのノード数を指定します。 |
| --nodes-min | ワーカーノードのスケーリングの最小サイズを指定します。 |
| --nodes-max | ワーカーノードのスケーリングの最大サイズを指定します。 |
| --node-ami | ワーカーノードの起動に用いる Amazon マシンイメージ (AMI) を指定します。 「auto」が指定されている場合、Kubernetes バージョン/リージョン/インスタンスタイプに基づいて AMI を自動的に設定されます。 |
上記以外にも指定可能なオプションがあります。
詳細については、下記のコマンドでヘルプを参照し、構築する環境に合わせて指定してください。
eksctl create cluster --help
作成したKubernetes クラスタの操作に必要な kubectl をインストールします。
<Windows の場合>
curl -o kubectl.exe https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/windows/amd64/kubectl.exe curl -o kubectl.exe.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/windows/amd64/kubectl.exe.sha256Kubernetes 1.17:
curl -o kubectl.exe https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.12/2020-11-02/bin/windows/amd64/kubectl.exe curl -o kubectl.exe.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.12/2020-11-02/bin/windows/amd64/kubectl.exe.sha256Kubernetes 1.16:
curl -o kubectl.exe https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.15/2020-11-02/bin/windows/amd64/kubectl.exe curl -o kubectl.exe.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.15/2020-11-02/bin/windows/amd64/kubectl.exe.sha256
Get-FileHash kubectl.exe
上記コマンドで出力された SHA-256 チェックサムとダウンロードした SHA-256 ファイルに記載された内容が一致することを確認してください。
Caution PowerShell のコマンド実行結果は大文字で出力されます。
<Linux の場合>
curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/kubectl curl -o kubectl.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/kubectl.sha256Kubernetes 1.17:
curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.12/2020-11-02/bin/linux/amd64/kubectl curl -o kubectl.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.12/2020-11-02/bin/linux/amd64/kubectl.sha256Kubernetes 1.16:
curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.15/2020-11-02/bin/linux/amd64/kubectl curl -o kubectl.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.16.15/2020-11-02/bin/linux/amd64/kubectl.sha256
openssl sha1 -sha256 kubectl
上記コマンドで出力された SHA-256 チェックサムとダウンロードした SHA-256 ファイルに記載された内容が一致することを確認してください。
chmod +x ./kubectl
eksctl create cluster \ --name <クラスタ名> \ --region <AWS リージョン> \ --version <Kubernetes バージョン番号> \ --fargate --alb-ingress-access
コマンド例 :
eksctl create cluster \ --name eks-fargate-cluster \ --region ap-northeast-1 \ --version 1.18 \ --fargate --alb-ingress-access
| オプション名 | 説明 |
|---|---|
| --name | Amazon EKS クラスタの名前を指定します。 |
| --region | Amazon EKS クラスタを作成するリージョンを指定します。 詳細については、AWS リファレンスガイドの「AWS サービスエンドポイント」をご参照ください。 |
| --version | Kubernetes バージョン番号を指定します。 |
| --fargate | kube-system および default の Namespace へ Pod を展開するのに必要な Fargate プロファイルを作成します。 |
| --alb-ingress-access | alb-ingress-controllerのフルアクセスを有効にします。 |
上記以外にも指定可能なオプションがあります。
詳細については、下記のコマンドでヘルプを参照し、構築する環境に合わせて指定してください。
eksctl create cluster --help
作成したKubernetes クラスタの操作に必要な kubectl をインストールします。手順については、「Amazon EKS on EC2 クラスタの場合」- (2)を参照を参照してください。
eksctl utils associate-iam-oidc-provider --region <AWS リージョン> --cluster <クラスタ名> --approve
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/iam-policy.json aws iam create-policy --policy-name <IAMポリシー名> --policy-document file://iam-policy.json
出力例:
POLICY arn:aws:iam::<アカウントID>:policy/<IAMポリシー名> 0 ****-**-*****:**:*** v1 True / 0 ********************* <IAMポリシー名:> ****-**-*****:**:***
※作成した IAM ポリシーの arn（赤字箇所）は、以降の手順で使用しますので、出力内容を控えてください。
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/rbac-role.yaml
eksctl create iamserviceaccount \ --region <AWS リージョン> \ --name alb-ingress-controller \ --namespace kube-system \ --cluster <クラスタ名> \ --attach-policy-arn <IAM ポリシーの arn> \ --override-existing-serviceaccounts \ --approve
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/alb-ingress-controller.yaml
下記の赤字部分をコメントを解除して、値を編集します。
# Application Load Balancer (ALB) Ingress Controller Deployment Manifest.
# This manifest details sensible defaults for deploying an ALB Ingress Controller.
# GitHub: https://github.com/kubernetes-sigs/aws-alb-ingress-controller
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: alb-ingress-controller
name: alb-ingress-controller
# Namespace the ALB Ingress Controller should run in. Does not impact which
# namespaces it's able to resolve ingress resource for. For limiting ingress
# namespace scope, see --watch-namespace.
namespace: kube-system
spec:
selector:
matchLabels:
app.kubernetes.io/name: alb-ingress-controller
template:
metadata:
labels:
app.kubernetes.io/name: alb-ingress-controller
spec:
containers:
- name: alb-ingress-controller
args:
# Limit the namespace where this ALB Ingress Controller deployment will
# resolve ingress resources. If left commented, all namespaces are used.
# - --watch-namespace=your-k8s-namespace
# Setting the ingress-class flag below ensures that only ingress resources with the
# annotation kubernetes.io/ingress.class: "alb" are respected by the controller. You may
# choose any class you'd like for this controller to respect.
- --ingress-class=alb
# REQUIRED
# Name of your cluster. Used when naming resources created
# by the ALB Ingress Controller, providing distinction between
# clusters.
- --cluster-name=<クラスター名>
# AWS VPC ID this ingress controller will use to create AWS resources.
# If unspecified, it will be discovered from ec2metadata.
- --aws-vpc-id=<EKS の VPC ID>
# AWS region this ingress controller will operate in.
# If unspecified, it will be discovered from ec2metadata.
# List of regions: http://docs.aws.amazon.com/general/latest/gr/rande.html#vpc_region
- --aws-region=<リージョン名>
# Enables logging on all outbound requests sent to the AWS API.
# If logging is desired, set to true.
# - --aws-api-debug
# Maximum number of times to retry the aws calls.
# defaults to 10.
# - --aws-max-retries=10
# env:
# AWS key id for authenticating with the AWS API.
# This is only here for examples. It's recommended you instead use
# a project like kube2iam for granting access.
#- name: AWS_ACCESS_KEY_ID
# value: KEYVALUE
# AWS key secret for authenticating with the AWS API.
# This is only here for examples. It's recommended you instead use
# a project like kube2iam for granting access.
#- name: AWS_SECRET_ACCESS_KEY
# value: SECRETVALUE
# Repository location of the ALB Ingress Controller.
image: docker.io/amazon/aws-alb-ingress-controller:v1.1.4
serviceAccountName: alb-ingress-controller
次のコマンドを実行して ALB Ingress Controller を展開します。
kubectl apply -f alb-ingress-controller.yaml
次のコマンドを実行して ALB Ingress Controller の Pod の STATUS が「Running」、READY が「1/1」となることを確認します。
kubectl get pod -n kube-system
default の Namespace 以外に Pod を展開する場合、Fargate プロファイルを作成する必要があります。
eksctl create fargateprofile --cluster <クラスター名> --name <プロファイル名> --namespace <Namespace名>
Amazon ECR 上に、Operator の Docker イメージを登録する手順は次の通りです。
aws ecr get-login --no-include-email --region <AWS リージョン>
上記コマンドを実行すると、Amazon ECR へログインするためのコマンドが出力されます。
取得した認証コマンドを実行します。
docker login -u AWS -p <省略>== https://<レジストリID>.dkr.ecr.<AWS リージョン>.amazonaws.com
「Login Succeeded」と表示されれば、ログインの成功です。
aws ecr create-repository --region <AWS リージョン> --repository-name webotx/webotx-operator
出力例 :
> aws ecr create-repository --region ap-northeast-1 --repository-name webotx/webotx-operator
{
"repository": {
"repositoryArn": "arn:aws:ecr:ap-northeast-1:123456789012:repository/webotx/webotx-operator",
"registryId": "123456789012",
"repositoryName": "webotx/webotx-operator",
"repositoryUri": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/webotx/webotx-operator",
"createdAt": 1581908263.0,
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": false
}
}
}
registryId は、次の手順にて使用する為、出力内容を控えてください。
Operator の Docker イメージを、Amazon ECR のリポジトリへ登録するために、イメージ名のタグを修正します。
docker tag <Operator イメージ名> <registryId>/dkr.ecr.<AWS リージョン>.amazonaws.com/webotx/webotx-operator:10.4
<registryId> は、Amazon ECR リポジトリを作成した際のコマンド結果に出力された値を設定。
docker push <registryId>/dkr.ecr.<AWS リージョン>.amazonaws.com/webotx/webotx-operator:10.4
Amazon EKS 上に作成した、Kubernetes クラスタに WebOTX Operator を展開する手順は「Operator の展開」を参照してください。
| 設定項目 | 置換文字 |
|---|---|
| カスタムリソース名 | REPLACE_APPLICATIONSERVER_NAME |
| WebOTX Application Server の Docker イメージ名 | REPLACE_WEBOTX_AS_IMAGE |
<LoadBalancer タイプのサービスを利用して、外部へ公開する場合>
LoadBalancer タイプのサービスを作成します。
設定例 :
：
# Service manifest definition settings
service:
# Configure NodePort service.
type: LoadBalancer
ports:
- name: http
protocol: TCP
targetPort: 8080
port: 8080
nodePort: 30080
- name: https
protocol: TCP
targetPort: 8443
port: 8443
nodePort: 30443
sessionAffinity: None
sessionAffinityConfig:
clientIP:
timeoutSeconds: 10800
externalTrafficPolicy: Cluster
<ALB Ingress Controller を利用して、外部へ公開する場合>
ClusterIP タイプのサービスを作成します。
設定例 :
：
# Service manifest definition settings
service:
# Configure NodePort service.
type: ClusterIP
ports:
- name: http
protocol: TCP
targetPort: 8080
port: 8080
- name: https
protocol: TCP
targetPort: 8443
port: 8443
sessionAffinity: None
sessionAffinityConfig:
clientIP:
timeoutSeconds: 10800
次のコマンドを実行し、WebOTX Server 用のカスタムリソースを適用します。
kubectl apply -f manifest/webotx_cr.yaml -n <Namespace名>
ALB Ingress Controller を利用して外部へ公開する場合、Ingress を作成する必要があります。
マニフェスト例 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: <Ingress名>
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
labels:
app: webotx-micro-ingress
spec:
rules:
- http:
paths:
- path: /*
backend:
serviceName: <カスタムリソース名>
servicePort: <公開するポート番号>
kubectl apply -f <マニフェストファイルパス> -n <Namespace名>
次のコマンドを実行し、WebOTX Server の Pod の STATUS が「Running」、READY が「2/2」となることを確認します。
kubectl get pod -n <Namespace名>
出力例 :
NAME READY STATUS RESTARTS AGE webotx-for-container-57964fffbc-bsldj 2/2 Running 0 3m21s
Amazon EKS on Fargate クラスタへ Pod を展開する場合、CPU やメモリなどの必要なリソースが足りず、OOMKilled エラーで起動に失敗する場合があります。 その場合、以下のようにカスタムリソース（webotx_cr.yaml）へ、リソースの設定を追加して展開することで回避できます。
設定例 :
spec:
# WebOTX related settings
webotx:
：
resources:
webotx:
requests:
cpu: <WebOTX AS コンテナの起動に必要な CPU リソースの値>
memory: <WebOTX AS コンテナの起動に必要なメモリリソースの値>
limits:
cpu: <WebOTX AS コンテナの最大 CPU リソースの値>
memory: <WebOTX AS コンテナの最大メモリリソースの値>
logstash:
requests:
cpu: <Logstash コンテナの起動に必要な CPU リソースの値>
memory: <Logstash コンテナの起動に必要なメモリリソースの値>
limits:
cpu: <Logstash コンテナの最大 CPU リソースの値>
memory: <Logstash コンテナの最大メモリリソースの値>
Amazon EKS 上に作成した、Kubernetes クラスタを削除する手順は次の通りです。
eksctl delete cluster --name <クラスタ名> --wait
--wait オプションを指定することで、クラスタの削除が完了してからコマンドが終了します。
Amazon ECR 上に登録した、Operator の Docker イメージを削除する手順は次の通りです。
aws ecr list-images --repository-name webotx/webotx-operator
出力例 :
> aws ecr list-images --repository-name webotx/webotx-operator
{
"imageIds": [
{
"imageDigest": "sha256:27fb54237f6dbcd45e976e56b4cf6ef14be57bd16292c3b43a8d91b39faed646",
"imageTag": "10.4"
}
]
}
削除するイメージの imageDigest を控えてください。
aws ecr batch-delete-image --repository-name webotx/webotx-operator --image-ids imageDigest=<imageDigest の出力値>
出力例 :
> aws ecr batch-delete-image --repository-name webotx/webotx-operator --image-ids imageDigest=sha256:27fb54237f6dbcd45e976e56b4cf6ef14be57bd16292c3b43a8d91b39faed646
{
"imageIds": [
{
"imageDigest": "sha256:27fb54237f6dbcd45e976e56b4cf6ef14be57bd16292c3b43a8d91b39faed646",
"imageTag": "10.4"
}
],
"failures": []
}
作成したリポジトリも削除する場合は、次のコマンドを実行します。
aws ecr delete-repository --repository-name webotx/webotx-operator
Caution リポジトリを削除すると、リポジトリ内のイメージもすべて削除されますので、注意が必要です。
OpenShift では、クラスタ内部にコンテナレジストリを持っています。この内部レジストリに、ソースコード（Dockerfile）からビルドされたコンテナイメージを登録して、 OpenShift 上へ配備することができます。
ここでは、WebOTX Operator のコンテナイメージの生成とレジストリへの登録方法を説明します。
oc login -u <ユーザー名> -p <パスワード>
oc project <プロジェクト名>
新規にプロジェクトを作成する場合は、次のコマンドを実行します。
oc new-project <プロジェクト名>
次のコマンドで、バイナリソースによる Docker ビルドストラテジーの BuildConfig を作成します。
oc new-build --strategy=docker --binary --name=<任意の BuildConfig 名>
プロキシ環境下では、必要に応じて --build-arg オプションで環境変数 http_proxy, https_proxy, no_proxy を指定してください。
次のコマンドで、WebOTX Operator のインストールで展開した資材を使用して、ビルドを開始します。
oc start-build <任意の BuildConfig 名> --from-dir=<Operator インストールディレクトリ>/docker
実行結果はOpenShiftの管理コンソールか oc get is コマンドで確認できます。 また、oc start-build コマンドに --follow オプションを追加すると、コンテナイメージ生成の実行状況が表示されます。
生成されたコンテナイメージのタグは latest として生成されます。次のコマンドでコンテナイメージのタグを変更できます。
oc tag <任意の BuildConfig 名>:latest <任意の BuildConfig 名>:<タグ>
次のコマンドで、生成されたコンテナイメージを確認します。
oc get is
出力例 :
> oc get is NAME IMAGE REPOSITORY TAGS UPDATED webotx-operator image-registry.openshift-image-registry.svc:5000/example/webotx-operator 10.4,latest 42 seconds ago
上記は、example という名前のプロジェクト上で生成した場合の例です。
この場合、operator.yaml に設定する Operator イメージ名は、「image-registry.openshift-image-registry.svc:5000/example/webotx-operator:10.4」となります。
OpenShift へ WebOTX Operator を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
oc apply -f manifest/webotx_crd.yaml
oc apply -f manifest/service_account.yaml
oc apply -f manifest/configmap.yaml
マニフェストファイル（operator.yaml）に Operator コンテナイメージ名とライセンスキーを設定します。
詳細は、「Operator の展開」を参照してください。
oc apply -f manifest/operator.yaml
OpenShift へ WebOTX Application Server を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
以下のコマンドで、対象のサービスアカウントに SCC を付与します。 この設定は各プロジェクトで 1 回実行すれば十分です。
SCC の設定は不要です。（デフォルトの restricted で動作します）
oc patch scc nonroot --type=merge -p 'priority: 5' oc adm policy add-scc-to-user nonroot -z <サービスアカウント名>
oc adm policy add-scc-to-user anyuid -z <サービスアカウント名>
| 設定項目 | 置換文字 |
|---|---|
| カスタムリソース名 | REPLACE_APPLICATIONSERVER_NAME |
| WebOTX Application Server の Docker イメージ名 | REPLACE_WEBOTX_AS_IMAGE |
OpenShift では、サービスの公開を Route を作成して行うため、ワーカーノードにポートフォワードする必要がないため、NodePort ではなく ClusterIP で作成します。
設定例 :
：
# Service manifest definition settings
service:
# Configure NodePort service.
type: ClusterIP
ports:
- name: http
protocol: TCP
targetPort: 8080
port: 8080
- name: https
protocol: TCP
targetPort: 8443
port: 8443
oc apply -f manifest/webotx_cr.yaml
OpeShift へ展開した WebOTX Application Server のコンテナ（Pod）に外部からアクセスする場合、次のコマンドを実行します。
oc expose svc/<カスタムリソース名> --name <Route名> --port <公開するポート番号>
複数のポートを公開する場合は、公開するポート番号毎に異なる Route 名を指定します。
OpenShift から WebOTX Application Server を削除する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
次のコマンドで、サービスを公開する為に作成した Route を確認します。
oc get route
出力例 :
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD webotx-as-http webotx-as-http-example.apps.otx4k.smileninja.net webotx-as-container 8080 None webotx-as-https webotx-as-https-example.apps.otx4k.smileninja.net webotx-as-container 8443 None
oc expose svc/<カスタムリソース名> --name <Route名> --port <公開するポート番号>
複数のポートを公開する場合は、公開するポート番号毎に異なる Route 名を指定します。
oc delete -f manifest/webotx_cr.yaml
OpenShift から WebOTX Operator を削除する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
oc delete -f manifest/operator.yaml oc delete -f manifest/service_account.yaml
OpenShift 上に展開した全ての WebOTX Operator および、WebOTX Application Server を削除する場合のみ実施します。
oc delete -f manifest/webotx_crd.yaml
Caution カスタムリソースの定義は、プロジェクト毎ではなく、OpenShift 全体で 1 つ登録します。 このため、カスタムリソース定義を削除すると、 カスタムリソース定義に紐づいている WebOTX Application Server が全てのプロジェクトから 削除されるので、注意が必要です。