云原生|kubernetes|etcd集群详细介绍+安装部署+调优(二)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
日志服务 SLS,月写入数据量 50GB 1个月
简介: 云原生|kubernetes|etcd集群详细介绍+安装部署+调优

二、部署etcd集群


1、下载etcd安装包

wget https://github.com/etcd-io/etcd/releases/download/v3.3.10/etcd-v3.3.10-linux-amd64.tar.gz
tar zxf etcd-v3.3.10-linux-amd64.tar.gz
cp  etcd-v3.3.10-linux-amd64/etcd* /opt/etcd/bin/

2、创建etcd的工作目录,也就是数据存放目录

mkdir /opt/etcd/data

3、创建etcd启动脚本文件(修改对应etcd主机名称和ip,比如,在192.168.217.19上,IP都是19,name是etcd-1,那么,在20服务器上,这里的IP就都是20,name是etcd-2)

cat > /etc/systemd/system/etcd.service << EOF
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/coreos
[Service]
Type=notify
WorkingDirectory=/opt/kubernetes/etcd/
ExecStart=/opt/kubernetes/bin/etcd \
  --name etcd-1 \
  --cert-file=/opt/etcd/ssl/etcd.pem \
  --key-file=/opt/etcd/ssl/etcd-key.pem \
  --peer-cert-file=/opt/etcd/ssl/etcd.pem \
  --peer-key-file=/opt/etcd/ssl/etcd-key.pem \
  --trusted-ca-file=/opt/etcd/ssl/ca.pem \
  --peer-trusted-ca-file=/opt/etcd/ssl/etcd/ca.pem \
  --initial-advertise-peer-urls https://192.168.217.19:2380 \
  --listen-peer-urls https://192.168.217.19:2380 \
  --listen-client-urls https://192.168.217.19:2379,http://127.0.0.1:2379 \
  --advertise-client-urls https://192.168.217.19:2379 \
  --initial-cluster-token etcd-cluster-0 \
  --initial-cluster etcd1=https://192.168.217.19:2380,etcd2=https://192.168.217.20:2380,etcd3=https://192.168.217.21:2380 \
  --initial-cluster-state new \
  --data-dir=/opt/kubernetes/etcd
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
EOF
为了保证通信安全,需要指定 etcd 的公私钥(cert-file和key-file)、Peers 通信的公私钥和 CA 证书(peer-cert-file、peer-key-file、peer-trusted-ca-file)、客户端的CA证书(trusted-ca-file); 
创建etcd.pem 证书时使用的 etcd-csr.json 文件的 hosts 字段包含所有 etcd 节点的IP,否则证书校验会出错;
–initial-cluster-state 值为 new 时,–name 的参数值必须位于 –initial-cluster 列表中.

4、启动etcd服务并且设置开机自启动

systemctl daemon-reload
systemctl start etcd.service
systemctl status etcd.service
systemctl enable etcd.service

最先启动的 etcd 进程会卡住一段时间,等待其它节点上的 etcd 进程加入集群,为正常现象。

5、验证etcd集群状态,以及查看leader,在任何一个etcd节点执行

[root@k8s-master1 etcd]# etcdctl --ca-file=/opt/etcd/ssl/ca.pem --cert-file=/opt/etcd/ssl/etcd.pem --key-file=/opt/etcd/ssl/etcd-key.pem cluster-health
member 8b7aa04311a7389f is healthy: got healthy result from https://192.168.217.19:2379
member 9b7dcd0eef5c1758 is healthy: got healthy result from https://192.168.217.20:2379
member f617b05c8dbf5231 is healthy: got healthy result from https://192.168.217.21:2379
cluster is healthy
[root@k8s-master1 etcd]# etcdctl --ca-file=/opt/etcd/ssl/etcd/ca.pem --cert-file=/opt/etcd/ssl/etcd.pem --key-file=/opt/etcd/ssl/etcd-key.pem member list
8b7aa04311a7389f: name=etcd-2 peerURLs=https://192.168.217.20:2380 clientURLs=https://192.168.217.19:2379 isLeader=false
9b7dcd0eef5c1758: name=etcd-3 peerURLs=https://192.168.217.21:2380 clientURLs=https://192.168.217.20:2379 isLeader=true
f617b05c8dbf5231: name=etcd-1 peerURLs=https://192.168.217.19:2380 clientURLs=https://192.168.217.21:2379 isLeader=false

