Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to deploy the Etcd cluster in the Kubernetes simulated production environment to build a high availability cluster. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Let's first talk about what etcd is and why kubernetes uses etcd, and then practice binary installation and deployment of etcd clusters.

I. brief introduction of Etcd components

Etcd is a highly available key storage system that quickly saves and provides access to critical data. It achieves reliable distributed coordination through distributed locking, leader election, and write barriers. Etcd clusters are designed to achieve high availability and persistent data storage and retrieval. It is mainly used for shared configuration and service discovery. It handles log replication through Raft consistency algorithm to ensure strong consistency. We can understand that it is a highly available service discovery repository with strong consistency. Etcd mainly solves the problem of data consistency in the distributed system, while the data in the distributed system is divided into control data and application data. The data type processed by etcd is control data, which can also be processed for a very small amount of application data.

Comparison of Etcd and Zookeeper:

Compared with deployment and maintenance, 1.zk is more complex to use, and the learning cost is higher. On the other hand, the deployment of etcd is simple, the use of HTTP as the interface is simple, and the use of Raft algorithm to ensure strong consistency makes it easy for users to understand.

2.zk is written in Java and requires jvm to run, which introduces a large number of dependencies and is relatively neutral.

3.zk develops slowly. On the other hand, etcd is used as the default storage system by K8s, and the upgrade iteration is fast.

4.etcd is more secure and supports SSL client security authentication.

2. The relationship between K8S and ETCD

Kubernetes officially uses etcd components as its own highly available and highly consistent service discovery repository by default. In kubernetes clusters, etcd is mainly used to configure data sharing and service discovery, and stores key data in etcd key storage, which makes the overall structure of kubernetes very simple. In kubernetes, because the data changes from time to time, new tasks are submitted, new Node is added, Node is down, the container is dead, and so on, the change of state data will be triggered. After the cluster state data changes, kube-scheduler and kube-controller-manager on the Master reschedule their work, and the result of their work scheduling is also data. Since changes in state data in the cluster need to be notified to each component in time, it just so happens that etcd has a good feature that you can call its api to listen to the data, and you will be notified when the data changes. With this feature, each component in kubernetes only needs to listen to the data in etcd to know what it should do. Kube-scheduler and kube-controller-manager only need to write the latest work schedule to etcd instead of notifying them one by one. In addition, etcd uses the raft protocol to achieve consistency, which is a distributed lock that can be used to make elections. If multiple kube-schdeuler are deployed in kubernetes, only one kube-scheduler can be working at a time. To ensure that only one kube-schduler is working, a leader is elected by etcd.

III. Binary deployment of etcd clusters

Official website address: https://etcd.io/

Document address: https://etcd.io/docs/

Project address: https://github.com/etcd-io/etcd

Download address: https://github.com/etcd-io/etcd/releases

1. Download the etcd binary installation package

This article uses the latest version 3.4.3 to download what is suitable for your hardware platform. This article uses: etcd-v3.4.3-linux-amd64.tar.gz

two。 Extract the etcd binary installation package

Tar-zxvf etcd-v3.4.3-linux-amd64.tar.gz

3. Install the binary program

Mkdir-p / work/etcd/ {cfg,bin,dat,run,wal}

Copy the etcd and etcdctl files to the / work/etcd/bin/ directory

Create a soft connection:

Ln-s / work/etcd/bin/etcd / usr/local/bin/etcd

Ln-s / work/etcd/bin/etcdctl / usr/local/bin/etcdctl

4. Write registration system service files

Vi / usr/lib/systemd/system/etcd.service is as follows:

[Unit] Description=etcdDocumentation= https://github.com/etcd-io/etcdConflicts=etcd.serviceAfter=network.targetAfter=network-online.targetWants=network-online.target[Service]Type=notifyRestart=alwaysRestartSec=5sLimitNOFILE=40000TimeoutStartSec=0WorkingDirectory=/work/etcd/run/ExecStart=/work/etcd/bin/etcd-- config-file=/work/etcd/cfg/etcd.yml [Install] WantedBy=multi-user.target

5. Generate the certificate required by the Etcd service

Prepare the certificate generation tool

Curl-L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64-o. / cfssl

Curl-L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64-o. / cfssljson

Curl-L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64-o. / cfssl-certinfo

Note: this article is installed in a simulated intranet environment, so the / usr/local/bin is uploaded to the machine after the download is completed.

Create a global certificate catalog mkdir cert

Create a certification authority (CA)

Cfssl print-defaults config > ca-etcd-config.json # default certificate production policy configuration template

Cfssl print-defaults csr > ca-etcd-csr.json # default csr request template

Modify the custom content of the template vi ca-etcd-config.json as follows:

