C# & JavaScript

今回は「Podを配置するNodeの選択/制限方法」のうち「Taints & Tolerations」についてまとめます。 「NodeSelector」「Node Affinity」「Pod Affinity / Anti-Affinity」について以前まとめていますので過去記事を参照してください。

Selector または Affinity 、 Taints & Tolerations など似たようなものがいくつかあり、分かりづらいのでまとめてみました。

概要

「Podを意図したNodeに配置したい」とは逆で、「Nodeに配置したくないPodの条件」を指定します。 Node に対して決められた Pod 以外は配置できないようにするための仕組みです。

あらかじめ Node に対しては Taint （汚れ）を指定しておきます。 Pod を Node に配置する際、Toleration（許容(= 許せる汚れ)） がなければ Taints(汚れ) のある Node へ Toloration（許容(= 許せる汚れ)）のない Pod は配置できません。 逆に Taint（汚れ） のある Node でも Toloration（許容(= 許せる汚れ)）がある Pod であれば 配置できます。

Node Taints

Taintsの確認

Node Label の確認と同じで kubectl describe node NAME で確認できます。

[root@k8s-master ~]# kubectl describe node k8s-node02
Name:               k8s-node02
Roles:              worker
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=k8s-node02
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/worker=
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"aa:ff:b4:fa:6c:05"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 10.51.1.102
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Sun, 02 Jun 2019 17:48:59 +0900
Taints:             key1=value1:NoSchedule
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:48:59 +0900   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:48:59 +0900   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:48:59 +0900   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Sat, 15 Jun 2019 16:03:38 +0900   Sun, 02 Jun 2019 17:49:29 +0900   KubeletReady                 kubelet is posting ready status

… (以下省略) …

Taintsの付与/削除

Node に対して Taint を付与/削除するには kubectl taint nodes NAME KEY=VALUE:EFFECT を利用します。

[root@k8s-master ~]# kubectl taint nodes k8s-node02 key1=value1:NoSchedule
node/k8s-node02 tainted

EFFECTに指定できるのは以下のいずれかになります。 指定によってNode中で動作しているPodに対する影響が変わります。

• NoSchedule 今後は配置しないで。実行中のPodは無視するよ。
• PreferNoSchedule 今後できれば配置しないで。実行中のPodは無視するよ。
• NoExecute 実行中のPodは出ていけ！

付与されている Taint を削除する場合 kubectl taint nodes NAME KEY:EFFECT- で削除できます。

[root@k8s-master ~]# kubectl taint nodes k8s-node02 key1:NoSchedule-
node/k8s-node02 untainted

組み込み Taints

自動付与される組み込み Taint は以下の通りです。

• node.kubernetes.io/not-ready
• node.kubernetes.io/unreachable
• node.kubernetes.io/out-of-disk
• node.kubernetes.io/memory-pressure
• node.kubernetes.io/disk-pressure
• node.kubernetes.io/network-unavailable
• node.kubernetes.io/unschedulable
• node.cloudprovider.kubernetes.io/uninitialized

Pod Tolerations

Pod に対して Tolerations を指定すると Taints が指定された Node に対して配置が可能になります。

apiVersion: v1
kind: Pod
metadata:
  name: sample
spec:
  containers:
  - name: sample
    image: k8s.gcr.io/pause:2.0
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"
    tolerationSeconds: 3600

tolorations に指定できるのは key 、 operator 、 value 、 effect 、 tolerationSeconds です。

key 、 value 、 effect が operator で指定された条件で一致している Node であれば配置されますが、それ以外は配置されません。 operator に指定できる演算子は以下の通りです。

• Exists (デフォルト)
• Equal

tolerationSeconds は effect が NoExecute のときに立ち退くまでの時間(秒)を指定します。

今回は「Taints & Tolerations」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• kubernetes - Assigning Pods to Nodes
• kubernetes - Taints and Tolerations

今回は「Podを配置するNodeの選択/制限方法」のうち「NodeSelector」「Node Affinity」「Pod Affinity / Anti-Affinity」についてまとめます。 「Taints & Tolerations」は次回まとめます。

Selector または Affinity 、 Taints & Tolerations など似たようなものがいくつかあり、分かりづらいのでまとめてみました。

概要

NodeにはあらかじめLabelが指定されています。 Podに対して「NodeのどのLabelと一致させるか」を指定し、Labelが一致するNodeに対してPodを配置していくものです。

Podを意図したNodeに配置したい場合、以下のような定義を利用して指定します。

• nodeSelector
• nodeAffinity
• podAffinity または podAntiAffinity

上記の定義はいずれも Node Label との一致状況を確認するので、まずは Node Label から確認していきましょう。

Node Label

Podの配置にはNodeのラベルが使われます。 なので、何はともあれNodeのラベルとしてどんなものが定義されているのか、どう定義するのかなどを確認しておきます。

Labelの確認

現在 Node に付与されている ラベル を確認するには kubectl describe node NAME で確認できます。

[root@k8s-master ~]# kubectl describe node k8s-node01
Name:               k8s-node01
Roles:              worker
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=k8s-node01
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/worker=
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"9e:14:d6:92:02:02"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 10.51.1.101
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Sun, 02 Jun 2019 17:49:09 +0900
Taints:             
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:09 +0900   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:09 +0900   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:09 +0900   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Mon, 10 Jun 2019 23:39:18 +0900   Sun, 02 Jun 2019 17:49:19 +0900   KubeletReady                 kubelet is posting ready status

… (以下省略) …

Labelの付与/削除

新たなラベルを Node に付与したい場合は kubectl label nodes NAME KEY=VALUE で付与します。

以下のコマンドでは「k8s-node01」に対して「disktype = ssd」を指定しています。

[root@k8s-master ~]# kubectl label nodes k8s-node01 disktype=ssd
node/k8s-node01 labeled

付与したラベルを削除したい場合は kubectl label nodes NAME KEY- を指定します。

以下のコマンドでは「k8s-node01」に定義された「disktype」を削除しています。

[root@k8s-master ~]# kubectl label nodes k8s-node01 disktype-
node/k8s-node01 labeled

デフォルトLabel

Node作成時にデフォルトで付与されるラベルは以下の通りです。

• kubernetes.io/hostname
• failure-domain.beta.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/region
• beta.kubernetes.io/instance-type
• kubernetes.io/os
• kubernetes.io/arch

kubernetes.io/hostname は基本的に Node 名 と一致します。

Node Selector

nodeSelector はその名の通り「Podを配置したいNodeラベル」をキーバリュー形式で指定します。

例えば disktype: ssd というラベルのある Node へ配置したい場合、以下のような指定をします。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

この nodeSelector はいずれなくなるようです。 理由は、この後に説明する nodeAffinity で代替できるからとのことです。

Node Affinity

nodeAffinity は nodeSelector よりも柔軟な Node 指定ができます。 Anti Affinity や、この後に紹介する Taints & Tolerations と維持する動作も表現可能です。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value

