Calico install

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680051/3d018d4a-8be2-1f65-e886-25eaabbf222f.png)


## はじめに

Kubernetsクラスタのポットが使用するネットワークを構成するために、Calicoというツールをデプロイする。

基本的に、Kubernetesクラスタの構築は、公式ドキュメントにインストール方法の記載があるのでそれを参考にしている。
しかし、CNIに関してはインストールが必要であるということと、その際の注意事項のみの記載である。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680051/a4b51e38-eaf6-d58b-f8b9-ba496d92a82a.png)

そのため、本書ではCNIの1つであるCalicoのインストール方法をまとめる。

## 参考文献
Kubenetes Document
[Kubernetes Document](https://kubernetes.io/ja/docs/home/)

Calico Document
[Calico Document](https://docs.tigera.io/calico/latest/about/)


## 前提条件
kubeadm initが完了したKubernetesクラスタが必要。
デプロイ方法は、以下ご参照。
[Kubernetes install](https://qiita.com/haru_yama/items/cdd721fbc48a577aedd0)
```
kubectl -n kube-system get pod
NAME                                        READY   STATUS    RESTARTS   AGE
coredns-7db6d8ff4d-58mm5                    0/1     Pending   0          20m
coredns-7db6d8ff4d-g5rkv                    0/1     Pending   0          20m
etcd-kube-controller01                      1/1     Running   2          20m
kube-apiserver-kube-controller01            1/1     Running   1          20m
kube-controller-manager-kube-controller01   1/1     Running   0          20m
kube-proxy-94xnx                            1/1     Running   0          20m
kube-scheduler-kube-controller01            1/1     Running   1          20m


kubectl get node
NAME                STATUS     ROLES           AGE   VERSION
kube-controller01   NotReady   control-plane   23m   v1.30.2
```

前提条件が整ったところで、公式ドキュメントを参照しながらインストールを行っていく。

## Calico公式ドキュメントより、インストール方法が記載された箇所を探す
Calicoをインストールするために、まずはCalicoの公式ドキュメントにアクセスする。
(CalicoはTigera社という会社が提供しているサービスであることを知った。)

基本的に、インストール方法についてはドキュメントから外れない・ドキュメント以外のことでシステムに変更が加わるようなことは実施しない。

私もよく、一発でインストールできてしまうQiitaの記事などを参照してしまうが、それらはあくまで公式ドキュメントを読む際の補足資料的立ち位置でなければならない。

こちらの、「Quickstart for Calico on Kubernetes」という箇所にインストール方法が記載されていた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680051/4f5735cc-8bc8-2aed-a78c-812221060174.png)


## install 前準備
公式ドキュメントには、Calicoをインストールする前の準備について「Create a single-host Kubernetes cluster」という部分で言及されていた。

ここでは、Kubernetesクラスタのインストールやpodが使うネットワーク設定などのついて記載されている。

以下、順番に確認していく。
### 1.kubeadmのインストールはできているか
CalicoはKubernetesのpodとして利用するため、Kubernetesクラスタ
こちらは、前提条件にも指定していたので、確認済である。
読み飛ばして問題ない。

### 2.sudo権限を持つユーザでkubeadmをインストールしたホストにログイン
私の場合、`mainte`というユーザがsudo権限を持っているので、それでログインできていればOK

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680051/2dbe6c4b-a5be-ff34-974e-aa3b226d05be.png)

### 3.podのCIDRを指定して、kubeadmを初期化
podネットワークに`192.168.0.0.16`のセグメントを割り当てる。

今は、podネットワークを指定していない状態でkubernetesクラスタが起動しているので、いったんresetする。

```
[実行コマンド]
sudo kubeadm reset

[結果]
取得漏れ
```
(ここはいつも結果だけ見てるが、ちゃんと止まっていることを確認したい場合は、kubectlコマンド打つか・kubeletのstatusを確認すればいいかな)

次に、再度podネットワークを指定して立ち上げる。
```
[実行コマンド]
sudo kubeadm init --pod-network-cidr=192.168.0.0/16

[結果]
取得漏れ
```

次に、podネットワークがちゃんと設定されているか確認を行う。確認を行うためには、kubernetesを構成しているノードの詳細情報を調べればよい。

まずは、現在のkubernetesクラスタのノードを表示させる。

```
[実行コマンド]
kubectl get node

[結果]
NAME                STATUS     ROLES           AGE   VERSION
kube-controller01   NotReady   control-plane   23m   v1.30.2
```
現在のKubernetesクラスタは、`kube-controller01`1台構成となっている。

次に、kube-controller01の詳細情報を表示する。
その際は`kubectl describe`というコマンドを使う。
このコマンドは、ノードの容量や現在そのノードで構成しているpod、podリソースなどを表示してくれる。

サーバのチューニングを行う際などは、describeで状況を確認してから変更を加えることが多い。

```
POD CIDR確認

[実行コマンド]
kubectl describe node kube-controller01 | less

[結果]
...
PodCIDR:                      192.168.0.0/24
PodCIDRs:                     192.168.0.0/24
...
```
となり、initで指定した通りのCIRDになっていることが分かった。

### kubectlをrootユーザ以外でも実行できるようにする設定

これは、Kubernetes公式ドキュメントにも記載されているので、その通りに実行。

エンジニアとして、人に説明する際に「以下のコマンドを実行する」とだけ言って済ませてしまうことが多い。

しかし、それは同じ知識レベルの人にしか分かってもらえないと考えてる。
自分よりも知識の無い人に説明する際、「以下のコマンドを実行する」だけでは、自分が説明する手間を省くために**コピペする・エンターを押す** ことしか指示できていない。

```
[実行コマンド]
sudo cp -i /etc/kubernetes/admin.conf /home/mainte/.kube/config

[確認コマンド]
mainte@kube-controller01:~$ ll /home/mainte/.kube/config

[結果]
-rw------- 1 root root 5653 Jul 28 02:48 /home/mainte/.kube/config

[所有者変更の実行コマンド]
mainte@kube-controller01:~$ sudo chown mainte:mainte /home/mainte/.kube/config 

[確認コマンド]
ll /home/mainte/.kube/config

[結果]
-rw------- 1 mainte mainte 5653 Jul 28 02:48 /home/mainte/.kube/config
```

## Install Calico
先ほどまででインストール前の準備は終わった。
次は、公式ドキュメントの「Install Calico」を参考にしてインストールを進める。

全部で5ステップあるので1つ1つ見ていく。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680051/4e51db88-5323-569e-d502-34650c87f6f6.png)