附1  etcdctl的 常用子命令:


  • version: 查看版本
  • member list: 查看节点状态,learner 情况
  • endpoint status: 节点状态,leader 情况
  • endpoint health: 健康状态与耗时
  • alarm list: 查看警告,如存储满时会切换为只读,产生 alarm
  • alarm disarm:清除所有警告
  • set app demo: 写入
  • get app: 获取
  • update app demo1:更新
  • rm app: 删除
  • mkdir demo 创建文件夹
  • rmdir dir 删除文件夹
  • backup 备份
  • compaction: 压缩
  • defrag:整理碎片
  • watch key 监测 key 变化
  • get / –prefix –keys-only: 查看所有 key

etcd集群调优:


ETCD作为kubernetes集群后端存储的分布式键值数据库,保存整个集群的状态信息,因此,对于etcd的备份和优化显得至关重要。etcd 使用 Raft 一致性算法来在成员之间复制请求并达成一致。一致性性能,特别是提交延迟,受限于两个物理约束:网络 IO 延迟和磁盘 IO 延迟,因此,调优也主要是针对这两个方面。

通常的etcd的参数设置可以在两个地方修改,一个是etcd的启动脚本,一个是etcd的配置文件,建议所有的参数都放置到etcd的配置文件内。

一个包含所有的参数的etcd配置文件是这样的;

[root@etcd1 etcd]# cat /etc/etcd/etcd.conf
#[Member]
#ETCD_CORS=""
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
#ETCD_WAL_DIR=""
#ETCD_LISTEN_PEER_URLS="http://localhost:2380"
ETCD_LISTEN_CLIENT_URLS="http://localhost:2379"
#ETCD_MAX_SNAPSHOTS="5"
#ETCD_MAX_WALS="5"
ETCD_NAME="default"
#ETCD_SNAPSHOT_COUNT="100000"
#ETCD_HEARTBEAT_INTERVAL="100"
#ETCD_ELECTION_TIMEOUT="1000"
#ETCD_QUOTA_BACKEND_BYTES="0"
#ETCD_MAX_REQUEST_BYTES="1572864"
#ETCD_GRPC_KEEPALIVE_MIN_TIME="5s"
#ETCD_GRPC_KEEPALIVE_INTERVAL="2h0m0s"
#ETCD_GRPC_KEEPALIVE_TIMEOUT="20s"
#
#[Clustering]
#ETCD_INITIAL_ADVERTISE_PEER_URLS="http://localhost:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"
#ETCD_DISCOVERY=""
#ETCD_DISCOVERY_FALLBACK="proxy"
#ETCD_DISCOVERY_PROXY=""
#ETCD_DISCOVERY_SRV=""
#ETCD_INITIAL_CLUSTER="default=http://localhost:2380"
#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
#ETCD_INITIAL_CLUSTER_STATE="new"
#ETCD_STRICT_RECONFIG_CHECK="true"
#ETCD_ENABLE_V2="true"
#
#[Proxy]
#ETCD_PROXY="off"
#ETCD_PROXY_FAILURE_WAIT="5000"
#ETCD_PROXY_REFRESH_INTERVAL="30000"
#ETCD_PROXY_DIAL_TIMEOUT="1000"
#ETCD_PROXY_WRITE_TIMEOUT="5000"
#ETCD_PROXY_READ_TIMEOUT="0"
#
#[Security]
#ETCD_CERT_FILE=""
#ETCD_KEY_FILE=""
#ETCD_CLIENT_CERT_AUTH="false"
#ETCD_TRUSTED_CA_FILE=""
#ETCD_AUTO_TLS="false"
#ETCD_PEER_CERT_FILE=""
#ETCD_PEER_KEY_FILE=""
#ETCD_PEER_CLIENT_CERT_AUTH="false"
#ETCD_PEER_TRUSTED_CA_FILE=""
#ETCD_PEER_AUTO_TLS="false"
#
#[Logging]
#ETCD_DEBUG="false"
#ETCD_LOG_PACKAGE_LEVELS=""
#ETCD_LOG_OUTPUT="default"
#
#[Unsafe]
#ETCD_FORCE_NEW_CLUSTER="false"
#
#[Version]
#ETCD_VERSION="false"
#ETCD_AUTO_COMPACTION_RETENTION="0"
#
#[Profiling]
#ETCD_ENABLE_PPROF="false"
#ETCD_METRICS="basic"
#
#[Auth]
#ETCD_AUTH_TOKEN="simple"