Node選択する際、「配置する時（DuringScheduling）の必須度合（required または preferred）」と「既に配置されて実行されているPod（DuringExecution）の対応（Ignore または Required）」の組み合わせで4パターンの動作が考えられます。 どのような動作をさせたいかで選択します。

• requiredDuringSchedulingIgnoredDuringExecution

  Pod配置時は必須条件とするが、すでに配置されているPodに対しては無視する。

• preferredDuringSchedulingIgnoredDuringExecution

  Pod配置時にできるだけ配慮して配置する。すでに配置されているPodに対しては無視する。

• requiredDuringSchedulingRequiredDuringExecution

  Pod配置時に必須条件とし、すでに配置されているPodがある場合は退去させる。 Kubernetes v1.14 時点では利用不可。 今後実装予定の機能。

• preferredDuringSchedulingRequiredDuringExecution

  組み合わせ上は存在するが機能としては存在しない。

matchExpressions は key 、 operator 、 values で構成されます。 key には条件にしたいNodeのラベル名、values には値を指定します。 operator に使える演算子は以下の通りです。

• In
• NotIn
• Exists
• DoesNotExist
• Gt
• Lt

preferredDuringScheduling には上記の条件に加えて weight が 1 ～ 100 の範囲で指定できます。 この weight は Node 選択時の演算で利用します。 各 Node においてラベルマッチした個数分 weight を加算し、最終的に点数の高い Node に Pod を配置します。

Pod Affinity / Anti-Affinity

podAffinity および podAffinity はすでに動いているPodをもとにどこへPodを配置するかを定義するものになります。

podAffinity は「指定されたラベルに一致する Pod が動作している Node がもつ topologyKey が同一の Node に Pod を配置させる」動作になります。 podAffinity は「topologyKey の範囲内に 指定されたラベルに一致するPodが動作していなければ、Pod を topologyKey 範囲内のNodeのいずれかに Pod を配置する」動作になります。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  containers:
  - name: with-pod-affinity
    image: k8s.gcr.io/pause:2.0
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: failure-domain.beta.kubernetes.io/zone

podAffinityやpodAntiAffinityはその性質（Nodeに配置されたPodのラベルマッチを行う）ので処理が重くなります。 そのため、数百Nodeもあるようなサービスでは使わないほうが良いようです。

labelSelector は key 、 operator 、 values で構成されます。 key には条件にしたいPodのラベル名、values には値を指定します。 operator に使える演算子は以下の通りです。

• In
• NotIn
• Exists
• DoseNotExist

topologyKey は基本的に Node に設定されたラベルになります。 なので、意図的にすべての Node に対して付与しているラベルがないのであれば標準的に付与される以下のようなラベルを利用します。

• kubernetes.io/hostname
• failure-domain.beta.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/region
• beta.kubernetes.io/instance-type
• kubernetes.io/os
• kubernetes.io/arch

今回は「NodeSelector」「Node Affinity」「Pod Affinity / Anti-Affinity」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• kubernetes - Assigning Pods to Nodes
• kubernetes - Taints and Tolerations

今回は「CentOS上にシングルマスター構成のKubernetesクラスターを構築する方法」についてまとめます。

いくつかブログやホームページを確認しながらやってみたのですが、うまくいかないものですね… 今回の記事では「目指せ冪等！」としてバージョン指定で構築方法をまとめました。

概要

マスターノード1台、ワーカーノード2台の3台構成で構築してみます。 同一筐体の上に仮想マシン3台を作成して、その3台でクラスタ環境を構築していきます。

利用するモジュール類は以下のようなものです。

• docker （コンテナエンジン）
• flannel （ネットワーク）
• kubeadm （Kubernetes 構築ツール）

Dockerはきちんとバージョン指定するのに、手作業の環境構築でバージョン指定しない違和感が激しかったので、今回はきちんとバージョン指定で環境構築していきます。 利用しているパッケージやイメージのバージョンは以下の通りです。

OS
CentOS Linux release 7.3.1611 (Core)

パッケージ	アーキテクチャー	バージョン
systemd	x86_64	219-62.el7_6.6
docker-ce	x86_64	18.09.6
docker-ce-cli	x86_64	18.09.6
containerd.io	x86_64	1.2.5
kubeadm	x86_64	1.14.2
kubectl	x86_64	1.14.2
kubelet	x86_64	1.14.2

イメージ	バージョン
flannel	0.11.0

OSが少し古いものを使いまわしていたので systemd の更新をしないと cgroup-driver を systemd に変更して動作させることができませんでした。 上の表はあらかじめアップデート済みの状態で記述しています。 もし、バージョンが異なるようであれば事前にアップデートが必要になります。

仮想マシン準備

必要となる仮想マシン3台分（マスター1台、ワーカー2台）を準備します。 基本的に root ユーザーで実施していきます（ sudo が手間なので…）。

仮想マシン作成

仮想マシンを作成する際、以下のような内容で作成しました。 基本的にはデフォルトのままで、CPUだけ修正しています。 Kubernetes は CPU コア 2コア 以上 で作成しないと動作しないので、作成時に間違えないよう注意してください。

CPU	2コア
メモリ	2048MB
ハードディスク	16GB
SCSI コントローラ	VMware Paravirtual
ネットワーク アダプタ	VM Network
CD/DVD ドライブ	データストア ISO ファイル (CentOS 7 のインストーラー イメージ)

systemdの更新

この手順は OS のバージョンによっては不要です。 バージョン確認して新しければいったんスキップしてもよいでしょう。 もし、「kubelet が systemd で起動できない」といった症状が出た場合はこの手順に戻って更新が必要になります。

バージョン確認

yum list | grep systemd

systemdの入れ直し

yum remove systemd
yum install systemd-219-62.el7_6.6.x86_64

マスターノード、ワーカーノード共通の構築

ホスト名、IPアドレス

あとで出てくるコマンド kubeadm init においてIPは決められている前提になるので、最初に固定しておきます。

1. ホスト名の設定

   hostnamectl set-hostname <hostname>
   

2. ネットワークの設定

   vi /etc/sysconfig/network-scripts/ifcfg-ens192
   

   TYPE="Ethernet"
   BOOTPROTO=none
   DEFROUTE="yes"
   IPV4_FAILURE_FATAL="no"
   IPV6INIT="yes"
   IPV6_AUTOCONF="yes"
   IPV6_DEFROUTE="yes"
   IPV6_FAILURE_FATAL="no"
   IPV6_ADDR_GEN_MODE="stable-privacy"
   NAME="ens192"
   DEVICE="ens192"
   ONBOOT="yes"
   IPADDR=10.51.1.100
   PREFIX=16
   GATEWAY=10.51.0.254
   DNS1=8.8.8.8
   DNS2=8.8.4.4
   IPV6_PEERDNS=yes
   IPV6_PEERROUTES=yes
   

   systemctl restart network
   

