Power Systems Virtual ServerへのOpenShift 4.7導入(7): IBM Cloudサービスの利用

# はじめに
この記事では、Power Systems Virtual Server(以下PowerVS)上に構築したOpenShift 4.7からIBM Cloudサービス(Block Storage、File Storage、LogDNA)を利用します。[事前](https://qiita.com/y-akio/items/4dda34a293a6fd6dc7e4)にIBM CloudのclassicノードとPowerVSのbastionノード間でIPIPトンネリングし、classicノードでIPマスカレードを構成しています。そのため、OpenShiftからIBM Cloudサービスのプライベートエンドポイントへの接続が可能です。また、OpenShiftからの通信の送信元IPアドレスは、classicノードのIPアドレス(10.192.36.132)に変換されるため、Block StorageとFile Storageでは、許可ホストに同IPアドレスを設定することで、これらのサービスの利用が可能になります。
![01_custom.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/7a4ab745-0196-117b-98eb-73f86b819ec8.png)

以下はPowerVSからのサービス連携に関連する記事です。

■ OpenShiftイメージレジストリのストレージとしてCloud Object Storageを設定

https://qiita.com/y-akio/items/f87f146ef44ebdee9ad3

■ OpenShiftのAlertManagerの通知先としてSlackを設定

https://qiita.com/y-akio/items/7d241745125ab7145bda#234-alertmanager%E8%A8%AD%E5%AE%9A

# 1. OpenShiftからBlock Storageを利用
## 1.1. Block Storage準備
IBM CloudでBlock Storageを**2つ**注文し、classicノードのIPアドレスからの接続を許可します。以後の設定では、IBM Cloudコンソールに表示される<ターゲット・アドレス>、<ボリュームID>、<ユーザー名>、<パスワード>、<ホストIQN>を使用します。<ホストIQN>とは別に\<IQN\>が必要である点に注意します。

![block.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/61f86e6f-494c-3fa6-528e-33b4c333d4bf.png)

2つのボリュームでは<ターゲット・アドレス>と<ボリュームID>が異なります。
![block06.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/57770665-9356-2d35-cb4f-e9be67bde22b.png)

2つのボリュームの<ユーザー名>、<パスワード>、<ホストIQN>は同じでした。
![block02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/63a10b50-d17d-54e0-546f-7d76ad6edadb.png)


## 1.2. IQN確認
永続ボリュームのマニフェストに必要な\<IQN\>とシークレットのマニフェストに必要な<ユーザー名をbase64エンコードした文字列>と<パスワードをbase64エンコードした文字列>を取得します。

※IBM Cloudコンソールでは、Block Storage毎に2つのターゲット・アドレスが表示されています。一方のボリュームのターゲット・アドレスにディスカバリ要求を送信すると(iscsiadm -m discovery〜)注文した2つのボリュームのターゲット・アドレス合計4つが応答されました。

```bash:bastionノード
yum -y install iscsi-initiator-utils
echo InitiatorName=<ホストIQN> > /etc/iscsi/initiatorname.iscsi
vi /etc/iscsi/iscsid.conf(5行修正)
node.session.auth.authmethod = CHAP
node.session.auth.username = <ユーザー名>
node.session.auth.password = <パスワード>
discovery.sendtargets.auth.username = <ユーザー名>
discovery.sendtargets.auth.password = <パスワード>
### vi終了

systemctl restart iscsid
iscsiadm -m discovery -t sendtargets -p <ターゲット・アドレス#1-1>
### 標準出力↓
<ターゲット・アドレス#1-1>:3260,1062 <IQN>
<ターゲット・アドレス#1-2>:3260,1058 <IQN>
<ターゲット・アドレス#2-1>:3260,1055 <IQN>
<ターゲット・アドレス#2-2>:3260,1060 <IQN>

echo -n <ユーザー名> | base64
### 標準出力↓
<ユーザー名をbase64エンコードした文字列>

echo -n <パスワード> | base64
### 標準出力↓
<パスワードをbase64エンコードした文字列>
```

## 1.3. Open Libertyデプロイ
事前にBlock Storageボリューム毎に1つの永続ボリューム(PV)を作成し、Open Libertyをレプリカ数『2』のステートフルセットとしてデプロイします。ステートフルセットのデプロイ時にworkerノードのiSCSIイニシエータがBlock Storageボリューム(iSCSIターゲット)を認証・ログインします。

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.7/html/storage/persistent-storage-using-iscsi

```bash:bastionノード
ssh core@worker-0 "echo InitiatorName=<ホストIQN> | sudo tee /etc/iscsi/initiatorname.iscsi"
ssh core@worker-1 "echo InitiatorName=<ホストIQN> | sudo tee /etc/iscsi/initiatorname.iscsi"
oc new-project block-storage
oc apply -f secret.yaml
oc apply -f persistent-volume0.yaml
oc apply -f persistent-volume1.yaml
oc apply -f statefulset.yaml

oc get pod
### 標準出力↓
NAME             READY   STATUS    RESTARTS   AGE
open-liberty-0   1/1     Running   0          56s
open-liberty-1   1/1     Running   0          38s

oc get pvc
### 標準出力↓
NAME                  STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
logs-open-liberty-0   Bound    iscsi-pv-0   1Gi        RWO                           66s
logs-open-liberty-1   Bound    iscsi-pv-1   1Gi        RWO                           48s

oc get pv
### 標準出力↓
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                               STORAGECLASS   REASON   AGE
iscsi-pv-0   1Gi        RWO            Retain           Bound    block-storage/logs-open-liberty-0                           81s
iscsi-pv-1   1Gi        RWO            Retain           Bound    block-storage/logs-open-liberty-1                           80s
```

```yaml:secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: chap-secret
type: "kubernetes.io/iscsi-chap"
data:
  discovery.sendtargets.auth.username: <ユーザー名をbase64エンコードした文字列>
  discovery.sendtargets.auth.password: <パスワードをbase64エンコードした文字列>
  node.session.auth.username: <ユーザー名をbase64エンコードした文字列>
  node.session.auth.password: <パスワードをbase64エンコードした文字列>
```

```yaml:persistent-volume0.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv-0
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: <ターゲット・アドレス#1-1>:3260
    portals: ['<ターゲット・アドレス#1-2:3260>']
    iqn: <IQN>
    lun: 0
    fsType: ext4
    chapAuthDiscovery: true
    chapAuthSession: true
    secretRef:
      name: chap-secret
```

```yaml:persistent-volume1.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv-1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: <ターゲット・アドレス#2-1>:3260
    portals: ['<ターゲット・アドレス#2-2:3260>']
    iqn: <IQN>
    lun: 1
    fsType: ext4
    chapAuthDiscovery: true
    chapAuthSession: true
    secretRef:
      name: chap-secret
```

```yaml:statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: open-liberty
  labels:
    app: open-liberty
spec:
  serviceName: open-liberty
  replicas: 2
  selector:
    matchLabels:
      app: open-liberty
  template:
    metadata:
      labels:
        app: open-liberty
    spec:
      containers:
        - name: open-liberty
          image: docker.io/open-liberty:21.0.0.4-full-java11-openj9
          ports:
            - containerPort: 9080
          volumeMounts:
            - name: logs
              mountPath: /logs
  volumeClaimTemplates:
  - metadata:
      name: logs
    spec:
      accessModes:
      - ReadWriteOnce
      volumeMode: Filesystem
      resources:
        requests:
          storage: 1Gi
```

bastionノードからBlock Storageをマウントすると、Open Libertyのmessages.logが出力されていることを確認できます。

```bash:bastionノード
# ディスカバーしないとログイン不可
iscsiadm -m discovery -t sendtargets -p <ターゲット・アドレス#1-1>
iscsiadm -m node -T <IQN> -p "<ターゲット・アドレス#1-1>:3260" --login
### 標準出力↓
Logging in to [iface: default, target: <IQN>, portal: <ターゲット・アドレス#1-1>,3260]
Login to [iface: default, target: <IQN>, portal: <ターゲット・アドレス#1-1>,3260] successful.

ls -l /dev/mapper/
### 標準出力↓
合計 0
lrwxrwxrwx. 1 root root       7  5月 28 22:32 3600a09803830566b682b5162702d6f47 -> ../dm-3

mount /dev/mapper/3600a09803830566b682b5162702d6f47 /mnt
ls -l /mnt
### 標準出力↓
合計 44
drwxrws---. 2 root       1000620000 16384  5月 28 19:20 lost+found
-rw-r-----. 1 1000620000 1000620000 11804  5月 28 22:33 messages.log

head /mnt/messages.log
### 標準出力↓
********************************************************************************
product = Open Liberty 21.0.0.4 (wlp-1.0.51.cl210420210407-0944)
wlp.install.dir = /opt/ol/wlp/
server.output.dir = /opt/ol/wlp/output/defaultServer/
java.home = /opt/java/openjdk
java.version = 11.0.10
java.runtime = OpenJDK Runtime Environment (11.0.10+9)
os = Linux (4.18.0-240.22.1.el8_3.ppc64le; ppc64le) (en_US)
process = 1@10.131.0.83
********************************************************************************

umount /mnt
iscsiadm -m node -T <IQN> -p "<ターゲット・アドレス#1-1>:3260" --logout

# 自動接続を回避
iscsiadm -m node -T <IQN> -o delete
```


# 2. OpenShiftからFile Storageを利用
## 2.1. File Storage準備
IBM CloudでFile Storageを**1つ**注文し、classicノードのIPアドレスからの接続を許可します。以後の設定では、IBM Cloudコンソールに表示される<ホスト名>と<マウント・ポイント>を使用します。マウント・ポイントは<ホスト名>:<パス>になっています。
![file.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/f02af238-9759-c4ff-f0e9-37b1c16feb9d.png)
![file3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/061b8922-002e-bf00-525d-0ac58aecc593.png)

![file2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/6aa79db0-9557-d779-19a6-dbf658e149e4.png)

## 2.2. NFS動的プロビジョナーデプロイ
Red Hatのマニュアルではなく、Redbook「Red Hat OpenShift V4.3 on IBM Power Systems Reference Guide」で紹介されているNFS動的プロビジョナー(nfs-client-provisioner)をデプロイします。この場合、1つのFile Storegeに対して複数の永続ボリューム(PV)を作成することができます。

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.7/html/storage/persistent-storage-using-nfs

http://www.redbooks.ibm.com/abstracts/redp5599.html

```bash:bastionノード
oc new-project external-storage
oc apply -f rbac.yaml
oc adm policy add-scc-to-user hostmount-anyuid system:serviceaccount:external-storage:nfs-client-provisioner
oc apply -f deployment.yaml
oc apply -f class.yaml

oc get pod
### 標準出力↓
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-7474565989-5wpnj   1/1     Running   0          6m8s

oc get sc
### 標準出力↓
NAME                  PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   fuseim.pri/ifs   Delete          Immediate           false                  45s
```

```yaml:rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: external-storage
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: external-storage
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: external-storage
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: external-storage
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: external-storage
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
```

```yaml:deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: external-storage
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: docker.io/ibmcom/nfs-client-provisioner-ppc64le:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: <ホスト名>
            - name: NFS_PATH
              value: <パス>
      volumes:
        - name: nfs-client-root
          nfs:
            server: <ホスト名>
            path: <パス>
```

```yaml:class.yaml
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: fuseim.pri/ifs # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"
```

## 2.3. Open Libertyデプロイ
Open Libertyをレプリカ数『2』のステートフルセットとしてデプロイします。ステートフルセットは永続ボリューム要求(PVC)を作成し、動的NFSプロビジョナーはPod毎に1つの永続ボリューム(PV)を作成します。

```bash:bastionノード
oc new-project file-storage
oc apply -f statefulset.yaml

oc get pod
### 標準出力↓
open-liberty-0   1/1     Running   0          112s
open-liberty-1   1/1     Running   0          106s

oc get pvc
### 標準出力↓
NAME                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS.       AGE
logs-open-liberty-0   Bound    pvc-38d33f66-dc97-4b45-b568-e79655a7f616   1Gi        RWO           managed-nfs-storage  2m2s
logs-open-liberty-1   Bound    pvc-01190ede-0394-4143-b098-41c8b0a19df6   1Gi        RWO           managed-nfs-storage  2m6s

oc get pv
### 標準出力↓
pvc-01190ede-0394-4143-b098-41c8b0a19df6   1Gi        RWO            Delete           Bound    file-storage/logs-open-liberty-1    managed-nfs-storage            2m5s
pvc-38d33f66-dc97-4b45-b568-e79655a7f616   1Gi        RWO            Delete           Bound    file-storage/logs-open-liberty-0    managed-nfs-storage            2m11s
```

bastionノードからFile StorageをNFSマウントすると、PV毎にディレクトリが作成されていること、同ディレクトリ以下にOpen Libertyのmessages.logが出力されていることを確認できます。

```bash:bastionノード
mount <マウント・ポイント> /mnt
ls -l /mnt
### 標準出力↓
合計 8
drwxrwxrwx. 2 nobody nobody 4096  5月 28 23:05 file-storage-logs-open-liberty-0-pvc-38d33f66-dc97-4b45-b568-e79655a7f616
drwxrwxrwx. 2 nobody nobody 4096  5月 28 23:05 file-storage-logs-open-liberty-1-pvc-01190ede-0394-4143-b098-41c8b0a19df6

find /mnt -type f -exec ls -l {} \;
### 標準出力↓
-rw-r-----. 1 1000640000 nobody 11332  5月 28 23:06 /mnt/file-storage-logs-open-liberty-0-pvc-38d33f66-dc97-4b45-b568-e79655a7f616/messages.log
-rw-r-----. 1 1000640000 nobody 11333  5月 28 23:06 /mnt/file-storage-logs-open-liberty-1-pvc-01190ede-0394-4143-b098-41c8b0a19df6/messages.log

head /mnt/file-storage-logs-open-liberty-0-pvc-38d33f66-dc97-4b45-b568-e79655a7f616/messages.log
### 標準出力↓
********************************************************************************
product = Open Liberty 21.0.0.4 (wlp-1.0.51.cl210420210407-0944)
wlp.install.dir = /opt/ol/wlp/
server.output.dir = /opt/ol/wlp/output/defaultServer/
java.home = /opt/java/openjdk
java.version = 11.0.10
java.runtime = OpenJDK Runtime Environment (11.0.10+9)
os = Linux (4.18.0-240.22.1.el8_3.ppc64le; ppc64le) (en_US)
process = 1@10.131.0.83
********************************************************************************

umount /mnt
```

```yaml:statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: open-liberty
  labels:
    app: open-liberty
spec:
  serviceName: open-liberty
  replicas: 2
  selector:
    matchLabels:
      app: open-liberty
  template:
    metadata:
      labels:
        app: open-liberty
    spec:
      containers:
        - name: open-liberty
          image: docker.io/open-liberty:21.0.0.4-full-java11-openj9
          ports:
            - containerPort: 9080
          volumeMounts:
            - name: logs
              mountPath: /logs
  volumeClaimTemplates:
    - metadata:
        name: logs
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: managed-nfs-storage
        resources:
          requests:
            storage: 1Gi
```

# 3. OpenShiftからLog Analysis with LogDNAを利用
ppc64le用のlogdna-agentバイナリは配布されていないので、GitHubで公開されている「logdna-agent」を使用します。Node.jsで開発されておりビルドすることなく動作しました。「logdna-agent-v2」はRustで開発されていて高速とのことですがビルドできませんでした。

https://github.com/logdna/logdna-agent

https://github.com/logdna/logdna-agent-v2

## 3.1. Log Analysis with LogDNA準備
IBM CloudでLog Analysis with LogDNAインスタンスを作成します。
![logdna.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/2af8a56e-8339-43cf-b35b-5ce4be4f12ec.png)
インスタンス作成後、プラットフォーム・ログを構成します。
![logdna2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/b8c2ce21-4da1-a443-c7d8-594de916237e.png)

ダッシュボードを開き、メニュー > ORGANIZATION > API KeysからIngestion keysを確認します。Ingestion keysはシークレットとして作成し、logdna-agentコンテナで利用します。

![logdna6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/8a14e939-4303-8ec7-636a-98e00a260815.png)
![logdna5.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413476/a22754b7-4564-b0e3-01db-90ed4dc49eeb.png)

## 3.2. OpenShiftへのlogdna-agentデプロイ
logdna-agentはDaemonSetとしてデプロイし、各ノードの「/var/log/containers」以下に出力されたログをLogDNAサービスに送信します。つまり、すべてのノードのコンテナログを対象にしています。

```bash:bastionノード
oc new-project logdna-agent

# Pod起動用Service Acccount作成・権限付与
oc create serviceaccount logdna-agent
oc adm policy add-scc-to-user privileged system:serviceaccount:logdna-agent:logdna-agent

# LogDNA接続用シークレット作成
oc create secret generic logdna-agent-key --from-literal=logdna-agent-key=<Ingestion keys>

# コンテナイメージ作成
oc new-build --name=logdna-agent --strategy=docker --binary
oc start-build logdna-agent --from-dir=. --follow
oc get is
### 標準出力↓
NAME           IMAGE REPOSITORY                                                            TAGS     UPDATED
logdna-agent   image-registry.openshift-image-registry.svc:5000/logdna-agent/logdna-agent   latest   13 seconds ago

# logdna-agentデプロイ
oc apply -f logdna-agent.yaml
oc get pod -o wide
### 標準出力↓
NAME                   READY   STATUS      RESTARTS   AGE     IP             NODE       NOMINATED NODE   READINESS GATES
logdna-agent-1-build   0/1     Completed   0          6m21s   10.131.1.89    worker-0   <none>           <none>
logdna-agent-44tpb     1/1     Running     0          2m      10.129.2.23    infra-2    <none>           <none>
logdna-agent-5s2qn     1/1     Running     0          2m      10.130.2.102   infra-1    <none>           <none>
logdna-agent-9sbmj     1/1     Running     0          2m      10.128.2.84    worker-1   <none>           <none>
logdna-agent-c7s8t     1/1     Running     0          2m      10.131.1.93    worker-0   <none>           <none>
logdna-agent-wptz5     1/1     Running     0          2m      10.131.2.24    infra-0    <none>           <none>
```

```dockerfile:Dockerfile
FROM registry.access.redhat.com/ubi8/ubi:latest

RUN dnf install -y nodejs git \
 && git clone https://github.com/logdna/logdna-agent.git

WORKDIR logdna-agent
COPY exec.sh /logdna-agent

RUN npm install \
 && chmod +x /logdna-agent/exec.sh

CMD ["/logdna-agent/exec.sh"]
```

```bash:exec.sh
#!/bin/bash

node index.js -u all
node index.js -k ${LOGDNA_AGENT_KEY}
node index.js -s LOGDNA_APIHOST=${LOGDNA_APIHOST}
node index.js -s LOGDNA_LOGHOST=${LOGDNA_LOGHOST}

LOGDNA_HOSTNAME=`cat /etc/logdna-hostname`
node index.js -n ${LOGDNA_HOSTNAME}

# 今回の例では/var/logをログ収集対象にしない
# /var/log/containersのリンク先=/var/log/podsを対象にするとログが送信されない
cp -p /etc/logdna.conf /etc/logdna.conf.tmp
sed -e 's/var\/log/var\/log\/containers/g' /etc/logdna.conf.tmp > /etc/logdna.conf

node index.js -s
```

```yaml:logdna-agent.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: logdna-agent
  labels:
    app: logdna-agent
spec:
  selector:
    matchLabels:
      app: logdna-agent
  template:
    metadata:
      labels:
        app: logdna-agent
    spec:
      containers:
      - name: logdna-agent
        image: image-registry.openshift-image-registry.svc:5000/logdna-agent/logdna-agent:latest
        imagePullPolicy: Always
        env:
        - name: LOGDNA_AGENT_KEY
          valueFrom:
            secretKeyRef:
              name: logdna-agent-key
              key: logdna-agent-key
        - name: LOGDNA_APIHOST
          value: api.jp-tok.logging.cloud.ibm.com
        - name: LOGDNA_LOGHOST
          value: logs.jp-tok.logging.cloud.ibm.com
        resources:
          requests:
            cpu: 20m
          limits:
            memory: 500Mi
        securityContext:
          privileged: true
        volumeMounts:
        - name: varlogcontainers
          mountPath: /var/log/containers
          readOnly: true
        - name: varlogpods
          mountPath: /var/log/pods
          readOnly: true
        - name: logdnahostname
          mountPath: /etc/logdna-hostname
      serviceAccount: logdna-agent
      serviceAccountName: logdna-agent
      volumes:
      - name: varlogcontainers
        hostPath:
          path: /var/log/containers
      - name: varlogpods
        hostPath:
          path: /var/log/pods
      - name: logdnahostname
        hostPath:
          path: /etc/hostname
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
```

以下はOpen Libertyデプロイ時にLogDNAダッシュボードに表示されたログです。時刻、Pod名「open-liberty-0」、Project名「open-liberty」が付加されています。

```bash:LogDNAダッシュボード
May 28 21:04:36 open-liberty-0 open-liberty Launching defaultServer (Open Liberty 21.0.0.4/wlp-1.0.51.cl210420210407-0944) on Eclipse OpenJ9 VM, version 11.0.10+9 (en_US)
May 28 21:04:36 open-liberty-0 open-liberty [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
May 28 21:04:40 open-liberty-0 open-liberty [AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
May 28 21:04:40 open-liberty-0 open-liberty [AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml
May 28 21:04:41 open-liberty-0 open-liberty WARNING [WARNING ] CWWKS3103W: There are no users defined for the BasicRegistry configuration of ID com.ibm.ws.security.registry.basic.config[basic].
May 28 21:04:42 open-liberty-0 open-liberty [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
May 28 21:04:46 open-liberty-0 open-liberty [AUDIT   ] CWWKS4104A: LTPA keys created in 3.423 seconds. LTPA key file: /opt/ol/wlp/output/defaultServer/resources/security/ltpa.keys
May 28 21:04:48 open-liberty-0 open-liberty [AUDIT   ] CWWKF0012I: The server installed the following features: [appClientSupport-1.0, appSecurity-2.0, appSecurity-3.0, batch-1.0, beanValidation-2.0, cdi-2.0, concurrent-1.0, distributedMap-1.0, ejb-3.2, ejbHome-3.2, ejbLite-3.2, ejbPersistentTimer-3.2, ejbRemote-3.2, el-3.0, j2eeManagement-1.1, jacc-1.5, jaspic-1.1, javaMail-1.6, javaee-8.0, jaxb-2.2, jaxrs-2.1, jaxrsClient-2.1, jaxws-2.2, jca-1.7, jcaInboundSecurity-1.0, jdbc-4.2, jms-2.0, jndi-1.0, jpa-2.2, jpaContainer-2.2, jsf-2.3, jsonb-1.0, jsonp-1.1, jsp-2.3, managedBeans-1.0, mdb-3.2, servlet-4.0, ssl-1.0, wasJmsClient-2.0, wasJmsSecurity-1.0, wasJmsServer-1.0, webProfile-8.0, websocket-1.1].
May 28 21:04:48 open-liberty-0 open-liberty [AUDIT   ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 12.000 seconds.
May 28 21:04:50 open-liberty-0 open-liberty [AUDIT   ] CWPKI0803A: SSL certificate created in 7.357 seconds. SSL key file: /opt/ol/wlp/output/defaultServer/resources/security/key.p12
May 28 21:04:51 open-liberty-0 open-liberty [AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.