磁盘IO


  • –quota-backend-bytes: DB 数据大小,比如 10G,50G。
  • –auto-compaction-retention: 自动压缩,默认为 0 不开启,k8s中 apiserver会开启这个压缩,5 分钟一次。如果你的 etcd 还被其他人使用,这里也可以设置下时间
  • --auto-compaction-mode=periodic 周期性压缩

Etcd 的存储配额可保证集群操作的可靠性。如果没有存储配额,那么 Etcd 的性能就会因为存储空间的持续增长而严重下降,甚至有耗完集群磁盘空间导致不可预测集群行为的风险。一旦其中一个节点的后台数据库的存储空间超出了存储配额,Etcd 就会触发集群范围的告警,并将集群置于接受读 key 和删除 key 的维护模式。只有在释放足够的空间和消除后端数据库的碎片之后,清除存储配额告警,集群才能恢复正常操作。

启动 etcd 时。–quota-backend-bytes 默认为 2G,2G 一般情况下是不够用的

可以通过 etcdctl endpoint status 命令来查看当前的存储使用量,例如:

DB SIZE就是现在的etcd使用的存储空间大小,目前为2.6MB,三个节点都一样大小,如果不一样,那才是真的有问题了。

[root@master1 ssl]# etcd_search endpoint status -w table
+-----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|          ENDPOINT           |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+-----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://192.168.217.19:2379 |  97c1c1003e0d4bf |   3.4.9 |  2.6 MB |     false |      false |       194 |     388655 |             388655 |        |
| https://192.168.217.21:2379 | f5b8cb45a0dcf520 |   3.4.9 |  2.6 MB |      true |      false |       194 |     388655 |             388655 |        |
| https://192.168.217.20:2379 | ef2fee107aafca91 |   3.4.9 |  2.6 MB |     false |      false |       194 |     388655 |             388655 |        |
+-----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

在 3.4 版本中,etcd 的存储容量得到了提高,你可以设置 100G 的存储空间,当然并不是越大越好,key 存储过多性能也会变差,根据集群规模适当调整。

OK了,那么现在这些参数在哪里设置呢?在etcd的启动脚本内设置或者在etcd的配置文件内设置。例如:

在启动脚本内,相关配置是这些:

    --max-request-bytes=$((10*1024*1024)) \ #请求的最大字节数,默认一个key为1.5M,官方推荐最大为10M
    --quota-backend-bytes=$((8*1024*1024*1024)) #磁盘配额,也就是etcd的使用空间限制,这里是8G
    --auto-compaction-retention=1 \  #首次压缩周期为1小时,后续压缩周期为当前值的10%,也就是每隔6分钟压缩一次
    --auto-compaction-mode=periodic \ #周期性压缩

重启etcd服务后,可以在etcd服务状态内直接看到压缩日志,确实是5分钟一压缩:

[root@master1 ~]# systemctl status etcd -l
● etcd.service - Etcd Server
   Loaded: loaded (/usr/lib/systemd/system/etcd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2022-10-31 11:19:49 CST; 2h 23min ago
 Main PID: 1020 (etcd)
   Memory: 443.5M
   CGroup: /system.slice/etcd.service
           └─1020 /opt/etcd/bin/etcd --cert-file=/opt/etcd/ssl/server.pem --key-file=/opt/etcd/ssl/server-key.pem --peer-cert-file=/opt/etcd/ssl/server.pem --peer-key-file=/opt/etcd/ssl/server-key.pem --trusted-ca-file=/opt/etcd/ssl/ca.pem --peer-trusted-ca-file=/opt/etcd/ssl/ca.pem
Oct 31 13:19:53 master1 etcd[1020]: store.index: compact 303965
Oct 31 13:19:53 master1 etcd[1020]: finished scheduled compaction at 303965 (took 1.390764ms)
Oct 31 13:24:53 master1 etcd[1020]: store.index: compact 304473
Oct 31 13:24:53 master1 etcd[1020]: finished scheduled compaction at 304473 (took 1.833708ms)
Oct 31 13:29:53 master1 etcd[1020]: store.index: compact 304980
Oct 31 13:29:53 master1 etcd[1020]: finished scheduled compaction at 304980 (took 1.51143ms)
Oct 31 13:34:53 master1 etcd[1020]: store.index: compact 305488
Oct 31 13:34:53 master1 etcd[1020]: finished scheduled compaction at 305488 (took 1.188379ms)
Oct 31 13:39:53 master1 etcd[1020]: store.index: compact 305995
Oct 31 13:39:53 master1 etcd[1020]: finished scheduled compaction at 305995 (took 1.205064ms)

在配置文件内,相关配置是这两个:

#ETCD_QUOTA_BACKEND_BYTES=$((8*1024*1024*1024)) #默认数值是0,表示2G磁盘配额
#ETCD_MAX_REQUEST_BYTES=$((10*1024*1024)) #服务器将接受的最大客户端请求大小(以字节为单位),这里设置的是10M

以上是软件层面的关于etcd读写方面的优化,其实也就这么两个地方,那么,硬件层面自然是需要使用好的硬盘了,因为etcd对于磁盘写入延迟非常敏感,所以对于负载较重的集群,etcd一定要使用local SSD或者高性能云盘。可以使用fio测量磁盘实际顺序 IOPS,测试命令如下:

[root@master1 ~]# fio -filename=/dev/sda1  -ioengine=sync -direct=1 -rw=write -bs=8k -size=10G -numjobs=8 -runtime=100 -allow_mounted_write=1 -group_reporting -name=fio_test
fio_test: (g=0): rw=write, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=sync, iodepth=1
...
fio-3.7
Starting 8 processes
Jobs: 8 (f=8): [W(8)][100.0%][r=0KiB/s,w=47.2MiB/s][r=0,w=6037 IOPS][eta 00m:00s]
fio_test: (groupid=0, jobs=8): err= 0: pid=22064: Mon Oct 31 14:36:39 2022
  write: IOPS=6011, BW=46.0MiB/s (49.2MB/s)(4697MiB/100006msec)
    clat (usec): min=200, max=86655, avg=1326.13, stdev=2106.37
     lat (usec): min=201, max=86655, avg=1326.74, stdev=2106.40
    clat percentiles (usec):
     |  1.00th=[  537],  5.00th=[  742], 10.00th=[  791], 20.00th=[  840],
     | 30.00th=[  873], 40.00th=[  898], 50.00th=[  922], 60.00th=[  963],
     | 70.00th=[ 1004], 80.00th=[ 1139], 90.00th=[ 1893], 95.00th=[ 2114],
     | 99.00th=[12780], 99.50th=[13960], 99.90th=[24249], 99.95th=[37487],
     | 99.99th=[52691]
   bw (  KiB/s): min=  464, max= 8848, per=12.50%, avg=6011.00, stdev=2497.40, samples=1598
   iops        : min=   58, max= 1106, avg=751.33, stdev=312.23, samples=1598
  lat (usec)   : 250=0.01%, 500=0.66%, 750=4.71%, 1000=63.48%
  lat (msec)   : 2=24.27%, 4=4.65%, 10=0.38%, 20=1.62%, 50=0.21%
  lat (msec)   : 100=0.01%
  cpu          : usr=0.65%, sys=3.28%, ctx=603442, majf=0, minf=79
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,601235,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
  WRITE: bw=46.0MiB/s (49.2MB/s), 46.0MiB/s-46.0MiB/s (49.2MB/s-49.2MB/s), io=4697MiB (4925MB), run=100006-100006msec
Disk stats (read/write):
  sda: ios=0/598863, merge=0/2942, ticks=0/756213, in_queue=756214, util=99.46%

由于etcd必须将数据持久保存到磁盘日志文件中,因此来自其他进程的磁盘活动可能会导致增加写入时间,结果导致etcd请求超时和临时leader丢失。因此可以给etcd进程更高的磁盘优先级,使etcd服务可以稳定地与这些进程一起运行,一般使用命令ionice命令:

先查询出etcd的pid,然后调整io优先级为best-effort的最高优先等级。

[root@master3 ~]# pgrep etcd
15963
[root@master3 ~]# ionice -c 2 -n 0 -p 15963
[root@master3 ~]# ionice -p `pgrep etcd`
best-effort: prio 0

附2 IO调度策略:


ionice将磁盘IO调度分为三类:

ilde:空闲磁盘调度,该调度策略是在当前系统没有其他进程需要进行磁盘IO时,才能进行磁盘;因此该策略对当前系统的影响基本为0;当然,该调度策略不能带有任何优先级参数;目前,普通用户是可以使用该调度策略(自从内核2.6.25开始)。

Best effort:是缺省的磁盘IO调度策略;(1)该调度策略可以指定优先级参数(范围是0~7,数值越小,优先级越高);(2)针对处于同一优先级的程序将采round-robin方式;(3)对于best effort调度策略,8个优先级等级可以说明在给定的一个调度窗口中时间片的大小。(4)目前,普调用户(非root用户)是可以使用该调度策略。(5)在内核2.6.26之前,没有设置IO优先级的进程会使用“none”作为调度策略,但是这种策略使得进程看起来像是采用了best effort调度策略,因为其优先级是通过关于cpu nice有关的公式计算得到的:io_priority = (cpu_nice + 20) / 5。(6)在内核2.6.26之后,如果当前系统使用的是CFQ调度器,那么如果进程没有设置IO优先级级别,将采用与内核2.6.26之前版本同样的方式,推到出io优先级级别。

Real time:实时调度策略,如果设置了该磁盘IO调度策略,则立即访问磁盘,不管系统中其他进程是否有IO。因此使用实时调度策略,需要注意的是,该访问策略可能会使得其他进程处于等待状态。

ionice的参数说明:

-c class :class表示调度策略,其中0 for none, 1 for real time, 2 for best-effort, 3 for idle。

-n classdata:classdata表示IO优先级级别,对于best effort和real time,classdata可以设置为0~7,0是最高优先级,7是最低优先级。

-p pid:指定要查看或设置的进程号或者线程号,如果没有指定pid参数,ionice will run the listed program with the given parameters。

-t :忽视设置优先级时产生的错误。

网络层面的调优:


etcd 的一致性协议依赖两个时间参数。

  • –heartbeat-interval:心跳间隔,心跳间隔,即 leader 通知member 并保证自己 leader 地位的心跳,默认是 100ms(单位毫秒),这个应该设置为节点间的 RTT 时间。
  • –election-timeout:选举超时时间,即 member 多久没有收到 leader 的回应,就开始自己竞选 leader,默认超时时间为 1s(单位毫秒)

如果心跳间隔太短,则 etcd 将发送不必要的消息,从而增加 CPU 和网络资源的使用。另一方面,心跳间隔过长会导致选举超时。较高的选举超时时间需要更长的时间来检测领导者失败。测量往返时间(RTT)的最简单方法是使用PING,例如我的etcd集群ping值在500毫秒左右,那么,–heartbeat-interval应该是500,而不是默认的100,–election-timeout的值应该为心跳的5倍,因此是2500比较好。

[root@master1 ~]# ping 192.168.217.20
PING 192.168.217.20 (192.168.217.20) 56(84) bytes of data.
64 bytes from 192.168.217.20: icmp_seq=1 ttl=64 time=0.488 ms
64 bytes from 192.168.217.20: icmp_seq=2 ttl=64 time=0.416 ms
64 bytes from 192.168.217.20: icmp_seq=3 ttl=64 time=0.459 ms

因此,启动脚本文件应该是这样的:

cat  /usr/lib/systemd/system/etcd.service

[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
Type=notify
EnvironmentFile=/opt/etcd/cfg/etcd.conf
ExecStart=/opt/etcd/bin/etcd \
        --cert-file=/opt/etcd/ssl/server.pem \
        --key-file=/opt/etcd/ssl/server-key.pem \
        --peer-cert-file=/opt/etcd/ssl/server.pem \
        --peer-key-file=/opt/etcd/ssl/server-key.pem \
        --trusted-ca-file=/opt/etcd/ssl/ca.pem \
        --peer-trusted-ca-file=/opt/etcd/ssl/ca.pem
        --wal-dir=/var/lib/etcd \ #快照日志路径
        --snapshot-count=50000 \ #最大快照次数,指定有多少事务被提交时,触发截取快照保存到磁盘,释放wal日志,默认值100000
        --auto-compaction-retention=1 \  #首次压缩周期为1小时,后续压缩周期为当前值的10%,也就是每隔6分钟压缩一次
        --auto-compaction-mode=periodic \ #周期性压缩
        --max-request-bytes=$((10*1024*1024)) \ #请求的最大字节数,默认一个key为1.5M,官方推荐最大为10M
        --quota-backend-bytes=$((8*1024*1024*1024)) \
        --heartbeat-interval="500" \ #心跳检测500毫秒
        --election-timeout="1000"   #选举超时1000毫秒,也就是1秒
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

总结:


以上为etcd集群需要调优的参数,大体是7个参数,调整方向为磁盘io和网络负载。

未完待续

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
10天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
42 2
|
6天前
|
Kubernetes Cloud Native 开发者
云原生入门:Kubernetes的简易指南
【10月更文挑战第41天】本文将带你进入云原生的世界,特别是Kubernetes——一个强大的容器编排平台。我们将一起探索它的基本概念和操作,让你能够轻松管理和部署应用。无论你是新手还是有经验的开发者,这篇文章都能让你对Kubernetes有更深入的理解。
|
10天前
|
Kubernetes 监控 负载均衡
深入云原生:Kubernetes 集群部署与管理实践
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其弹性、可扩展性成为企业IT架构的首选。本文将引导你了解如何部署和管理一个Kubernetes集群,包括环境准备、安装步骤和日常维护技巧。我们将通过实际代码示例,探索云原生世界的秘密,并分享如何高效运用这一技术以适应快速变化的业务需求。
36 1
|
14天前
|
运维 Kubernetes Cloud Native
Kubernetes云原生架构深度解析与实践指南####
本文深入探讨了Kubernetes作为领先的云原生应用编排平台,其设计理念、核心组件及高级特性。通过剖析Kubernetes的工作原理,结合具体案例分析,为读者呈现如何在实际项目中高效部署、管理和扩展容器化应用的策略与技巧。文章还涵盖了服务发现、负载均衡、配置管理、自动化伸缩等关键议题,旨在帮助开发者和运维人员掌握利用Kubernetes构建健壮、可伸缩的云原生生态系统的能力。 ####
|
15天前
|
存储 运维 Kubernetes
云原生之旅:Kubernetes的弹性与可扩展性探索
【10月更文挑战第32天】在云计算的浪潮中,云原生技术以其独特的魅力成为开发者的新宠。本文将深入探讨Kubernetes如何通过其弹性和可扩展性,助力应用在复杂环境中稳健运行。我们将从基础架构出发,逐步揭示Kubernetes集群管理、服务发现、存储机制及自动扩缩容等核心功能,旨在为读者呈现一个全景式的云原生平台视图。
27 1
|
20天前
|
Kubernetes 负载均衡 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第27天】Kubernetes(简称K8s)是云原生应用的核心容器编排平台,提供自动化、扩展和管理容器化应用的能力。本文介绍Kubernetes的基本概念、安装配置、核心组件(如Pod和Deployment)、服务发现与负载均衡、网络配置及安全性挑战,帮助读者理解和实践Kubernetes在容器编排中的应用。
58 4
|
21天前
|
Kubernetes 监控 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第26天】随着云计算技术的发展,容器化成为现代应用部署的核心趋势。Kubernetes(K8s)作为容器编排领域的佼佼者,以其强大的可扩展性和自动化能力,为开发者提供了高效管理和部署容器化应用的平台。本文将详细介绍Kubernetes的基本概念、核心组件、实践过程及面临的挑战,帮助读者更好地理解和应用这一技术。
56 3
|
15天前
|
监控 Cloud Native 微服务
云端漫步:探索云原生应用的构建与部署
【10月更文挑战第32天】在数字时代的浪潮中,云原生技术如同一艘航船,承载着企业的梦想驶向未知的海洋。本文将带你领略云原生应用的魅力,从基础概念到实战操作,我们将一步步揭开云原生的神秘面纱,体验它如何简化开发、加速部署,并提升系统的可扩展性与可靠性。让我们一起启航,探索云原生的世界!
|
Kubernetes Shell Docker
Kubernetes安装部署演示介绍-(一)
序 这是差不多2年前我整理的一篇纯手工搭建Kubernetes的文档,里边涉及的软件版本相对偏低一些,但对一些初学者来说应该依然具有一定的借鉴意义。 环境介绍: OS:Linux redhat721 3.
1274 0
|
Kubernetes Shell 容器
Kubernetes安装部署演示介绍-(二)
四、安装k8s 1、安装 使用的是k8s 1.2.4版本。 将kubernetes.tar.gz 上传主机,并解压。 tar -xzvf kubernetes.tar.gz cd kubernetes/server/ tar -xzvf kubernetes-server-linux-amd64.
1126 0
下一篇
无影云桌面