swap 無効化

swap が有効だと kubelet が起動しないので、 swap をあらかじめ無効化しておきます。

1. swapを一時的に無効化

   swapoff -a
   

2. swapを恒久的に無効化

   リブート時に再有効化されないためには /etc/fstab の内容を一部コメントアウトします。 コメントアウトするのは swap の記載がある行（L.10）です。

   vi /etc/fstab
   

   #
   # /etc/fstab
   # Created by anaconda on Thu May 23 20:34:05 2019
   #
   # Accessible filesystems, by reference, are maintained under '/dev/disk'
   # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
   #
   /dev/mapper/cl-root     /                       xfs     defaults        0 0
   UUID=868f654f-e5e7-4369-9b43-99c462ac384d /boot                   xfs     defaults        0 0
   # /dev/mapper/cl-swap     swap                    swap    defaults        0 0
   

Docker インストール

今回はコンテナエンジンとして「Docker」を利用します。 Dockerは cgroup-driver にデフォルトだと cgroupfs を利用しているので、 Kubernetes 推奨の systemd で起動するように変更して設定していきます。

1. 実行に必要なパッケージをインストール

   yum install -y yum-utils device-mapper-persistent-data lvm2
   

2. 安定板リポジトリを設定

   yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
   

3. DockerCEをインストール

   sudo yum install \
    docker-ce-18.09.6 \
    docker-ce-cli-18.09.6 \
    containerd.io-1.2.5
   

4. daemonの設定

   systemd 経由で起動されるよう /etc/docker/daemon.json ファイルを以下の内容で作成します。

   vi /etc/docker/daemon.json
   

   {
     "exec-opts": ["native.cgroupdriver=systemd"],
     "log-driver": "json-file",
     "log-opts": {
       "max-size": "100m"
     },
     "storage-driver": "overlay2"
   }
   

   以下のコマンドを実行してサービス用のフォルダを作成します。

   mkdir -p /etc/systemd/system/docker.service.d
   

5. daemonの再読み込み

   systemctl daemon-reload
   

6. Dockerの自動起動を有効化

   systemctl enable docker
   

7. Dockerを起動

   systemctl start docker
   

Dockerが正常にインストールできたかどうかは、docker run hello-world コマンドを実行して確認できます。 以下には実行結果のサンプルも含めて掲載します。

[root@k8s-master ~]# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:0e11c388b664df8a27a901dce21eb89f11d8292f7fca1b3e3c4321bf7897bffe
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Kubernetes インストール

Kubernetes といってもインストールする実態は kubeadm 、 kubelet 、 kubectl の3つです。

1. ネットワーク設定(iptables)

   以下のような内容の /etc/sysctl.d/k8s.conf ファイルを作成します。

   vi /etc/sysctl.d/k8s.conf
   

   net.bridge.bridge-nf-call-ip6tables = 1
   net.bridge.bridge-nf-call-iptables = 1
   

   以下のコマンドで設定ファイルの読み込みを行います。

   sysctl --system
   

2. ネットワーク設定(hosts)

   ホスト名でアクセスできるよう、/etc/hosts に以下のネットワーク情報を追記します。

   vi /etc/hosts
   

   10.51.1.100 k8s-master
   10.51.1.101 k8s-node01
   10.51.1.102 k8s-node02
   

3. リポジトリの設定

   以下のような内容の /etc/yum.repos.d/kubernetes.repo ファイルを作成

   [kubernetes]
   name=Kubernetes
   baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
   enabled=1
   gpgcheck=1
   repo_gpgcheck=1
   gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
   exclude=kube*
   

4. SELinux の 無効化

   setenforce 0
   sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
   

5. Kubernetes の インストール

   yum install -y \
    kubelet-1.14.2-0.x86_64 \
    kubeadm-1.14.2-0.x86_64 \
    kubectl-1.14.2-0.x86_64 \
    --disableexcludes=kubernetes
   

6. daemonの設定変更

   Cgroup Driver に systemd を指定します。 /var/lib/kubelet/kubeadm-flags.env ファイルの内容に以下を追記します。

   vi /var/lib/kubelet/kubeadm-flags.env
   

   KUBELET_EXTRA_ARGS=--cgroup-driver=systemd
   

7. daemonの再読み込み

   systemctl daemon-reload
   

8. kubelet の 有効化

   systemctl enable kubelet
   

9. kubelet の 起動

   systemctl start kubelet
   

このタイミングまでの動作確認をしたい場合、 systemctl status kubelet で kubelet が起動しているかどうかを確認すると良いです。 以下に実行サンプルを掲載します。

[root@k8s-master ~]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           mq10-kubeadm.conf
   Active: active (running) since 日 2019-06-02 18:26:32 JST; 6h ago
     Docs: https://kubernetes.io/docs/
 Main PID: 18332 (kubelet)
    Tasks: 16
   Memory: 96.8M
   CGroup: /system.slice/kubelet.service
           mq18332 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kube...

マスタノード構築

以下の手順はマスターノードだけで行う作業です。 マスターノードにアクセスして実行していきます。

ファイアウォール設定

1. ポートの開放

   ポートレンジ	プロトコル	用途
   6443	TCP	Kubernetes API Server
   2379-2380	TCP	etcd
   10250	TCP	kubelet
   10251	TCP	kube-scheduler
   10252	TCP	kube-controller-manager

   sudo firewall-cmd --zone public --add-port 6443/tcp --permanent
   sudo firewall-cmd --zone public --add-port 2379-2380/tcp --permanent
   sudo firewall-cmd --zone public --add-port 10250/tcp --permanent
   sudo firewall-cmd --zone public --add-port 10251/tcp --permanent
   sudo firewall-cmd --zone public --add-port 10252/tcp --permanent
   sudo firewall-cmd --reload
   

マスターノードの初期化

