Kubernetes中的Secret资源可以用来存储密码、Token、秘钥等敏感数据。 将这些敏感信息保存在Secret中，相对于暴露到Pod、镜像中更加的安全和灵活。 1.Kubernetes Secret的类型 Kubernetes内置了三种类型的Secret： 1.1 Service Account Secret 为了能从Pod内部访问Kubernetes API，Kubernetes提供了Service Account资源。 Service Account会自动创建和挂载访问Kubernetes API的Secret，会挂载到Pod的 /var/run/secrets/kubernetes.io/serviceaccount目录中。 关于这种类型的Secret我们这里先不展开。
环境准备 机器(操作系统 CentOS) 192.168.61.30 c0 - admin-node, deploy-node 192.168.61.31 c1 - mon 192.168.61.32 c2 - osd.1 192.168.61.33 c3 - osd.2 配置各个节点的host文件： 192.168.61.31 c0 192.168.61.31 c1 192.168.61.32 c2 192.168.61.33 c3 管理节点c0上配置Ceph yum源 /etc/yum.repos.d/ceph.repo [ceph-noarch] name=Ceph noarch packages baseurl=https://download.ceph.com/rpm-jewel/el7/noarch enabled=1 priority=2 gpgcheck=1 gpgkey=https://download.ceph.com/keys/release.asc 更新软件库并安装 ceph-deploy
Ceph简介 Ceph是一个分布式存储系统，可以提供块存储RBD(Rados Block Device），对象存储RADOSGW(Rados Grateway)、文件系统存储(Ceph Filesystem)。 Ceph消除了对系统单一中心节点的依赖，实现了无中心结构的设计思想。
Docker 1.13新功能 Docker 1.13在去年年底发布，是一个重要的版本。以下是Top 10新增功能: 正式支持服务栈: docker stack 正式支持插件: docker plugin 添加在Swarm集群环境下对密码、密钥管理的secret管理服务docker secret 增加docker system命令 可以直接使用docker-compose.yml进行服务部署 添加docker service滚动升级出现故障后回滚的功能 增加强制再发布选项docker service update --force 允许docker service create映射宿主端口，而不是边界负载均衡网络端口 允许docker run炼乳制定的swarm mode的overlay网络 解决中国GFW墙掉docker-engine apt/yum源的问题 Docker 1.13安装 官方的安装文档在内容也做了更新。
系统启动可以分为以下六个阶段：BIOS, MBR, GRUB, Kernel, Init, Runlevel linux-boot-process BIOS BIOS(基本输入输出系统),是计算机启动时加载的第一个软件。 计算机在通电后首先由BIOS对自身的硬件环境进行自检，这就是POST(Power On Self Test开机自检)，这个过程主要是硬件环境自检，例如检查CPU, 内存, 主板等设备是否有故障存在。
JSON作为一种在不同平台间的数据交换格式，Go的标准包encoding/json中实现了对json的编码(marshal)和解码(unmarshal)功能。 json.Marshal json.Marshal函数实现Json的编码： 如果给定的值不等于nil并且实现了json.Marshaler接口，调用json.Marshaler的MarshalJSON方法完成编码 如果没有实现json.Marshaler接口，而是实现了encoding.TextMarshaler,将调用其MarshalText完成编码 否则将按照下面的默认情况进行编码： bool 编码为 JSON boolean 整形,浮点型等数值 编码为 JSON number string 编码为 JSON string array和slice编码为JSON array, []byte作为例外会被编码成base64 string map[string]interface{}编码为JSON object struct编码为JSON object(只适用struct的可导出字段) nil编码为JSON null json tag定制struct编码 json:"-"忽略字段
Kubernetes和EFK 我们使用Kubernetes作为微服务架构的基础，在我们的系统中每个微服务都有多个副本，每个副本的数量以及所在的Node都是可变的。因此对于日志需要集中化管理，在使用Kubernetes之前，我们的系统使用ELK(Elasticsearch+Logstash+Kibana)实现日志的聚集、查询和展现。由于Kubernetes推荐使用Fluentd,所以我们尝试使用EFK(Elasticsearch+Fluentd+Kibana)作为我们的日志集中管理组件。
Kubernetes对于无状态服务的支持已经十分成熟，有状态服务需要保存状态，Kubernetes提供了Volume和Persistent Volume用于服务的状态保存。 很多有状态服务都是以集群形式部署的，因此在在Kubernetes上部署有状态服务时还需要考虑集群管理的需求。针对这个需求Kubernetes提供了StatefulSet(在Kubernetes 1.5之前是PetSet)。
Kubernetes提供了三种级别的客户端认证方式： HTTPS证书认证，是基于CA根证书签名的双向数字证书认证方式，是最严格的认证 HTTP Token认证，通过Token识别每个合法的用户 HTTP Basic认证 HTTP Token认证和Http Basic认证是相对简单的认证方式，Kubernetes的各组件与Api Server的通信方式仍然是HTTPS，但不再使用CA数字证书。
PV和PVC的概念 Kubernetes的Persistent Volume是对存储的抽象，这个抽象包含两个资源： 持久化卷 PersistentVolume，后边简称PV 持久卷申请PersistentVolumeClaim，后边简称PVC PV是集群中的一块网络存储，也是Kubernetes集群的一种资源。 Pod的Volume与PV的区别是：Volume的生命周期和Pod相同，Pod被删除时，Volume和保存在Volume中的数据就被删除了；对于PV，即使挂载PV的Pod被删除了，PV仍然存在，PV上的数据也还在。