{"signing": {"default": {"expiry": "87600h"}, "profiles": {"etcd": {"expiry": "87600h", "usages": ["signing", "key encipherment" "server auth", "client auth"]}

Note:

Ca-config.json: you can define multiple profiles to specify different expiration time, usage scenarios and other parameters. Later, you can specify a profile; to be used when signing the certificate. This instance has only one etcd.

Signing: indicates that the certificate can be used to sign other certificates; CA=TRUE in the generated ca-etcd.pem certificate

Server auth: indicates that client can use this CA to verify the certificate provided by server

Client auth: indicates that server can use this CA to verify the certificate provided by client

Modify the custom content of the template ca-etcd-csr.json as follows:

{"CN": "etcd", "key": {"algo": "rsa", "size": 2048}, "names": [{"C": "CN", "ST": "SH", "L": "BS", "O": "etcd", "OU": "System"}]}

Generate certificate (ca-etcd-key.pem) and secret key (ca-etcd.pem)

Cfssl gencert-initca ca-etcd-csr.json | cfssljson-bare ca-etcd

Create an etcd certificate signing request with the following vi etcd-csr.json:

{"CN": "etcd", "hosts": ["127.0.0.1", "192.168.100.111", "192.168.100.112", "192.168.100.113", "kube-cluster-master01", "kube-cluster-master02", "kube-cluster-master03"], "key": {"algo": "rsa", "size": 2048} "names": [{"C": "CN", "ST": "SH", "L": "BS", "O": "etcd", "OU": "System"}]}

Generate etcd certificate

Cfssl gencert-ca=/work/cert/ca-etcd.pem\

-ca-key=/work/cert/ca-etcd-key.pem\

-config=/work/cert/ca-etcd-config.json\

-profile=etcd etcd-csr.json | cfssljson-bare etcd

The generated file is as follows: etcd.csr etcd-key.pem etcd.pem copies three certificates to the other two nodes

6. Write Etcd service profile

Node 1 profile: vi / work/etcd/cfg/etcd.yml

Name: kube-etcd-node01wal-dir: / work/etcd/waldata-dir: / work/etcd/dat/default.etcdlisten-peer-urls: https://192.168.100.111:2380listen-client-urls: https://192.168.100.111:2379, Https://127.0.0.1:2379advertise-client-urls: https://192.168.100.111:2379initial-advertise-peer-urls: https://192.168.100.111:2380initial-cluster: kube-etcd-node01= https://192.168.100.111:2380,kube-etcd-node02=https://192.168.100.112:2380, Kube-etcd-node03= https://192.168.100.113:2380initial-cluster-token: kube-etcd-clusterinitial-cluster-state: newclient-transport-security: cert-file: / work/cert/etcd.pem key-file: / work/cert/etcd-key.pem client-cert-auth: false trusted-ca-file: / work/cert/ca-etcd.pem auto-tls: falsepeer-transport-security: cert-file: / work/cert/etcd.pem key-file: / work/cert/etcd-key.pem client-cert-auth: false trusted-ca-file: / work/cert/ca-etcd.pem auto-tls: falsedebug: falselogger: zaplog-outputs: [stderr]

Node 2 profile: vim / work/etcd/cfg/etcd.yml

Name: kube-etcd-node02wal-dir: / work/etcd/waldata-dir: / work/etcd/dat/default.etcdlisten-peer-urls: https://192.168.100.112:2380listen-client-urls: https://192.168.100.112:2379, Https://127.0.0.1:2379advertise-client-urls: https://192.168.100.112:2379initial-advertise-peer-urls: https://192.168.100.112:2380initial-cluster: kube-etcd-node01= https://192.168.100.111:2380,kube-etcd-node02=https://192.168.100.112:2380, Kube-etcd-node03= https://192.168.100.113:2380initial-cluster-token: kube-etcd-clusterinitial-cluster-state: newclient-transport-security: cert-file: / work/cert/etcd.pem key-file: / work/cert/etcd-key.pem client-cert-auth: false trusted-ca-file: / work/cert/ca-etcd.pem auto-tls: falsepeer-transport-security: cert-file: / work/cert/etcd.pem key-file: / work/cert/etcd-key.pem client-cert-auth: false trusted-ca-file: / work/cert/ca-etcd.pem auto-tls: falsedebug: falselogger: zaplog-outputs: [stderr]

Node 3 profile: vi / work/etcd/cfg/etcd.conf

Name: kube-etcd-node03wal-dir: / work/etcd/waldata-dir: / work/etcd/dat/default.etcdlisten-peer-urls: https://192.168.100.113:2380listen-client-urls: https://192.168.100.113:2379, Https://127.0.0.1:2379advertise-client-urls: https://192.168.100.113:2379initial-advertise-peer-urls: https://192.168.100.113:2380initial-cluster: kube-etcd-node01= https://192.168.100.111:2380,kube-etcd-node02=https://192.168.100.112:2380, Kube-etcd-node03= https://192.168.100.113:2380initial-cluster-token: kube-etcd-clusterinitial-cluster-state: newclient-transport-security: cert-file: / work/cert/etcd.pem key-file: / work/cert/etcd-key.pem client-cert-auth: false trusted-ca-file: / work/cert/ca-etcd.pem auto-tls: falsepeer-transport-security: cert-file: / work/cert/etcd.pem key-file: / work/cert/etcd-key.pem client-cert-auth: false trusted-ca-file: / work/cert/ca-etcd.pem auto-tls: falsedebug: falselogger: zaplog-outputs: [stderr]

7. Start the ETCD service

After the above steps are completed on all three nodes, do the following on each of the three nodes:

Systemctl daemon-reload

Systemctl enable etcd

Systemctl start etcd

8. Verify the ETCD service

Etcdctl-cacert=/work/cert/ca-etcd.pem\-cert=/work/cert/etcd.pem\-key=/work/cert/etcd-key.pem\-endpoints= https://192.168.100.111:2379,https://192.168.100.112:2379,https://192.168.100.113:2379 endpoint health

Etcdctl-- write-out=table\-- cacert=/work/cert/ca-etcd.pem\-- cert=/work/cert/etcd.pem\-- key=/work/cert/etcd-key.pem\-endpoints= https://192.168.100.111:2379,https://192.168.100.112:2379,https://192.168.100.113:2379 endpoint status

Etcdctl-- write-out=table\-- cacert=/work/cert/ca-etcd.pem\-- cert=/work/cert/etcd.pem\-- key=/work/cert/etcd-key.pem\-endpoints= https://192.168.100.111:2379,https://192.168.100.112:2379,https://192.168.100.113:2379 member list

This is how the Etcd cluster in the Kubernetes simulation production environment shared by the editor is deployed. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.