### 1.Tigera Calicoオペレーターとカスタムリソース定義
公式ページより、`https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml`リソースの設定情報が記載されているyamlファイルを取得する。

ここでは、Calico本体というより、そのオペレータをインストールしている。

一回、指定のURLが正しいかと、中身を確認してみる。
```
[実行コマンド]
curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml | less

[結果]
metadata:
  name: tigera-operator
subjects:
- kind: ServiceAccount
  name: tigera-operator
  namespace: tigera-operator
roleRef:
  kind: ClusterRole
  name: tigera-operator
  apiGroup: rbac.authorization.k8s.io
...
```
URLが正しいことは分かった。
内容であるが、2万行以上にも及んでいたため、一番上の数行ではnamespaceやdeploymentの名前かもしれないものが載っていた。

kubectl createコマンドは、Kubernetesのコマンドラインツールkubectlを使用して、指定されたリソースをクラスタに作成するために使用される。
このコマンドを使って、Kubernetesリソース（ポッド、サービス、デプロイメントなど）を定義したYAMLファイルを適用し、そのリソースをクラスタに作成する。

自分の予想だと、createコマンド実行後は、`kubectl get deployments`をすると`tigera-operator`というものが表示される。だろうと考える。


```
[実行コマンド]
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml

[結果]
namespace/tigera-operator created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgpfilters.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
...
clusterrole.rbac.authorization.k8s.io/tigera-operator created
clusterrolebinding.rbac.authorization.k8s.io/tigera-operator created
deployment.apps/tigera-operator created

[実行コマンド]
kubectl get ns

[結果]
NAME              STATUS   AGE
default           Active   3h18m
kube-node-lease   Active   3h18m
kube-public       Active   3h18m
kube-system       Active   3h18m
tigera-operator   Active   42s

[実行コマンド]
kubectl -n tigera-operator get deployment

[結果]
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
tigera-operator   1/1     1            1           66s

[実行コマンド]
kubectl -n tigera-operator get pod

[結果]
NAME                               READY   STATUS    RESTARTS   AGE
tigera-operator-76ff79f7fd-2jsxz   1/1     Running   0          85s

```
tigera-operatorのpodが立ち上がっていることが分かった。


### 2.必要なカスタムリソースを作成してCalicoをインストールする

まずは、ドキュメントで指定しているURLが正しいか確認する。

```
[実行コマンド]
curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml

[結果]
# This section includes base Calico installation configuration.
# For more information, see: https://docs.tigera.io/calico/latest/reference/installation/api#operator.tigera.io/v1.Installation
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  # Configures Calico networking.
  calicoNetwork:
    ipPools:
    - name: default-ipv4-ippool
      blockSize: 26
      cidr: 192.168.0.0/16
      encapsulation: VXLANCrossSubnet
      natOutgoing: Enabled
      nodeSelector: all()

```
ここで気づいたが、このにもcidr表記がある。
そのため、自分が設定したものと一致しない場合はエラーが起こるかもしれない。

```
[実行コマンド]
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml

[結果]
installation.operator.tigera.io/default created
apiserver.operator.tigera.io/default created
```

