了解Secret

为了存储与分发此类信息,Kubemetes提供了一种称为Secret的单独资源对象。Secret结构与ConfigMap类似,均是键/值对的映射。Secret的使用方法也与ConfigMap相同,可以

将Secret条目作为环境变量传递给容器

将Secret条目暴露为卷中的文件

Kubernetes通过仅仅将Secret分发到需要访问Secret的pod所在的机器节点来保障其安全性。另外,Secret只会存储在节点的内存中,永不写入物理存储,这样从节点上删除Secret时就不需要擦除磁盘了。

对于主节点本身(尤其是etcd),Secret通常以非加密形式存储,这就需要保障主节点的安全从而确保存储在Secret中的敏感数据的安全性。这种保障不仅仅是对etcd存储的安全性保障,同样包括防止未授权用户对API服务器的访问,这是因为任何人都能通过创建pod并将Secret挂载来获得此类敏感数据。

从Secret与ConfigMap中做出正确选择是势在必行的,选择依据相对简单:

·采用ConfigMap存储非敏感的文本配置数据。 采用Secret存储天生敏感的数据,通过键来引用,如果一个配置文件同时包含敏感与非敏感数据,该文件应该被存储在Secret中。

默认令牌Secret

对任意一个pod使用命令kubectl describe pod,输出往往包含如下信息:

1
2
3

default-token-6nw87:
Type:        Secret (a volume populated by a Secret)
SecretName:  default-token-6nw87

为何要更换CDN源

waline默认指定CDN为unpkg，虽然使用外部CDN，在一定程度上减少自身服务器的负担和带宽消耗，但CDN请求有时并不稳定，以导致网页加载时间过长甚至异常。如unpkg获取表情的库有时会无法访问，导致表情无法正常加载。故可以将从外部获取的CDN源下载至本地，统一使用站内的 Web 资源文件，以此来解决外部源不稳定的问题。

kube-proxy

和Service相关的任何事情都有每个节点上运行的kube-proxy进程处理。开始的时候，kube-proxy确实是一个proxy，等待连接，对每个进来的连接，连接到一个pod。这称为userspace（用户空间）代理模式。后来，性能更好的iptables代理模式取代了它。iptables代理模式目前是默认的模式。

每个Service有其自己稳定的IP地址和端口。客户端（通常为pod）通过连接该IP和端口使用服务。IP地址是虚拟的，没有被分配给任何网络接口，当数据包离开节点时也不会列为数据包的源或目的IP地址。Service的一个关键细节是，它们包含一个IP、端口对（或者针对多端口Service有多个IP、端口对），所以服务IP本身并不代表任何东西。这就是为什么你不能够ping它们。

本文只介绍iptables操作时的一些命令记录，对于iptables的其它概念如表，链，规则等不再赘述

在对iptables操作时需要尤其小心，对于防火墙添加的失误会造成程序间端口无法访问，导致业务受影响甚至停摆。

–APPEND -A

-A chain – 指定规则应该添加到的 chain 的名称。例如，使用 INPUT 将会把规则添加到默认的 INPUT（入站）链的末尾，而使用 OUTPUT 则会将规则添加到出站链的末尾。

1

iptables -A chain firewall-rule

-A 的意思是附加（append），并不是添加（add）的意思，它是将规则添加到已有的防火墙链（chain）的末尾的操作指令。这是特别重要的，因为规则在 iptables 中的位置非常重要，所以千万记住，-A 的意思是将规则添加到末尾，因为一般情况下 iptables 中最后一条规则是丢弃所有数据包。如果你已经有了一条这样的规则，使用 -A 参数添加的规则将会在丢弃规则之后，以至于新规则根本无法起作用。如果要插入到中间位置，需要用 -I 指令。