1. 初期化

   sudo kubeadm init \
     --apiserver-advertise-address 10.51.1.100 \
     --kubernetes-version 1.14.2 \
     --pod-network-cidr 10.244.0.0/16
   

   フラグ	必須	説明
   --apiserver-advertise-address string		APIサーバーとして受け付けるIPアドレス。指定しなければデフォルトネットワークインターフェースが利用される
   --apiserver-bind-port int32		APIサーバーとして受け付けるポート。デフォルト 6443 。
   --cert-dir string		証明書の保存先を指定。デフォルトは /etc/kubernetes/pki 。
   --config string		kubeadm 用設定ファイル へのパスを指定。
   --image-repository string		イメージを取得するリポジトリを指定。デフォルトは k8s.gcr.io 。
   --kubernetes-version string		Kubernetes の バージョン を指定。デフォルトは stable-1 。
   --node-name string		ノード名を指定。
   --pod-network-cidr string	○	Podネットワークで利用するIPアドレス範囲を指定。CNIにFlannelを利用する場合、10.244.0.0/16 を指定。
   --service-cidr string		サービスに割り当てるVIP範囲を指定。デフォルトは 10.96.0.0/12 。
   --service-dns-domain string		サービスに割り当てるドメイン名を指定。デフォルトは cluster.local

   実行結果

   [root@k8s-master ~]# kubeadm init --apiserver-advertise-address 10.51.1.100 \
   > --kubernetes-version 1.14.2 \
   > --pod-network-cidr 10.244.0.0/16
   [init] Using Kubernetes version: v1.14.2
   [preflight] Running pre-flight checks
           [WARNING Firewalld]: firewalld is active, please ensure ports [6443 10250] are open or your cluster may not function correctly
   [preflight] Pulling images required for setting up a Kubernetes cluster
   [preflight] This might take a minute or two, depending on the speed of your internet connection
   [preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
   [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
   [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
   [kubelet-start] Activating the kubelet service
   [certs] Using certificateDir folder "/etc/kubernetes/pki"
   [certs] Generating "etcd/ca" certificate and key
   [certs] Generating "etcd/healthcheck-client" certificate and key
   [certs] Generating "etcd/peer" certificate and key
   [certs] etcd/peer serving cert is signed for DNS names [k8s-node00 localhost] and IPs [10.51.2.191 127.0.0.1 ::1]
   [certs] Generating "apiserver-etcd-client" certificate and key
   [certs] Generating "etcd/server" certificate and key
   [certs] etcd/server serving cert is signed for DNS names [k8s-node00 localhost] and IPs [10.51.2.191 127.0.0.1 ::1]
   [certs] Generating "ca" certificate and key
   [certs] Generating "apiserver" certificate and key
   [certs] apiserver serving cert is signed for DNS names [k8s-node00 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.51.2.191]
   [certs] Generating "apiserver-kubelet-client" certificate and key
   [certs] Generating "front-proxy-ca" certificate and key
   [certs] Generating "front-proxy-client" certificate and key
   [certs] Generating "sa" key and public key
   [kubeconfig] Using kubeconfig folder "/etc/kubernetes"
   [kubeconfig] Writing "admin.conf" kubeconfig file
   [kubeconfig] Writing "kubelet.conf" kubeconfig file
   [kubeconfig] Writing "controller-manager.conf" kubeconfig file
   [kubeconfig] Writing "scheduler.conf" kubeconfig file
   [control-plane] Using manifest folder "/etc/kubernetes/manifests"
   [control-plane] Creating static Pod manifest for "kube-apiserver"
   [control-plane] Creating static Pod manifest for "kube-controller-manager"
   [control-plane] Creating static Pod manifest for "kube-scheduler"
   [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
   [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
   [apiclient] All control plane components are healthy after 17.002251 seconds
   [upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
   [kubelet] Creating a ConfigMap "kubelet-config-1.14" in namespace kube-system with the configuration for the kubelets in the cluster
   [upload-certs] Skipping phase. Please see --experimental-upload-certs
   [mark-control-plane] Marking the node k8s-node00 as control-plane by adding the label "node-role.kubernetes.io/master=''"
   [mark-control-plane] Marking the node k8s-node00 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
   [bootstrap-token] Using token: q8793g.yx6nn1ca0ckvkqcz
   [bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
   [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
   [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
   [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
   [bootstrap-token] creating the "cluster-info" ConfigMap in the "kube-public" namespace
   [addons] Applied essential addon: CoreDNS
   [addons] Applied essential addon: kube-proxy
   
   Your Kubernetes control-plane has initialized successfully!
   
   To start using your cluster, you need to run the following as a regular user:
   
     mkdir -p $HOME/.kube
     sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
     sudo chown $(id -u):$(id -g) $HOME/.kube/config
   
   You should now deploy a pod network to the cluster.
   Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
     https://kubernetes.io/docs/concepts/cluster-administration/addons/
   
   Then you can join any number of worker nodes by running the following on each as root:
   
   kubeadm join 10.51.2.191:6443 --token q8793g.yx6nn1ca0ckvkqcz \
       --discovery-token-ca-cert-hash sha256:86d84fead96089fd28631f4f172348b823abb85f80c99fefa851ec136075df40
   

   実行結果の最後に表示される kubeadm join ~ （L.68-69）はメモしておきます。 このあと、ワーカーノード上で子のコマンドを実行してマスターノードに参加させていきます。

2. config ファイル の コピー

   kubectl を通常ユーザーで利用する場合、通常ユーザーにおいて以下のコマンドを実行します。

   mkdir -p $HOME/.kube
   sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
   sudo chown $(id -u):$(id -g) $HOME/.kube/config
   

   もし、引き続き root ユーザーで kubectl を利用する場合、rootユーザーで以下のコマンドを実行します。

   export KUBECONFIG=/etc/kubernetes/admin.conf
   

ここまでの作業がうまくできているか、 kubectl を実行して動作確認してみます。 このタイミングではまだネットワーク（CNI）が設定されていないので、 ステータスは NotReady になっています。

[root@k8s-master ~]# kubectl get nodes
NAME         STATUS     ROLES    AGE     VERSION
k8s-master   NotReady   master   3m41s   v1.14.2

Flannel インストール

1. kube-flannel.yml のダウノード

   curl -O https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
   

2. kube-flannel.yml の編集

   5箇所修正。OSプラットフォームの違いで5種類の設定があるため。

     …
         - name: kube-flannel
           image: quay.io/coreos/flannel:v0.11.0-amd64
           command:
           - /opt/bin/flanneld
           args:
           - --ip-masq
           - --kube-subnet-mgr
           - --iface=ens192        # <- 環境に合わせてNIC名を指定
     …
   

3. Kubernetes上に展開

   kubectl apply -f kube-flannel.yml
   

無事、Flannelの展開が完了して、Kubernetesのマスターノードが利用可能になっているか、kubectl get pods コマンドで Pod起動状況 を確認します。 起動までは少し時間がかかるので、何度かコマンドをたたいて様子を見てみます。 最終的にすべてのPodが Running になっていればOKです。

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-fb8b8dccf-dc59z              1/1     Running   0          11m
kube-system   coredns-fb8b8dccf-mghv4              1/1     Running   0          11m
kube-system   etcd-k8s-node00                      1/1     Running   0          10m
kube-system   kube-apiserver-k8s-node00            1/1     Running   0          10m
kube-system   kube-controller-manager-k8s-node00   1/1     Running   0          10m
kube-system   kube-flannel-ds-amd64-7rswc          1/1     Running   0          47s
kube-system   kube-proxy-j8xmv                     1/1     Running   0          11m
kube-system   kube-scheduler-k8s-node00            1/1     Running   0          10m

ワーカーノード構築

マスターノード構築後24時間以内であれば、kubeadm init 実行結果で取得されたコマンドを実行すればワーカーノードをマスターノードに登録できます。 以下の手順は マスターノード初期化後24時間以内 にワーカーノードをマスターノードに登録する手順です。

ファイアウォール設定

1. ポートの開放

   ポートレンジ	プロトコル	用途
   10250	TCP	Control plane
   30000-32767	TCP	All

   sudo firewall-cmd --zone public --add-port 10250/tcp --permanent
   sudo firewall-cmd --zone public --add-port 30000-32767/tcp --permanent
   sudo firewall-cmd --reload
   

マスターノードに登録

1. マスタノードへ参加

   sudo kubeadm join 10.51.1.100:6443 --token q8793g.yx6nn1ca0ckvkqcz \
       --discovery-token-ca-cert-hash sha256:86d84fead96089fd28631f4f172348b823abb85f80c99fefa851ec136075df40
   

もし、ワーカーノードの追加がマスターノード構築から24時間以上経っている場合、以下の手順でトークンとハッシュを作成してからワーカーノードをマスターノードに追加します。

マスターノード上で操作

1. トークンの生成

   kubeadm token create
   

2. ハッシュの取得

   openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
      openssl dgst -sha256 -hex | sed 's/^.* //'
   

ワーカーノード上で操作

1. マスターノードへ参加

   sudo kubeadm join 10.51.1.100:6443 --token <トークン> \
       --discovery-token-ca-cert-hash sha256:<ハッシュ>
   

動作確認

環境構築がすべて終わっているかどうか、Node と Pod を確認してみます。 Node を確認するには kubectl get nodes 、 Pod を確認するには kubectl get pods を利用します。 以下に実行結果のサンプルを掲載します。

[root@k8s-master ~]# kubectl get nodes
NAME         STATUS   ROLES    AGE     VERSION
k8s-master   Ready    master   6h41m   v1.14.2
k8s-node01   Ready       6h28m   v1.14.2
k8s-node02   Ready       6h28m   v1.14.2

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-fb8b8dccf-tjrv9              1/1     Running   0          6h41m
kube-system   coredns-fb8b8dccf-w8qmr              1/1     Running   0          6h41m
kube-system   etcd-k8s-master                      1/1     Running   0          6h41m
kube-system   kube-apiserver-k8s-master            1/1     Running   0          6h41m
kube-system   kube-controller-manager-k8s-master   1/1     Running   0          6h40m
kube-system   kube-flannel-ds-amd64-fqmdp          1/1     Running   0          6h28m
kube-system   kube-flannel-ds-amd64-ql2g2          1/1     Running   0          6h28m
kube-system   kube-flannel-ds-amd64-xhrmx          1/1     Running   0          6h36m
kube-system   kube-proxy-7wglt                     1/1     Running   0          6h41m
kube-system   kube-proxy-ckfwd                     1/1     Running   0          6h28m
kube-system   kube-proxy-hz4k9                     1/1     Running   0          6h28m
kube-system   kube-scheduler-k8s-master            1/1     Running   0          6h41m

「Node が 仮想マシン分あること」、「flannel の Pod が仮想マシン分あること」が確認できれば環境構築ができていることの確認になります。 そもそも Flannnel 自体が Kubernetes の仕組み上で動作している DaemonSet という種類のリソースで、各ノードに1台ずつ配置されるものなので、

[参考] うまくいかず再設定したい場合

Docker

• Daemonの停止、無効化

  systemctl stop docker && systemctl disable docker
  

• ファイル/フォルダ削除

  rm -f /etc/docker/daemon.json
  rm -rf /etc/systemd/system/docker.service.d
  

• Dockerアンインストール

  yum remove docker-ce docker-ce-cli containerd.io
  

Kubernetes

• Daemonの停止、無効化

  systemctl stop kubelet && systemctl disable kubelet
  

• kubernetesクラスタの初期化

  kubeadm reset
  

• ファイル/フォルダ削除

  rm -f /var/lib/kubelet/kubeadm-flags.env
  

• kubelet, kubeadm, kubectl の削除

  yum remove \
   kubelet \
   kubeadm \
   kubectl
  

[参考] 各種確認

エラーが発生して困ったときに利用した各種確認用のコマンドの覚書。

Kubernetes

# node, pod の一覧
kubectl get nodes
kubectl get pods --all-namespaces

# 詳細確認(Kubernetes視点)
kubectl describe nodes <node name>
kubectl describe pods <pod name> -A

# kubelet のエラー確認(詳細確認はできない・・・)
systemctl status kubelet

# kubelet のエラー確認（詳細も確認）
journalctl -xe -u kubelet

今回は「CentOS上にシングルマスター構成のKubernetesクラスターを構築する方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• kubernetes - Installing kubeadm
• kubernetes - Creating a single master cluster with kubeadm
• kubernetes - CRI installation
• Qiita - Kubernetes on CentOS7
• GitHub - coreos/flannel
• 寝て起きて寝る - kubeadmでKubernetes1.9.3のClusterを構築したメモ
• Qiita - Kubernetes on CentOS7

今回は Nested Virtualization の１つとして「ESXi 上に Hyper-V を構築する方法」についてまとめます。

事象

ESXi 上の Windows 内で Docker を利用しようと思ったら、Hyper-V が利用できないために正常起動しないという事象がありました。 そのとき発生したエラーは、以下のようなものでした。

Unable to start: ユーザー設定変数 "ErrorActionPreference" または共通パラメーターが Stop に設定されているため、実行中のコマンドが停止しました。'MobyLinuxVM' は起動できませんでした。

Hyper-V コンポーネントの 1 つが実行されていないため、仮想マシン 'MobyLinuxVM' を起動できませんでした。

'MobyLinuxVM' は起動できませんでした。(仮想マシン ID BA02EB4E-07B5-44D1-B97E-B1AEEF2D1730)

Hyper-V コンポーネントの 1 つが実行されていないため、仮想マシン管理サービスは仮想マシン 'MobyLinuxVM' を起動できませんでした (仮想マシン ID BA02EB4E-07B5-44D1-B97E-B1AEEF2D1730)。
Start-MobyLinuxVM、<ファイルなし>: 行 296
、<ファイルなし>: 行 412
   場所 Docker.Core.Pipe.NamedPipeClient.Send(String action, Object[] parameters) 場所 C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.Core\pipe\NamedPipeClient.cs:行 36
   場所 Docker.Actions.DoStart(SynchronizationContext syncCtx, Boolean showWelcomeWindow, Boolean executeAfterStartCleanup) 場所 C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.Windows\Actions.cs:行 92
   場所 Docker.Actions.<>c__DisplayClass19_0.b__0() 場所 C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.Windows\Actions.cs:行 74
   場所 Docker.WPF.TaskQueue.<>c__DisplayClass19_0.<.ctor>b__1() 場所 C:\workspaces\stable-18.09.x\src\github.com\docker\pinata\win\src\Docker.WPF\TaskQueue.cs:行 59
   

今回は、上記エラーを解消する方法を以下に手順として整理しました。

対応

1. Hyper-Vを有効化したい仮想マシンをシャットダウンしておく

2. Hyper-Vを有効化したい仮想マシンを選択し、[アクション]-[設定の編集]を開く

   

3. 「仮想ハードウェア」の「CPU」の項目を開き、 「ハードウェア仮想化」にある「ハードウェア アシストによる仮想化をゲスト OS に公開」を有効化

   

4. 「設定の編集」を「保存」して閉じる

   

5. Hyper-Vを有効化したい仮想マシンを起動

作業としては以上でDockerが利用できるようになります。

[おまけ] GUI から vmx ファイルを修正する方法

ただ、参考にした各サイトはいずれも以下の設定を追記していたようですが…追記しなくても動作はするようです。

• vhv.enable = "TRUE"
• hypervisor.cpuid.v0 = "FALSE"

もし、仮に設定するにしても[仮想マシンオプション]タブ→[詳細]-[構成の編集]から追加したほうが簡単です。 以下に簡単な手順を載せておきます…。

1. 「設定の編集」にある「仮想マシンオプション」タブへ移動

   

2. 「詳細」を展開

   

3. 「構成の編集」を選択

   

4. 「パラメータの追加」を選択して追加

   

   vhv.enabl

   "TRUE"

   hypervisor.cpuid.v0

   "FALSE"

5. [OK]を選択して保存

   

今回は「ESXi 上で Hyper-V を動作させる方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• オラクる。 - ESXi上の仮想マシンにHyperVを構築する方法
• らくがきちょう - vSphere ESXi 上の仮想マシンで VT-x を有効化するには
• tokyo-wasted’s diary - Nested ESXi 構築時のレシピまとめ (vSphere 6.5 + vSAN)
• watercloud.net - VMwareの仮想マシン上でIntel VT-x等の仮想化支援機能を有効にするには

今回は「テスト実施結果報告 は どのように作るべきか」についてまとめます。

報告を受け取る人は何を知りたいのか

【タイミング】

テストフェーズごと（単体テスト、結合テスト…）に結果をまとめて報告する。 システムテストや受入テストなど最終フェーズのテストではそこに至るまでのテスト結果を総括したほうがベター。 労力かかるので実際はあまりやらない気がします（金融系などしっかりした開発を求められる場合は必要かも）。

【報告先】

報告先は自分自身のポジションによりますが、体制図上の上位者が一般的でしょう。 場合によっては、客先やシステムオーナーだったりするかもしれません。

【報告内容】

大きな項目としては「総括を意味する概要」、「具体的な中身を記載した詳細」になります。 報告先にもよりますが、基本はあまり細かな話しをしても仕方がないので、「概要」で8割説明しきる内容で報告が望ましいはず。 「詳細」には「"進捗" と "品質"」と「"テスト" と "アプリ"」を掛け合わせた4観点（テストケース消化、不具合解消、テスト品質、アプリ品質）を記載すると網羅的です。

具体的な内容はこの後の各セクションで詳しく見ていきます。

テスト実施状況の分析

最終断面

断面として洗い出すとよさそうな数値は以下のようなものがあります。

• 当初計画ケース数
• 実施予定ケース数
• 実施実績ケース数
• 完了ケース数（ or 未完了ケース数）

「当初計画ケース数」は「テストフェーズ開始時点でのテストケース数」、 「実施予定ケース数」は「テストフェーズ完了時点（＝報告書作成時点）でのテストケース数」、 「実施実績ケース数」は「実際に実施してテストケース数」、 「完了ケース数」は「テスト実施して障害検出されずOKとなったケース数」です。

理想的には以下のような数式になるハズです。

「当初計画ケース数」＝「実施予定ケース数」＝「実施実績ケース数」＝「完了ケース数」

「当初計画ケース数」と「実施予定ケース数」にはズレがあることがあります。 テスト実施する中で、テストケースの追加や削除を行った場合です。 これらについては後続のテスト品質分析で原因分析と対策を行います。

「実施予定ケース数」と「実施実績ケース数」がズレることはまずありえないです。 もしあるとすればそれは管理者の管理怠慢としか言えない気がします…。 報告時点ではケース実施不要の判断をして「実施予定ケース数」＝「実施実績ケース数」にしてしまいましょう。

「実施実績ケース数」と「完了ケース数」がズレる場合は状況によってはありえます。 未完了ケースがあるということは、障害が解消できないためにケース消化ができていないという状況です。 該当の障害が後続テストに影響ないことを確認するか、または後続テストに影響がないよう調整します。

実施済みテストケース累積

時間とともに実施ケース数が増えており、最終的には飽和していることを確認します。 最初はどうしても消化ケースが増えないですが、中盤からいっきに増えます。 終盤で盛り上がっているのは追加テストを実施した場合です。 理想的には一通りテストが終わった後に不具合分析して追加テストして終結するのが良い気がします（コストかかるけど…）。

不具合解消状況の分析

最終断面

断面として出す数値としては以下のようなものがあります。

• 総検出件数
• 解消件数

理想的には以下のような数式になるハズです。

「総検出件数」＝「解消件数」

一致しない場合、解消できていない障害が残っている状況になるので、残障害となるものそれぞれについて今後どのような対応を行っていくのかの方針を示します。

信頼度成長曲線

一般的に信頼度成長曲線はS字カーブを描きます。 時間経過とともに不具合発生件数が飽和していき、不具合解消件数も飽和している状態であることを確認します。

テスト品質の分析

テスト自体（テストケース、テスト実施者、テスト環境）の品質を確認するものです。 実施したテストが必要十分なケースであり問題のないテスト実施であったことを示します。

ケース見直しに対する原因と対策

テスト実施していると「テストケース追加」や「テストケース削除」が起こります。 実施していると見えていなかったものが見えてくることから起こるものです。

「テストケース削除」は「実施できないので後続テストフェーズに移管」か「他ケースで担保できるので実施不要」となって消されることが多いです。 このケースであれば、本当に必要なことをやっていないわけではないので特に問題ではないです。

「テストケース追加」は「ある観点が漏れていた」可能性があります。 類似する観点でほかに漏れがないか確認できているかを示す必要があります。

障害起票されたが障害確定しなかったチケットの分析

テスト実施中にはいったん起票されたが実は障害ではなかったというものが紛れています。 そうした障害にならなかったチケットはテストケース、テスト実施者、テスト環境に問題があることが多いです。 以下に示すように大きく3分類してさらに詳細原因を深掘りしていきます。

テストケース不備

• ユーザーの要求事項別
• 機能・サブシステム別
• テストケース作成者別

オペレーションミス

• 根本原因別（プロセス、マニュアル、テストケース不備、テストツール…など）

テスト環境不備

• 対象別（設定、前提データ）

基本的には上述の観点を参考に、どこに偏りがあるかを見つけて対策を打っていきます。

障害起票漏れしていたケースの分析

いわゆる「False Negative」なケース。 テスト実施後の承認タイミングで起票漏れが検知されたようなケース。 実施者に問題があるケースが多いイメージはありますが、数値で示すなら以下のような分析をしてみると良い気がします。

• 実施者別
• テストケース作成者別
• ユーザーの要求事項別
• 機能・サブシステム別

アプリケーション品質の分析

テスト実施されたアプリケーションの品質が十分高まっていることを示します。

不具合報告の記載内容による分類

不具合がなぜ埋め込まれたのか、その影響はどんなところに対するものかなど、不具合が入り込む過程と影響する内容に関する分類です。

• 重大度別
• 現象別
• 原因別
• 混入肯定別・除去工程別

重大度別	主観的な評価になりやすい項目になるのであらかじめ定義が必要です。 たとえば、エンドユーザーに対する影響度という視点で以下のように切り分けてみます。 「高＝エンドユーザーに対する影響がある」 「中＝その他何かしらの影響がある」 「低＝未発現で実質的な影響がない」 これらの定義に従った分類をした際に偏りがないかを確認します。 （障害対応の "優先度" とは異なるので注意してください）
現象別	どのような症状があらわれているかで分類します。 直接原因となっている欠陥の内容ではなく、発現している事象で分類します。 たとえば以下のようなものになります。 画面表示（崩れ、位置が不正、項目過不足、無反応） 入力チェック 登録内容 メール（未送信、内容不備） プッシュ通知（未通知） ファイル（出力されない、項目過不足、内容不備） 通信（接続できない）
原因別	不具合を埋め込んでしまった根本原因別で分類します。 m-SHELL などを参考に原因分類してみると良いでしょう。 管理 ソフト（プロセス、手順書、マニュアル…など） ハード（ツール…など） 環境（PC、モニタ…など） 当事者 関係者
混入工程別・除去工程別	どの工程で欠陥を埋め込んでしまったか、本来どの工程で除去すべきだったかという視点で分類します。 前工程で適切な除去ができていないようであれば、さかのぼって見直しをする必要があります。

ソフトウェアの作り方による分類

不具合そのものがどのようなものであるかを分析したものです。

• ユーザーの要求事項別
• サブシステム別・機能別
• ソフトウェアの処理分類別
• データ項目別

ユーザーの要求事項別	不具合に関連する要件を記載します。 複数要件にまたがる不具合も起こりうるので複数入力できると良いでしょう。 特定要件に不具合が集中している場合、その要件の見直しや追加テストを検討します。 逆に特定要件で不具合が出ていない場合、誤ったテストをしていないか、テストに不足がないかを確認します。
サブシステム別・機能別	不具合が発生したサブシステム別や機能別に集計します。 分析の考え方は要求事項別と同じで、不具合が多すぎる機能、少なすぎる機能に対して分析を行います。
ソフトウェアの処理分類別	不具合の原因となった箇所（欠陥箇所）の処理分類別に集計します。 画面表示 入力チェック データ登録 データ検索 データ更新 データ削除 文字列操作 算術演算 「不具合の現象」と似ているが異なるものです。 「現象」は「ユーザーによって認識される事象」ですが、 「処理」は「現象を引き起こす不具合の原因（欠陥）」です。
データ項目別	不具合が影響を及ぼしているまたは不具合の原因となっているデータ項目別に集計します。 対象としている業務にも依存するので一概に例示できないですが、以下のようなものが考えられます。 権限 ユーザー情報 管理者情報 企業情報 記事情報 少し抽象的な記載になっていますが、もう少し具体的な分析を行えばよく問題を起こすデータ（注意しなければならないデータ）などがあぶりだせるようになります。 過去から修正を繰り返すことで取り回しが難しくなってしまったデータ、なんてものも存在するので…。

テスト実施方法による分類

不具合を見つけたテストに関する情報で分類します。 どちらかと言うとシステム全体を通しての品質分析での利用になると思います。 各テスト工程でこの分類は出てこないでしょう。

• テスト工程別
• テスト種類別
• テスト観点別

テスト工程別	テスト工程別に集計します。 単体テスト サブ内テスト サブ間テスト システムテスト
テスト種類別	テスト種別ごとに集計します。 ドキュメントレビュー ウォークスルー コードレビュー 機能確認テスト 制御フローテスト データフローテスト 状態遷移テスト リグレッションテスト（修正箇所に関連する） デグレードテスト（修正箇所に関連しない） セキュリティテスト ユーザビリティテスト 性能テスト
テスト観点別	テスト観点別に集計します。 機能 信頼 使用 効率 保守 移植 テスト観点については「テスト観点 の サンプル」にもまとめているので参考にしてください。

今回は「テスト実施結果報告 は どのように作るべきか」についてまとめました。 ただ、見て分かる通り、この報告を行うためには障害管理を報告できるように行うようにしないといけません。 障害管理を始めるときにあらかじめ最終的な障害報告までイメージしてないと実運用では困りそうですね…。

参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

今回は「不具合が埋め込まれて見つかるまで」どのような仕組みになっているかを解き明かしていきます。

プロジェクトにおける「不具合管理」やテストフェーズでの「不具合対応フロー」などを考えるためのベースとなる情報になるハズです。

プロセス全体像

現実、現場で働いている状況踏まえての感覚や前述の内容を踏まえてまとめると以下のような構造が作れる気がします。 作りとしては不具合発生のプロセスと不具合管理フローを組み合わせたようなものになっています。

• 根本原因

  環境や組織、ソフト、ハードといった面でシステム開発にとって適切でない状態となっていると、そこが原因となって次の誤りを誘発します。

• 誤り

  前述の根本原因がもととなって間違った認識や間違った行動を行い、次の欠陥を埋め込みます。

• 直接原因（欠陥）

  埋め込まれた欠陥は直接的な不具合の原因となるため、直接原因と呼ばれたりもします。 埋め込まれる場所はどこにでもありうるものです。

• 障害

  埋め込まれた欠陥は利用、実行されるとその不備が発現して問題へと発展していきます。 このとき、特に設計や実装に埋め込まれた欠陥のことを障害と呼びます。

• 問題

  埋め込まれた欠陥は最終的にエンドユーザーが期待する動作と異なる動作として表出してきます。

根本原因

すべての出発点になります。 根本原因の分析方法はいくつかありますが、図では「m-SHELL」という考え方を示しています。 m-SHELL はもともと航空分野で使われていたもののようですが、IT分野でも使えそうなものです。

「m-SHELL」を使った原因分析では以下の6パターンに分類して考えます。

観点			例
m	Management	管理	経営方針、安全管理など
S	Software	ソフトウェア	プロセス、手順書、マニュアル、規則など
H	Hardware	ハードウェア	機器、機材、設備、施設の構造など
E	Environment	環境	温度、湿度、照明など
L	Liveware	当事者	欠陥を埋め込んだ本人
L	Liveware	関係者	当事者以外の関係者、同僚など

誤り

さまざまな根本原因が積み重なった結果、人はミスを犯します。 そして、人が誤った行動をとった結果として欠陥が生み出されます。 （何もしなければミスも起こさないし、欠陥も生み出さないです。そもそもそんな人は何も生み出していないですが…）

では、その「行為の誤り」はなぜ起こるのでしょうか。 よくあるのは「認識の誤り」や「判断の誤り」といったところが考えられます。

直接原因（欠陥）

直接原因は「欠陥」であることが多いです。 ドキュメントの不備であったり、実装の誤りといった分かりやすいものです。

「問題（＝あるべき姿と現状のギャップ）」を生み出しているのがどこかを特定すると、この欠陥になります。

障害

「ケアレスミス」「単純ミス」などが「欠陥」をドキュメントやコードに埋め込みます。 埋め込まれた「欠陥」の箇所のうち特に「設計」や「実装」に埋め込まれた「欠陥」のことを特別に「障害」と呼びます。

「運用障害」とも呼ばれるような、実運用中に発生するネットワーク障害や外部攻撃など運用上の問題、ハードウェア上の問題もあります。 要件として定義されていたにもかかわらず対応できていないのであれば何かしらの「運用設計」や「運用を考慮した実装」ができていないという「障害」となります。 実際は問題発生を想定できていないことが多く要件が存在しないことが多い感覚です。 要件が定義できていないのであれば「要件不備」で要件元の問題（＝今回の定義では「障害」ではない）ですが… 「エンドユーザーに対するサービス影響は出さない」という暗黙の要件があるので、何かサービス影響ある問題起こせばすべて「障害」というカタチでくくられてしまう気がします。

「ユーザーに対するサービス影響有無」で「障害」かどうかを判断するケースもあるようです。 実際の感覚だと「ユーザーに対するサービス影響有無」には関係なく「システムに問題がある（＝設計か実装に欠陥が混入している）」状態であれば「障害」と呼んでいる気がします。 「ユーザーに対するサービス影響有無」はどちらかと言うと、障害対応時の優先度を考えるための判断材料になる気がします。

問題

「障害」のあるシステムを動かすとシステムはユーザーの期待と異なる動作をします。 この「 "ユーザーが期待する動作" と "システムの実際の動作" のギャップ」を問題と呼びます。 不具合管理システム上だと「不具合」と呼んだりすることもあります。

テスト実施や運用でまず上がるのは「問題」です。 「問題」は「障害」以外も含んでいるので、最初に「障害」かどうかの判定（または切り分け）が必要になります。

「期待と異なる動作」だけであれば、本来は「問題（＝"あるべき姿"と"現状"のギャップ）」であって、障害（＝設計または実装の不備）とまでは言えない状態です。 ただ、現場の感覚だと「問題（＝ "あるべき姿" と "現状" のギャップ）」と「障害（＝設計/実装の不備）」のあたりを混同して話されることが多く見受けられます。

今回は「不具合が埋め込まれて見つかるまでのプロセス」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

今回は「不具合、欠陥、バグ、障害、エラー … などの用語の示す意味の違い」についてまとめます。

はじめに

用語の定義はプロジェクトによってまちまちなので、プロジェクトに参画するたびメンバーと認識をあわせる必要があります。 実際、不具合まわりの解説をしているブログやサイトも名称はやや異なる定義をしていたりしました。

ここでは「用語にはどんなものがあるか」と「分類する考え方にどんなものがあるのか」をまとめているので、プロジェクトにあわせて適切に組み合わせて利用するような使い方をイメージして記事を書いています。

どんな用語があるのか

よく見かける用語を洗い出すと以下のようなものになります。 これら以外にもまだまだありそうですが、これだけの用語に対してプロジェクトで同一の認識がとれないと混乱を生んでしまう原因になってしまします。。

【用語集】

• 問題
• 課題
• 不具合
• 障害
• 欠陥
• 故障
• 誤り
• incident
• defect
• fault
• failure
• error
• bug

分類して違いを理解する

分類方法をいろいろと調べて整理しようとしたのですが、どうもしっくり来ませんでした。 結局、考え方によって名前の付け方が異なるようだったので、以下の分類方法（考え方）についてそれぞれまとめてみます。

• 不具合発生のメカニズムによる分類（機電系）
• 不具合発生のメカニズムによる分類（ITシステム系）
• テスト実施時の不具合管理フローによる分類

不具合発生のメカニズムによる分類（機電系）

不具合発生のメカニズムから分類する場合、以下の3工程に分類できます。

• 欠陥（defect）

  「システム内に内在する企図と異なる動作の要因となる不備」のこと。

• 障害（fault）

  「欠陥によって誘発される、システムがユーザーの期待する動きと異なる動きをする事象」のこと。

• 故障（failure）

  「障害が発生した結果、システムが利用できなくなる事象」のこと。

不具合発生のメカニズムによる分類（ITシステム系）

ITシステム開発の現場でよく見かける流れにしたがった分類です。 ISTQBの定義に近い定義の方法になります。 出てくる用語は4種類になります。

図は障害分析の考え方としても使えそうなものにしてみました。

• 誤り（mistake）

  「望まない結果を生み出す人の間違った行動」のこと。

• 欠陥（defect, bug, fault）

  「システム内に内在するコードやドキュメントの不備」のこと。

• 障害（failure）

  「システムがユーザーの期待する動きを提供できない事象」のこと。 システムに「欠陥」があったとしても実行されなければ「障害」とはならない。

• 問題（error）

  「障害（"期待する動作"と"現状の動作"のギャップ）を検知して明文化されたもの」のこと。 「問題」がすべて「障害（＝システム上の問題）」とは限らない。 後述の「不具合管理フロー」にある通り、要件漏れ/不備、操作者のミスといったものも含まれる。

テスト実施時の不具合管理フローによる分類（ITシステム系）

こちらもITシステム開発の現場で見かける分類になります。

テスト実施時に行われる不具合管理のフローに従った分類を行うと、以下の2種類に分類できます。

• 不具合

  「システムを使うユーザーが期待する動きと異なる動きをする事象」のこと。 「設計/実装の問題」か「それ以外の問題」かを分離する前の状態。 前述の「不具合発生のメカニズムによる分類（ITシステム系）」における「問題」とほぼ等しい。

• 欠陥

  「要件で定義された通りの設計や実装になっていない事象」のこと。 実際には「要件がそもそも漏れていた、考慮できていなかった」や「テスト仕様書の不備」「テスト実施者の誤り」もあるため、「不具合」の原因がシステムに起因していると特定された状態。 前述の「不具合発生のメカニズムによる分類（ITシステム系）」における「障害」とほぼ等しい。

参考記事

• DevelopersIO - システムのバグと欠陥の哲学
• たこはちの「へのかっぱ」日記 - 不具合と欠陥
• Programmer_Mixin_Conductor's Blog - 用語整理：エラー（誤り）、バグ・欠陥・フォールト、故障、インシデント

今回は「不具合や欠陥といった用語の整理」を行いました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！