etcd

本次测试集群为2各节点 一、 Etcd集群安装配置 安装包：etcd-3.3.11-2.el7.centos.x86_64.rpm 配置文件： #[Member] #ETCD_CORS="" ETCD_DATA_DIR="/var/lib/etcd/default.etcd" #ETCD_WAL_DIR="" ETCD_LISTEN_PEER_URLS="http://192.168.218.146:2380" ETCD_LISTEN_CLIENT_URLS="http://192.168.218.146:2379,http://127.0.0.1:2379" #ETCD_MAX_SNAPSHOTS="5" #ETCD_MAX_WALS="5" ETCD_NAME="k8s_002" #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

Watch key changes Applications can watch on a key or a range of keys to monitor for any updates. Here is the command to watch on key foo : $ etcdctl watch foo # in another terminal: etcdctl put foo bar PUT foo bar Here is the command to watch on key foo in hex format: $ etcdctl watch foo --hex # in another terminal: etcdctl put foo bar PUT \x66\x6f\x6f # Key \x62\x61\x72 # Value Here is the command to watch on a range key from foo to foo9 : $ etcdctl watch foo foo9 # in another terminal: etcdctl put foo bar PUT foo bar # in another terminal: etcdctl put foo1 bar1 PUT foo1 bar1 Here is the

Note that any key that was created using the v2 API will not be able to be queried via the v3 API. A v3 API etcdctl get of a v2 key will exit with 0 and no key data, this is the expected behaviour. export ETCDCTL_API=3 etcdctl version 1、etcdctl put foo bar 2、etcdctl put foo1 bar1 --lease=1234abcd（创建的租约ID） 3、etcdctl get foo 4、etcdctl get foo --hex 5、$ etcdctl get --prefix foo foo bar foo1 bar1 foo2 bar2 foo3 bar3 6、etcdctl get --prefix --limit=2 foo 7、版本，每次修订KEY，都会全局版本加一 Suppose an etcd cluster already has the following keys: foo = bar # revision = 2 foo1 = bar1 # revision = 3 foo = bar_new #

问题描述： Oct 13 20:01:08 c_3.50 systemd[1]: Started etcd. Oct 13 20:01:08 c_3.50 systemd[1]: Starting etcd... Oct 13 20:01:08 c_3.50 systemd[1]: etcd.service: main process exited, code=exited, status=203/EXEC //203不能执行 Oct 13 20:01:08 c_3.50 systemd[1]: Unit etcd.service entered failed state. Oct 13 20:01:08 c_3.50 systemd[1]: etcd.service failed. 问题解决： 01、查看exe执行在配置的路径中存在不 02、脚本是否加#!/bin/bash 注意：截图中的环境变量不允许${}，必须用实体替换或者写到EnvironmentFile中 Oct 13 20:15:08 c_3.50 systemd[1]: Started etcd. Oct 13 20:15:08 c_3.50 systemd[1]: Starting etcd... Oct 13 20:15:08 c_3.50 systemd[1]: etcd.service: main

部署k8s 1.13.1和istio1.3.1 部署k8s 前提条件 1，ETCD集群正常，并配置有证书 2，系统关闭交换分区，集群各节点配置好hostname和/etc/hosts文件 3，各个节点安装docker，本次使用17.03版本 解压kube1.13.1.tgz文件 # 部署所需的文件和脚本 链接：https://pan.baidu.com/s/1232DdKT3VOgQry88ON3tiQ 提取码：rz1c tar -zxvf kube1.13.1.tgz cd kube1.13.1.tgz 文件目录结构 ├── conf │ ├── dashboard │ ├── flannel │ ├── heapster │ ├── kubeadm.yaml │ └── wget ├── helm │ └── helm-v2.14.3-linux-amd64.tar.gz ├── images │ ├── coredns_1.2.6.tar │ ├── etcd_3.2.24.tar │ ├── flannel-0.11.tar │ ├── heapster-amd64_v1.5.4.tar │ ├── heapster-grafana-amd64_v5.0.4.tar │ ├── heapster-influxdb-amd64_v1.5.2.tar │ ├── helm

Kubernetes改变了我们所有人对计算平台的看法。我们同样也需要改变现代应用程序存储数据的方式。企业越来越多地依赖数字服务来接触客户，传统企业正在Kubernetes上重新部署它们的IT应用和服务。容器的可移植性和Kubernetes自动化的好处意味着在整个IT开发/测试和生产生命周期中我们可以更快、更可靠地交付应用程序。与此同时，企业必须认识到多云部署不仅仅是一种供应策略，而且还是一种对客户最合理的应用程序交付方式。 传统的存储行业还没有做好足够的工作来解决K8S的问题：容器可移植性、K8S自动化和多云交付。 Portworx企业版首先为K8S中大数据量的工作负载提供无缝的高可用性，无论这些工作负载是在本地系统还是在公共云中运行，都将提供无缝的高可用性。通过Portworx，开发团队可以获得集成调度程序、完整的数据生命周期管理，以及核心生产功能，如BYOK加密和云备份。 通过与那些已经把应用部署在主要的公有云平台或自有硬件平台上的优秀客户合作，Portworx已经掌握了完整的数据可迁移性、操作自动化、以及将含有大量数据的应用交付到多云部署中的真正能力。 可迁移性和易操作性 通过控制与K8S的集成方式，PX-Motion为大量数据型工作负载带来了充分的可迁移性。现在，类似Kubernetes为无状态工作负载带来的方便一样，我们在有状态工作负载上为客户的数据库、分析堆栈

