小知识记录：第XII篇

1、冯诺依曼体系结构
组成部分：控制器、运算器、存储器、输入设备、输出设备
(1)采用存储程序方式，指令和数据不加区别混合存储在同一个存储器中，数据和程序在内存中是没有区别的,它们都是内存中的数据,当EIP指针指向哪 CPU就加载那段内存中的数据,如果是不正确的指令格式,CPU就会发生错误中断. 在现在CPU的保护模式中,每个内存段都有其描述符,这个描述符记录着这个内存段的访问权限(可读,可写,可执行).这就变相的指定了哪些内存中存储的是指令哪些是数据）
指令和数据都可以送到运算器进行运算，即由指令组成的程序是可以修改的。
(2)存储器是按地址访问的线性编址的一维结构，每个单元的位数是固定的。
(3)指令由操作码和地址码组成。操作码指明本指令的操作类型,地址码指明操作数和地址。操作数本身无数据类型的标志，它的数据类型由操作码确定。
(4)通过执行指令直接发出控制信号控制计算机的操作。指令在存储器中按其执行顺序存放，由指令计数器指明要执行的指令所在的单元地址。指令计数器只有一个，一般按顺序递增，但执行顺序可按运算结果或当时的外界条件而改变。
(5)以运算器为中心，I/O设备与存储器间的数据传送都要经过运算器。
(6)数据以二进制表示。

2、堆栈
概念：
堆栈是一个特定的存储区或寄存器，它的一端是固定的，另一端是浮动的 [1] 。堆这个存储区存入的数据，是一种特殊的数据结构。所有的数据存入或取出，只能在浮动的一端（称栈顶）进行，严格按照“先进后出”的原则存取，位于其中间的元素，必须在其栈上部（后进栈者）诸元素逐个移出后才能取出。在内存储器（随机存储器）中开辟一个区域作为堆栈，叫软件堆栈；用寄存器构成的堆栈，叫硬件堆栈。
区别：
栈（操作系统）：由操作系统自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。
堆（操作系统）： 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS（操作系统）回收，分配方式倒是类似于链表。
栈使用的是一级缓存， 他们通常都是被调用时处于存储空间中，调用完毕立即释放。
堆则是存放在二级缓存中，生命周期由虚拟机的垃圾回收算法来决定（并不是一旦成为孤儿对象就能被回收）。所以调用这些对象的速度要相对来得低一些。
堆（数据结构）：堆可以被看成是一棵树，如：堆排序。
栈（数据结构）：一种先进后出的数据结构。