Calicoのpodが立ち上がっているか確認する。
```
[実行コマンド]
kubectl get ns

[結果]
NAME              STATUS   AGE
calico-system     Active   39s
default           Active   5h26m
kube-node-lease   Active   5h26m

[実行コマンド]
kubectl -n calico-system get deployment

[結果]
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
calico-kube-controllers   0/1     1            0           64s
calico-typha              1/1     1            1           65s

[実行コマンド]
kubectl -n calico-system get pod

[結果]
NAME                                      READY   STATUS              RESTARTS   AGE
calico-kube-controllers-7969fd476-7pxvh   1/1     Running             0          84s
calico-node-4s2bb                         0/1     Running             0          84s
calico-typha-7975c59f4-vhktj              1/1     Running             0          84s
csi-node-driver-6l96d                     0/2     ContainerCreating   0          84s
```
いくつか立ち上がっていないpodもあるが、インストールされてることは確認できた。

### 3.インストールした結果、podが動いているか確認する。

インストールしたら確認する。
watchコマンドを使ってリアルタイムでのステータスの変化を観察する。
```
[確認コマンド]
watch kubectl get pods -n calico-system

[結果]
NAME                                      READY   STATUS    RESTARTS   AGE
calico-kube-controllers-7969fd476-7pxvh   1/1     Running   0          6m2s
calico-node-4s2bb                         1/1     Running   0          6m2s
calico-typha-7975c59f4-vhktj              1/1     Running   0          6m2s
csi-node-driver-6l96d                     2/2     Running   0          6m2s
```
全て`Running`担っていることが確認できた。


### 4.コントロールプレーンノードがuntaintであるように設定する

`kubectl taint`は、Kubernetesノードに「taint」（汚染）を設定または削除するためのコマンドである。
taintを設定することで、そのノードに特定のPodがスケジュールされるのを防ぐことができる。
逆にtaintを削除すると、制限が解除され、そのノードにPodがスケジュール可能となる。

Calicoはネットワークポリシーとネットワーク接続のためのCNI（Container Network Interface）プラグイン。Calicoの一部のコンポーネントはコントロールプレーンノードでも動作する必要がある。

例えば、Calicoのコントロールプレーンコンポーネントは、コントロールプレーンノードにPodとしてスケジュールされることがある。

そのためには、コントロールプレーンノードがPodを受け入れられるように「taint」の制限を外すことがある。

```
[実行コマンド]
kubectl describe node kube-controller01 | grep -i taint

[結果]
Taints:             node-role.kubernetes.io/control-plane:NoSchedule

[実行コマンド]
kubectl taint nodes --all node-role.kubernetes.io/control-plane-

[結果]
node/kube-controller01 untainted

[実行コマンド]
kubectl describe node kube-controller01 | grep -i taint

[結果]
Taints:             <none>
```
前後確認を行った。
nodeのTaintsがnoneに変化したので、設定が反映されていることが確認できた。

### 5.クラスター内のノードを確認

nodeが正常に稼働しているか確認する。

```
[実行コマンド]
kubectl get nodes -o wide

[結果]
NAME                STATUS   ROLES           AGE     VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
kube-controller01   Ready    control-plane   5h47m   v1.30.2   10.0.2.15     <none>        Ubuntu 22.04.3 LTS   5.15.0-113-generic   cri-o://1.31.0
```
ノードは問題なく稼働していることが分かった。

## calicoctlをインストール
今回はやらないが、次はcalicoctlコマンドを入力できるようなプラグインをインストールする。

以下のページを参照予定。
https://docs.tigera.io/calico/latest/operations/calicoctl/install


## トラブルシュート

スムーズにいったので、今回はトラブルシュート無し。





























<!--
### シングルホストのKubernetesクラスタを作成

```
[実行コマンド]
sudo kubeadm reset

[結果]
[reset] Reading configuration from the cluster...
[reset] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0710 14:12:08.586491    1171 reset.go:124] [reset] Unable to fetch the kubeadm-config ConfigMap from cluster: failed to get config map: Get "https://10.0.2.15:6443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout=10s": dial tcp 10.0.2.15:6443: connect: connection refused
W0710 14:12:08.587238    1171 preflight.go:56] [reset] WARNING: Changes made to this host by 'kubeadm init' or 'kubeadm join' will be reverted.
[reset] Are you sure you want to proceed? [y/N]: y
[preflight] Running pre-flight checks
W0710 14:12:11.560961    1171 removeetcdmember.go:106] [reset] No kubeadm config, using etcd pod spec to get data directory
[reset] Deleted contents of the etcd data directory: /var/lib/etcd
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Deleting contents of directories: [/etc/kubernetes/manifests /var/lib/kubelet /etc/kubernetes/pki]
[reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/bootstrap-kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf]

The reset process does not clean CNI configuration. To do so, you must remove /etc/cni/net.d

The reset process does not reset or clean up iptables rules or IPVS tables.
If you wish to reset iptables, you must do so manually by using the "iptables" command.

If your cluster was setup to utilize IPVS, run ipvsadm --clear (or similar)
to reset your system's IPVS tables.

The reset process does not clean your kubeconfig files and you must remove them manually.
Please, check the contents of the $HOME/.kube/config file.
```

-->