mirrors/kubernetes-the-hard-way
1
0
Fork 0
mirror of https://github.com/kelseyhightower/kubernetes-the-hard-way.git synced 2025-12-15 17:28:58 +03:00
Code Issues Projects Releases Wiki Activity

Update spelling

Browse Source
This commit is contained in:
rsavchuk
2023-06-08 22:25:56 +02:00
parent 1b6b7be592
commit 0d2e3d93d1
9 changed files with 200 additions and 166 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
docs/04-etcd.md
View File

@@ -1,36 +1,41 @@
# ETCD
At this point we already know that we can run pods even withour API server. But current aproach is not very confortable to use, to create pod we need to place some manifest in some place. It is not very comfortable to manage. Now we will start our jorney of configuring "real" (more real than current, because current doesn't look like kubernetes at all) kubernetes. And of course we need to start with the storage.
At this point, we already know that we can run pods even without an API server. To create a pod we need to place some manifest in some place. It is not very comfortable to manage. Now we will start configuring "real" (more real than current, because current doesn't look like kubernetes at all) kubernetes cluster.
![image](./img/04_cluster_architecture_etcd.png "Kubelet")
For kubernetes (at least for original one if I can say so) we need to configura database called [etcd](https://etcd.io/).
For kubernetes (at least for the original one if I can say so) we need to configure a database called [etcd](https://etcd.io/).
>etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node.
Our etcd will be configured as single node database with authentication (by useage of client cert file).
Our etcd will be configured as a single node database with authentication.
So, lets start.
So, let's start.
As I already said, communication with our etcd cluster will be secured, it means that we need to generate some keys, to encrypt all the trafic.
To do so, we need to download tools which may help us to generate certificates
## certificates
We will configure etcd to authenticate users by the certificate file used during communication.
To do so, we need to generate some certs.
We will create certificate files using cfssl and cfssljson tools (that should be installed before we start)
First of all, we will download the tools mentioned
```bash
wget -q --show-progress --https-only --timestamping \
https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 \
https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssljson_1.4.1_linux_amd64
```
And install
And install them
```bash
{
mv cfssl_1.4.1_linux_amd64 cfssl
mv cfssljson_1.4.1_linux_amd64 cfssljson
chmod +x cfssl cfssljson
sudo mv cfssl cfssljson /usr/local/bin/
mv cfssl_1.4.1_linux_amd64 cfssl
mv cfssljson_1.4.1_linux_amd64 cfssljson
chmod +x cfssl cfssljson
sudo mv cfssl cfssljson /usr/local/bin/
}
```
After the tools installed successfully, we need to generate ca certificate.
After the tools are installed successfully, we need to generate ca certificate.
A ca (Certificate Authority) certificate, also known as a root certificate or a trusted root certificate, is a digital certificate that is used to verify the authenticity of other certificates.
```bash
@@ -125,21 +130,7 @@ kubernetes-key.pem
kubernetes.pem
```
Now, we have all required certificates, so, lets download etcd
```bash
wget -q --show-progress --https-only --timestamping \
"https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-amd64.tar.gz"
```
After donload complete, we can move etcd binaries to proper folders
```bash
{
tar -xvf etcd-v3.4.15-linux-amd64.tar.gz
sudo mv etcd-v3.4.15-linux-amd64/etcd* /usr/local/bin/
}
```
Now, we can start wioth the configurations of the etcd service. First of all, we need to discribute previuosly generated certificates to the proper folder
And distribute certificate files created
```bash
{
sudo mkdir -p /etc/etcd /var/lib/etcd
@@ -150,7 +141,23 @@ Now, we can start wioth the configurations of the etcd service. First of all, we
}
```
Create etcd service configuration file
## configure
Now, we have all the required certificates, so, let's download etcd
```bash
wget -q --show-progress --https-only --timestamping \
"https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-amd64.tar.gz"
```
After the download is complete, we can move etcd binaries to the proper folders
```bash
{
tar -xvf etcd-v3.4.15-linux-amd64.tar.gz
sudo mv etcd-v3.4.15-linux-amd64/etcd* /usr/local/bin/
}
```
Now, we can configure etcd service
```bash
cat <<EOF | sudo tee /etc/systemd/system/etcd.service
[Unit]
@@ -186,12 +193,12 @@ Configuration options specified:
- advertise-client-urls - specifies the network addresses that the etcd server advertises to clients for connecting to the server
- data-dir - directory where etcd stores its data, including the key-value pairs in the etcd key-value store, snapshots, and transaction logs
And finally we need to run our etcd service
And finally, we need to run our etcd service
```bash
{
sudo systemctl daemon-reload
sudo systemctl enable etcd
sudo systemctl start etcd
sudo systemctl daemon-reload
sudo systemctl enable etcd
sudo systemctl start etcd
}
```
@@ -200,7 +207,7 @@ To ensure that our service successfully started, run
systemctl status etcd
```
The output should be similar to
Output:
```
● etcd.service - etcd
Loaded: loaded (/etc/systemd/system/etcd.service; enabled; vendor preset: enabled)
@@ -214,7 +221,9 @@ The output should be similar to
...
```
Now, when etcd is up and running, we can check wheather we can communicate with it
## verify
When etcd is up and running, we can check whether we can communicate with it
```
sudo ETCDCTL_API=3 etcdctl member list \
--endpoints=https://127.0.0.1:2379 \
@@ -228,6 +237,6 @@ Output:
8e9e05c52164694d, started, etcd, http://localhost:2380, https://127.0.0.1:2379, false
```
As you can see, to communicate with our etcd service, we specified cert and key file, this the the same file we used to configure etcd, it is only to simplity our deployment, in real life, we can use different certificate which is signed by the same ca file.
As you can see, to communicate with the etcd service, we specified a cert and key file, this is the same file we used to configure etcd, it is only to simplify our deployment, in real life, we can use a different certificate which is signed by the same ca file.
Next: [Api Server](./05-apiserver.md)