3、docker配置文件docker-daemon.json详解
docker-daemon.json各配置详解
{
“api-cors-header”:"", ——————在引擎API中设置CORS标头
“authorization-plugins”:[], ——————要加载的授权插件
“bridge”:"", ————将容器附加到网桥
“cgroup-parent”:"", ——————为所有容器设置父cgroup
“cluster-store”:"", ——————分布式存储后端的URL
“cluster-store-opts”:{}, ————————设置集群存储选项（默认map []）
“cluster-advertise”:"", ————————要通告的地址或接口名称
“debug”: true, ————————启用调试模式，启用后，可以看到很多的启动信息。默认false
“default-gateway”:"", ——————容器默认网关IPv4地址
“default-gateway-v6”:"", ——————容器默认网关IPv6地址
“default-runtime”:“runc”, ————————容器的默认OCI运行时（默认为“ runc”）
“default-ulimits”:{}, ——————容器的默认ulimit（默认[]）
“dns”: [“192.168.1.1”], ——————设定容器DNS的地址，在容器的 /etc/resolv.conf文件中可查看。
“dns-opts”: [], ————————容器 /etc/resolv.conf 文件，其他设置
“dns-search”: [], ————————设定容器的搜索域，当设定搜索域为 .example.com 时，在搜索一个名为 host 的 主机时，DNS不仅搜索host，还会搜
索host.example.com 。 注意：如果不设置， Docker 会默认用主机上的 /etc/resolv.conf 来配置容器。
“exec-opts”: [], ————————运行时执行选项
“exec-root”:"", ————————执行状态文件的根目录（默认为’/var/run/docker‘）
“fixed-cidr”:"", ————————固定IP的IPv4子网
“fixed-cidr-v6”:"", ————————固定IP的IPv6子网
“data-root”:"/var/lib/docker", ————-Docker运行时使用的根路径，默认/var/lib/docker
“group”: “”, ——————UNIX套接字的组（默认为“docker”）
“hosts”: [], ——————设置容器hosts
“icc”: false, ——————启用容器间通信（默认为true）
“ip”:“0.0.0.0”, ————————绑定容器端口时的默认IP（默认0.0.0.0）
“iptables”: false, ———————启用iptables规则添加（默认为true）
“ipv6”: false, ——————启用IPv6网络
“ip-forward”: false, ————————默认true, 启用 net.ipv4.ip_forward ,进入容器后使用 sysctl -a | grepnet.ipv4.ip_forward 查看
“ip-masq”:false, ——————启用IP伪装（默认为true）
“labels”:[“nodeName=node-121”], ————————docker主机的标签，很实用的功能,例如定义：–label nodeName=host-121
“live-restore”: true, ——————在容器仍在运行时启用docker的实时还原
“log-driver”:"", ——————容器日志的默认驱动程序（默认为“ json-file”）
“log-level”:"", ——————设置日志记录级别（“调试”，“信息”，“警告”，“错误”，“致命”）（默认为“信息”）
“max-concurrent-downloads”:3, ——————设置每个请求的最大并发下载量（默认为3）
“max-concurrent-uploads”:5, ——————设置每次推送的最大同时上传数（默认为5）
“mtu”: 0, ——————设置容器网络MTU
“oom-score-adjust”:-500, ——————设置守护程序的oom_score_adj（默认值为-500）
“pidfile”: “”, ——————Docker守护进程的PID文件
“raw-logs”: false, ——————全时间戳机制
“selinux-enabled”: false, ——————默认 false，启用selinux支持
“storage-driver”:"", ——————要使用的存储驱动程序
“swarm-default-advertise-addr”:"", ——————设置默认地址或群集广告地址的接口
“tls”: true, ————————默认 false, 启动TLS认证开关
“tlscacert”: “”, ——————默认 ~/.docker/ca.pem，通过CA认证过的的certificate文件路径
“tlscert”: “”, ————————默认 ~/.docker/cert.pem ，TLS的certificate文件路径
“tlskey”: “”, ————————默认~/.docker/key.pem，TLS的key文件路径
“tlsverify”: true, ————————默认false，使用TLS并做后台进程与客户端通讯的验证
“userland-proxy”:false, ——————使用userland代理进行环回流量（默认为true）
“userns-remap”:"", ————————用户名称空间的用户/组设置
“bip”:“192.168.88.0/22”, ——————————指定网桥IP
“registry-mirrors”: [“https://192.498.89.232:89”], ————————设置镜像加速
“insecure-registries”: [“120.123.122.123:12312”], ———————设置私有仓库地址可以设为http
“storage-opts”: [
“overlay2.override_kernel_check=true”,
“overlay2.size=15G”
], ————————存储驱动程序选项
“log-opts”: {
“max-file”: “3”,
“max-size”: “10m”,
}, ————————容器默认日志驱动程序选项
“iptables”: false ————————启用iptables规则添加（默认为true）
}

4、no matches for kind "ReplicaSet" in version "extensions/v1beta1"
各api版本说明
alpha
* 该软件可能包含错误。启用一个功能可能会导致bug
* 随时可能会丢弃对该功能的支持，恕不另行通知

beta
* 软件经过很好的测试。启用功能被认为是安全的。
* 默认情况下功能是开启的
* 细节可能会改变，但功能在后续版本不会被删除

stable
* 该版本名称命名方式：vX这里X是一个整数
* 稳定版本、放心使用
* 将出现在后续发布的软件版本中

v1
Kubernetes API的稳定版本，包含很多核心对象：pod、service等

apps/v1beta2
在kubernetes1.8版本中，新增加了apps/v1beta2的概念，apps/v1beta1同理
DaemonSet，Deployment，ReplicaSet 和 StatefulSet的当时版本迁入apps/v1beta2，兼容原有的extensions/v1beta1

apps/v1
在kubernetes1.9版本中，引入apps/v1，deployment等资源从extensions/v1beta1, apps/v1beta1 和 apps/v1beta2迁入apps/v1，原来的v1beta1等被废弃。

apps/v1代表：包含一些通用的应用层的api组合，如：Deployments, RollingUpdates, and ReplicaSets

batch/v1
代表job相关的api组合
在kubernetes1.8版本中，新增了batch/v1beta1，后CronJob 已经迁移到了 batch/v1beta1，然后再迁入batch/v1

autoscaling/v1
代表自动扩缩容的api组合，kubernetes1.8版本中引入。
这个组合中后续的alpha 和 beta版本将支持基于memory使用量、其他监控指标进行扩缩容

extensions/v1beta1
deployment等资源在1.6版本时放在这个版本中，后迁入到apps/v1beta2,再到apps/v1中统一管理

certificates.k8s.io/v1beta1
安全认证相关的api组合

authentication.k8s.io/v1
资源鉴权相关的api组合

5、GET和POST请求
--1、GET、POST请求都是基于TCP/IP协议栈；
--2、GET将数据放到请求的URL中，POST将请求数据放到body中；
--3、GET请求的URL有长度限制，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。POST可以支持更大量的请求数据，腾讯云API限制为10M（在v3版本签名鉴权模式下）；
--4、GET进行一次请求，POST一般为两次请求（URL一次，body一次，两个tcp数据包）；
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
注：并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

6、k8s证书更新---可参考
----------------------------------------------------------
在使用Kubernetes 集群时有个大坑，一些证书的有效期是一年，官方考虑到安全性希望开发者在一年内，能及时更新Kubernetes的版本。更新之后有效期会再次刷新。
Kubernetes版本 1.14.2
Ubuntu版本 16.04
1. 原因证书过期问题
```bash
certificate has expired or is not yet valid.
```
2.原因应该是 /etc/kubernetes/admin.conf 也就是 $HOME/.kube/config 过期的原因。在终端操作命令使用的认证证书，根据/etc/kubernetes/pki/ca.crt生成的。所以这个也需要更新.
```bash
kubectl get pods
`You must be logged in to the server (Unauthorized)`
```

### 1、各个证书过期时间
```bash
/etc/kubernetes/pki/apiserver.crt #1年有效期
/etc/kubernetes/pki/front-proxy-ca.crt #10年有效期
/etc/kubernetes/pki/ca.crt #10年有效期
/etc/kubernetes/pki/apiserver-etcd-client.crt #1年有效期
/etc/kubernetes/pki/front-proxy-client.crt #1年有效期
/etc/kubernetes/pki/etcd/server.crt #1年有效期
/etc/kubernetes/pki/etcd/ca.crt #10年有效期
/etc/kubernetes/pki/etcd/peer.crt #1年有效期
/etc/kubernetes/pki/etcd/healthcheck-client.crt #1年有效期
/etc/kubernetes/pki/apiserver-kubelet-client.crt #1年有效期
```
### 2、获取集群的配置文件
1. 可以使用当时 kubeadm init --config=kubeadm-config.yaml 时的配置文件。
2. 使用命令获取
```bash
kubeadm config view > /tmp/kubeadm-config.yaml
```
### 3、备份
1. 备份原有证书
```bash
cp -rp /etc/kubernetes /etc/kubernetes.bak
```
2. 备份etcd数据目录
```bash
cp -r /var/lib/etcd /var/lib/etcd.bak
```
3. 备份配置信息
```bash
mkdir /etc/kubernetes/conf-backup
mv /etc/kubernetes/admin.conf kubelet.conf scheduler.conf controller-manager.conf conf-backup/
```

### 4、更新证书
```bash
kubeadm alpha certs renew all --config=/tmp/kubeadm-config.yaml
```

### 5、更新配置文件
admin.conf 是给kubectl操作时用的,根据car.crt生成 所以需要更新
```bash
kubeadm init phase kubeconfig all --config /tmp/kubeadm-config.yaml
```
### 6、在三台Master上执行重启kube-apiserver,kube-controller,kube-scheduler,etcd这4个容器，使其生效
```bash
docker ps |grep -E 'k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler|k8s_etcd_etcd' | awk -F ' ' '{print $1}' |xargs docker restart
# 重启kubelet
systemctl restart kubelet
```
### 7、更换kubectl 操作的配置信息
```bash
rm -rf $HOME/.kube
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
### 8、查看各个证书过期时间
```bash
#查看pod
kubectl get pods
# 查看各证书过期时间
for item in `find /etc/kubernetes/pki -maxdepth 2 -name "*.crt"`;do openssl x509 -in $item -text -noout| grep Not;echo ======================$item===============;done
```

[1]: https://www.cnblogs.com/uglyliu/p/12361546.html
----------------------------------------------------------

7、腾讯云API签名V3拼接过程
https://cloud.tencent.com/document/api/214/30671#1.-.E6.8B.BC.E6.8E.A5.E8.A7.84.E8.8C.83.E8.AF.B7.E6.B1.82.E4.B8.B2
###1、拼接规范请求串
CanonicalRequest =
HTTPRequestMethod + '\n' +
CanonicalURI + '\n' +
CanonicalQueryString + '\n' +
CanonicalHeaders + '\n' +
SignedHeaders + '\n' +
HashedRequestPayload
注：HashedRequestPayload为请求内容，如：{"Limit": 1, "Filters": [{"Values": ["\u672a\u547d\u540d"], "Name": "instance-name"}]}的sha256哈希加密的十六进制的小写值，其他字段见文档解释
示例：
POST
/
content-type:application/json; charset=utf-8
host:cvm.tencentcloudapi.com
content-type;host
35e9c5b0e3ae67532d3c9f17ead6c90222632e5b1ff7f6e89887f1398934f064

###2、拼接待签名字符串
StringToSign =
Algorithm + \n +
RequestTimestamp + \n +
CredentialScope + \n +
HashedCanonicalRequest
注：HashedCanonicalRequest为上面“拼接规范请求串”的sha256加密值
示例：
TC3-HMAC-SHA256
1551113065
2019-02-25/cvm/tc3_request
5ffe6a04c0664d6b969fab9a13bdab201d63ee709638e2749d62a09ca18d7031

###3、计算签名
SecretKey = "Gu5t9xGARNpq86cd98joQYCN3*******"
SecretDate = HMAC_SHA256("TC3" + SecretKey, Date)
SecretService = HMAC_SHA256(SecretDate, Service)
SecretSigning = HMAC_SHA256(SecretService, "tc3_request")
注：
##SecretDate为
----
TC3 + \n +
SecretKey + \n +
Date
----
这个的sha256加密值
##SecretService为
----
SecretDate + \n +
Service
----
这个的sha256加密值，SecretDate这个为上面加密的sha256
##SecretSigning为
----
SecretService + \n +
tc3_request
----
这个的sha256加密值，SecretService这个为上面加密的sha256
##计算签名：
Signature = HexEncode(HMAC_SHA256(SecretSigning, StringToSign))
注：Signature为SecretSigning, StringToSign的sha256加密值，如
----
SecretSigning + \n +
StringToSign
----
SecretSigning和StringToSign分别替换为上面计算的sha256值

###4、拼接 Authorization
Authorization =
Algorithm + ' ' +
'Credential=' + SecretId + '/' + CredentialScope + ', ' +
'SignedHeaders=' + SignedHeaders + ', ' +
'Signature=' + Signature
示例：
TC3-HMAC-SHA256 Credential=xxxxxxxxxxxxxxxxxxxxxxxx/2021-02-05/clb/tc3_request, SignedHeaders=content-type;host, Signature=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
注：分别对应为
Algorithm---TC3-HMAC-SHA256 （固定）
Credential---xxxxxxxxxxxxxxxxxxxxxxxx/2021-02-05/clb/tc3_request （秘钥id/日期/服务名称/tc3_request）tc3_request表示请求的服务和终止字符串（tc3_request
SignedHeaders---content-type;host
Signature---xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx （上面计算的签名值）

8、turbostat -v
turbostat --debug -i 10
turbostat统计X86 处理器的频率、空闲状态、电源状态、温度等状态。有两种方式调用该命令，第一个是提供command，这个统计CPU的信息直到命令完成。第二种方式移除相关的命令，这种方式每5秒钟展示统计信息。turbostat必须在root权限下调用。

一、turboastat可以用来查看CPU核心处在C1 C3 C6 C7状态下时间。
在CPU超线程的核心中，如果某个核心处于工作状态，会阻止该超线程的另一个核心进入比C1更加深入的省电模式。

二、turbostat可以查看CPU的温度信息。
CoreTmp：每个物理cpu核心的温度。
PkgTmp：每个物理CPU的温度。

三、turbostat查看CPU的忙碌状态。
AVG_MHz 执行周期数除以经过的时间
%Busy 处于“ C0”状态的时间百分比。
Bzy_MHz cpu繁忙时的平均时钟频率。 (in “c0” state).
TSC_MHz TSC在整个时间间隔内运行的平均MHz。TSC是一个64bit的寄存器，用来记录cpu的cycle个数。

四、查看能耗消耗位置
PkgWatt 整个CPU消耗的瓦特数。
CorWatt 核心消耗的瓦特数。
GFXWatt 图像部分消耗的瓦特数。
RAMWatt DRAM DIMMS 部分消耗的瓦特数。

五、查看RAPL信息
RAPL是Running Average Power Limit的缩写。
PKG_% cpu RAPL节流活动间隔的百分比。
RAM_% cpu RAPL节流在DRAM上处于活动状态的时间间隔的百分比。

9、k8s通过config修改配置文件后，实现服务自动更新，版本控制方式
kubectl patch deployment deploy-cm-volumete-test --patch '{"spec":{"template":{"metadata":{"annotations":{"version/config":"20210207"}}}}}'
#修改版本后会自动进行更新

10、Linux流量统计相关命令
iftop //iftop -h
nload //nload -d nload -m
https://www.cnblogs.com/zhangeamon/p/8310714.html
iptables //iptables -I OUTPUT -d 192.168.20.38 iptables -n -v -L -t filter -x
https://blog.csdn.net/li_wen01/article/details/93597936
sar –n DEV 1 2
cat /proc/net/dev
使用watch命令，配合ifconfig、more /proc/net/dev、cat /proc/net/dev来实时监控。比如执行 watch -n 1 "ifconfig eth0"
https://www.cnblogs.com/nmap/p/9427260.html
vnstat -d -i eth0 //vnstat -d -i etho(按天监控) vnstat -w -i eth0（实时监控） vnstat -m -i etho（按月监控）
https://jingyan.baidu.com/article/636f38bb9095d4d6b84610a5.html
ifstat
iptraf
https://www.linuxprobe.com/linux-io-network.html

11、网络黑产
https://baike.baidu.com/item/%E7%BD%91%E7%BB%9C%E9%BB%91%E4%BA%A7/22823089?fromtitle=%E9%BB%91%E4%BA%A7&fromid=24155660&fr=aladdin

12、K8S RBAC权限的创建绑定
#1、k8s不支持用户创建，通过取用证书的CN和O作为用户名和组名
例创建证书的json文件：
{
"CN": "devuser",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "Beijing",
"L": "Beijing",
"O": "k8s",
"OU": "System"
}
]
}

#2、下载证书生成工具
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl

wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo

chmod +x /usr/local/bin/cfssl*
cd /etc/kubernetes/ #cd到集群的ca证书目录，否则一下命令需要指明ca证书和秘钥的路径
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /root/devuser-csr.json |cfssljson -bare devuser

#3、设置集群参数
export KUBE_APISERVER="https://172.30.0.175:60002" #apiserver地址，端口号可能不一致，以实际使用为准
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ca.crt \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=devuser.kubeconfig

#4、设置客户端认证参数
kubectl config set-credentials devuser \
--client-certificate=/etc/kubernetes/devuser.pem \
--client-key=/etc/kubernetes/devuser-key.pem \
--embed-certs=true \
--kubeconfig=devuser.kubeconfig

#5、设置上下文参数
kubectl config set-context kubernetes \
--cluster=kubernetes \
--user=devuser \
--namespace=dev \
--kubeconfig=devuser.kubeconfig

#6、设置默认上下文
kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig
cp -f ./devuser.kubeconfig /root/.kube/config #如果为子账号，可以useradd创建，并cp config文件到子账号的家目录下.kube目录中，并授予子用户权限
kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev #将用户绑定到admin角色，当然这个角色也可以自行定义一个再绑定
注：以上devuser.kubeconfig也可以改名为config，指定配置文件切换时配置文件名称路径对应即可

13、k8s认证、鉴权和访问控制
###1、认证有三种方式
http token认证、http base认证（用户名+密码经过base64加密）、https证书认证（基于ca根证书签名的客户端认证方式）
目前最安全和常用的方式为https证书双向认证

###2、需要认证的组件
一般情况需要与apiserver进行交互的组件都需要进行认证，包括controller scheduler kube-proxy kubelet以及一些其他pod资源，例如：coreDNS、cAdvisor
注：controller scheduler两个组件，在只用过程中，一般和apiserver部署到同一台主机上，因此可以不用进行https认证，这样可以降低一点性能损耗，这两个组件一般直接通过apiserver的非安全端口访问，--insecure-bind-address=127.0.0.1
kubectl、kubelet、kube-proxy访问apiserver都需要证书进行https双向认证

###3、证书颁发
手动签发：通过k8s集群的根证书ca进行签发https证书
自动签发：kubelet首次访问apiserver时，使用token做认证，通过认证后，controller manager会为kubelet生成一个证书，以后的访问就用证书做认证
注：一般情况下，kubectl、kube-proxy为对应的手动签发

###4、kubeconfig
kubeconfig文件包含集群（CA证书、api server地址），客户端参数（上面生成的证书和私钥），集群context信息（集群名称、用户名）。kubernetes组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群

###5、ServiceAccount
pod中的容器访问apiserver。因为pod的创建、销毁是动态的，所以要为它手动生成证书就不可行。kubernetes使用ServiceAccount解决pod访问apiserver的认证问题

###6、Secret与SA的关系
kubernetes设计了一种资源对象叫做secret，分为两类。一种是用户ServiceAccount的service-account-token，另一种是用于保存用户自定义保密信息的Opaque。ServiceAccount中包含三部分：Token、ca.crt、namespace
--token是使用apiserver私钥签发的jwt。用于访问apiserver时，server端认证
--ca.crt根证书。用于client端验证apiserver发送的证书
--namespace标识这个service-account-token的作用域名空间
注：json web token（JWT），是为了在网络应用环境间传递声明而执行的一种基于json的开放标准（RFC 7519），该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（sso）场景。JWT的声明一般被用于在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其他业务逻辑所必须的声明信息，该token也可以直接被用于认证，也可被加密
kubectl get secret --all-namespaces
kubectl describe secret default-token-5gm9r --namespace-system
默认情况下，每个namespace都会有一个ServiceAccount，如果pod在创建时没有指定ServiceAccount,就会使用pod所属的namespace的ServiceAccount
<!--默认挂载目录：/run/secrets/kubernetes.io/serviceaccount/-->

###7、鉴权
在组件双方确认可以正常通行后，需要鉴权来决定哪些资源可以被访问。apiserver目前支持以下几
种授权策略（通过apiserver的启动参数--authorization-mode设置）
--AlwaysDeny: 表示拒绝所有的请求，一般用于测试
--AlwaysAllow: 允许接收所有请求，如果集群不需要授权流程，则可以采用该策略
--ABAC（Attribute-Based Access Control）: 基于属性的访问控制，表示使用用户配置的授权规>
则对用户请求进行匹配和控制
--Webhook: 通过调用外部REST服务对用户进行授权
RBAC（Role-Based Access Control）: 基于角色的访问控制，现行默认规则

###8、RBAC资源对象
role clusterrole rolebinding clusterrolebinding
注：clusterrole可以使用rolebinding，表示授予账号某一个namespace的权限
clusterrolebinding不可以绑定role，仅能绑定clusterrole，表示授予集群的权限

14、Kunbernetes-容器云应用的安装部署工具Helm
https://www.kubernetes.org.cn/4009.html
https://github.com/helm/helm/releases #安装包下载链接，最新版本取消了tiller组件

15、supervisor进程守护监控
https://www.cnblogs.com/toutou/p/supervisor.html

16、文件系统
一、文件系统层次分析
由上而下主要分为用户层、VFS层、文件系统层、缓存层、块设备层、磁盘驱动层、磁盘物理层
###用户层
最上面用户层就是我们日常使用的各种程序，需要的接口主要是文件的创建、删除、打开、关闭、写、读等。
###VFS层
我们知道Linux分为用户态和内核态，用户态请求硬件资源需要调用System Call通过内核态去实现。用户的这些文件相关操作都有对应的System Call函数接口，接口调用VFS对应的函数。
###文件系统层
不同的文件系统实现了VFS的这些函数，通过指针注册到VFS里面。所以，用户的操作通过VFS转到各种文件系统。文件系统把文件读写命令转化为对磁盘LBA的操作，起了一个翻译和磁盘管理的作用。
###缓存层
文件系统底下有缓存，Page Cache，加速性能。对磁盘LBA的写数据缓存到这里。
###块设备层
块设备接口Block Device是用来访问磁盘LBA的层级，读写命令组合之后插入到命令队列，磁盘的驱动从队列读命令执行。Linux设计了电梯算法等对很多LBA的读写进行优化排序，尽量把连续地址放在一起。
###磁盘驱动层
磁盘的驱动程序把对LBA的读写命令转化为各自的协议，比如变成ATA命令，SCSI命令，或者是自己硬件可以识别的自定义命令，发送给磁盘控制器。Host Based SSD甚至在块设备层和磁盘驱动层实现了FTL，变成对Flash芯片的操作。
###磁盘物理层
读写物理数据到磁盘介质。

二、文件系统构成元素
###引导块
为磁盘分区的第一个块，记录文件系统分区的一些信息，引导加载当前分区的程序和数据被保存在这个块中。一般占用2KB。
###超级块
超级块用于存储文件系统全局的配置参数(譬如：块大小，总的块数和inode数)和动态信息(譬如：当前空闲块数和inode数)，其处于文件系统开始位置的1k处，所占大小为1k。
为了系统的健壮性，最初每个块组都有超级块和组描述符表(以下将用GDT)的一个拷贝，但是当文件系统很大时，这样浪费了很多块(尤其是GDT占用的块多)，后来采用了一种稀疏的方式来存储这些拷贝，只有块组号是3, 5 ,7的幂的块组(譬如说1,3,5,7,9,25,49…)才备份这个拷贝。
通常情况下，只有主拷贝(第0块块组)的超级块信息被文件系统使用，其它拷贝只有在主拷贝被破坏的情况下才使用。
###块组描述符
GDT用于存储块组描述符，其占用一个或者多个数据块，具体取决于文件系统的大小。
它主要包含块位图，inode位图和inode表位置，当前空闲块数，inode数以及使用的目录数(用于平衡各个块组目录数)，具体定义可以参见ext3_fs.h文件中struct ext3_group_desc。
每个块组都对应这样一个描述符，目前该结构占用32个字节，因此对于块大小为4k的文件系统来说，每个块可以存储128个块组描述符。由于GDT对于定位文件系统的元数据非常重要，因此和超级块一样，也对其进行了备份。GDT在每个块组(如果有备份)中内容都是一样的，其所占块数也是相同的。
从上面的介绍可以看出块组中的元数据譬如块位图，inode位图,inode表其位置不是固定的，当然默认情况下，文件系统在创建时其位置在每个块组中都是一样的，如图2所示(假设按照稀疏方式存储，且n不是3,5,7的幂)
###块组
每个块组包含一个块位图块，一个 inode 位图块，一个或多个块用于描述 inode 表和用于存储文件数据的数据块，除此之外，还有可能包含超级块和所有块组描述符表(取决于块组号和文件系统创建时使用的参数)。下面将对这些元数据作一些简要介绍。
###块位图
块位图用于描述该块组所管理的块的分配状态。如果某个块对应的位未置位，那么代表该块未分配，可以用于存储数据；否则，代表该块已经用于存储数据或者该块不能够使用(譬如该块物理上不存在)。由于块位图仅占一个块，因此这也就决定了块组的大小。
###Inode位图
Inode位图用于描述该块组所管理的inode的分配状态。我们知道inode是用于描述文件的元数据，每个inode对应文件系统中唯一的一个号，如果inode位图中相应位置位，那么代表该inode已经分配出去；否则可以使用。由于其仅占用一个块，因此这也限制了一个块组中所能够使用的最大inode数量。
###Inode表
Inode表用于存储inode信息。它占用一个或多个块(为了有效的利用空间，多个inode存储在一个块中)，其大小取决于文件系统创建时的参数，由于inode位图的限制，决定了其最大所占用的空间。
以上这几个构成元素所处的磁盘块成为文件系统的元数据块，剩余的部分则用来存储真正的文件内容，称为数据块，而数据块其实也包含数据和目录。

三、操作系统是如何读取一个文件的（读取、操作）
###文件读取大概过程
1、根据文件所在目录的inode信息，找到目录文件对应数据块
2、根据文件名从数据块中找到对应的inode节点信息
3、从文件inode节点信息中找到文件内容所在数据块块号
4、读取数据块内容
###文件复制
1）拷贝文件：创建一个新的inode节点，并且拷贝数据块内容
###文件移动
2）剪切文件：同个分区里边mv，inode节点不变，只是更新目录文件对应数据块里边的文件名和inode对应关系；跨分区mv，则跟拷贝一个道理，需要创建新的inode，因为inode节点不同分区是不能共享的。
###软连接硬连接
3）软连接：创建软连接会创建一个新的inode节点，其对应数据块内容存储所链接的文件名信息，这样原文件即便删除了，重新建立一个同名的文件，软连接依然能够生效。
4)硬链接：创建硬链接，并不会新建inode节点，只是links加1，还有再目录文件对应数据块上增加一条文件名和inode对应关系记录；只有将硬链接和原文件都删除之后，文件才会真正删除，即links为0才真正删除。