Kubernetes改变了我们所有人对计算平台的看法。我们同样也需要改变现代应用程序存储数据的方式。企业越来越多地依赖数字服务来接触客户，传统企业正在Kubernetes上重新部署它们的IT应用和服务。容器的可移植性和Kubernetes自动化的好处意味着在整个IT开发/测试和生产生命周期中我们可以更快、更可靠地交付应用程序。与此同时，企业必须认识到多云部署不仅仅是一种供应策略，而且还是一种对客户最合理的应用程序交付方式。 传统的存储行业还没有做好足够的工作来解决K8S的问题：容器可移植性、K8S自动化和多云交付。 Portworx企业版首先为K8S中大数据量的工作负载提供无缝的高可用性，无论这些工作负载是在本地系统还是在公共云中运行，都将提供无缝的高可用性。通过Portworx，开发团队可以获得集成调度程序、完整的数据生命周期管理，以及核心生产功能，如BYOK加密和云备份。 通过与那些已经把应用部署在主要的公有云平台或自有硬件平台上的优秀客户合作，Portworx已经掌握了完整的数据可迁移性、操作自动化、以及将含有大量数据的应用交付到多云部署中的真正能力。 可迁移性和易操作性 通过控制与K8S的集成方式，PX-Motion为大量数据型工作负载带来了充分的可迁移性。现在，类似Kubernetes为无状态工作负载带来的方便一样，我们在有状态工作负载上为客户的数据库、分析堆栈

我们在实际生产中使用ETCD存储元数据，　起初集群规模不大的时候元数据信息不多没有发现什么问题。　随着集群规模越来越大问题逐渐暴露了 有些实际的配置还是需要在初始化的时候就研究确定 1. --auto-compaction-retention 由于ETCD数据存储多版本数据，随着写入的主键增加历史版本需要定时清理，　默认的历史数据是不会清理的，数据达到2G就不能写入，必须要清理压缩历史数据才能继续写入； 所以根据业务需求，在上生产环境之前就提前确定，历史数据多长时间压缩一次；　我们的生产环境现在升级后是默认一小时压缩一次数据。这样可以极大的保证集群稳定，减少内存和磁盘占用 2.--max-request-bytes etcd Raft消息最大字节数，ETCD默认该值为1.5M; 但是很多业务场景发现同步数据的时候1.5M完全没法满足要求，所以提前确定初始值很重要；　由于1.5M导致我们线上的业务无法写入元数据的问题， 我们紧急升级之后把该值修改为默认32M,但是官方推荐的是10M，大家可以根据业务情况自己调整 3.--quota-backend-bytes ETCDdb数据大小，默认是２G,当数据达到２G的时候就不允许写入，必须对历史数据进行压缩才能继续写入；　参加1里面说的，我们启动的时候就应该提前确定大小，官方推荐是8G,这里我们也使用8G的配置 ＃启动命令 /usr/bin

对于etcd api v3数据备份与恢复方法 # export ETCDCTL_API=3 # etcdctl --endpoints localhost:2379 snapshot save snapshot.db （备份） # etcdctl snapshot restore snapshot.db --name m3 --data-dir=/home/etcd_data （还原） 恢复后的文件需要修改权限为 etcd:etcd –name:重新指定一个数据目录，可以不指定，默认为 default.etcd –data-dir：指定数据目录 建议使用时不指定 name 但指定 data-dir，并将 data-dir 对应于 etcd 服务中配置的 data-dir 实践方法 单机备份 [root@k8s-master1 ~]# etcdctl --endpoints 127.0.0.1:2379 snapshot save snashot.db Snapshot saved at snashot.db [root@k8s-master1 ~]# ll -rw-r--r-- 1 root root 3756064 Apr 18 10:38 snashot.db [root@k8s-master1 ~]# 集群备份 [root@k8s-master1 ~]# etcdctl -

一、资源 官方文档 https://docs.projectcalico.org/v3.8/getting-started/kubernetes/installation/integration 二、Calico 部署注意事项 在使用 Calico 前当然最好撸一下官方文档，地址在这里 Calico 官方文档 ，其中部署前需要注意以下几点 官方文档中要求 kubelet 配置必须增加 --network-plugin=cni 选项 kube-proxy 组件必须采用 iptables proxy mode 模式(1.2 以后是默认模式) kubec-proxy 组件不能采用 --masquerade-all 启动，因为会与 Calico policy 冲突 NetworkPolicy API 只要需要 Kubernetes 1.3 以上 启用 RBAC 后需要设置对应的 RoleBinding，参考 官方文档 RBAC 部分 官方文档rbac https://docs.projectcalico.org/v2.3/getting-started/kubernetes/installation/hosted/ 三、系统要求 redhat、centos 7系列 默认情况下，NetworkManager不允许Calico管理接口。提前关闭NetworkManager Calico v3