k8s pod 安全 用户等-----3-2

kube-apiserver 存储服务的访问入口。数据保存在etcd 当中。

kubectl将数据提交给apiserver---->etcd

scheduler也是apiserver的客户端。kubectl 提交了一个新的pod 定义给apiserver.apiserver把etcd 的watch 机制。能够给监视相关资源的程序进行通知，而scheduler就像apiserver 注册监视每个没有pod 调度结果的。调度的结果也会通过apiserver 保存到etcd 当中。

controller manager 当中有很多controller,运行着controller loop

调度完成kubelet 负责加载pod 定义，并调用本地的docker 引擎运行为容器。kubelet 注册监听和自己pod的相关信息。并将成功与否相关信息进行保存。

scheduler: 负责调度，修改调度结果的字段

controller:负责当前状态，并且负责当前状态吻合用户期望状态。负责修改status 相关信息

kubelet :负责更新pod 当前状态信息

kube-proxy :负责svc相关信息

认证安全

认证   权限    行为

Adminssion control :

k8s 用户通过apiserver来完成资源操作的时候，三个步骤

1.身份校验

2.授权

3.如果是写的话，检查是否规范。

以插件的形式实现。以短路模式工作

而第三部不是以短路模式工作。

认证：客户端证书认证，密码,明文令牌，引导令牌。如果要证书认证，那么要精确到CN.  精确到人 。  认证通过后还要识别你是谁，所以不能使用同一客户端证书。

用户名密码在http 协议的首部进行传输。用户名和密码使用base64进行编码后通过header 

令牌：拿着尚方宝剑，我说我是谁你就要相信。

问题：每个节点都要建议单独发证，而且建议是两个。管理起来很是繁琐。 

在kubeapiserver 中内建了一个控制器，让一个节点加入时是没有证书的。apiserver为kubelet生成一个证书签署请求，并且通过自己的ca签署好并且发给他。（kubelet,kube-proxy 发起证书签署请求，生成一个csr）之后调自己信任的私有ca

以上的前提是引导令牌，拿着令牌接入。第一次见面时 用的。一般引导令牌有时效，一般24h 

kubectl 每次连apiserver都要证书是什么，私钥是什么。过于繁琐。

第一步部署apiserver后要求要复制一个文件，

[root@master ~]# cd /etc/kubernetes/
[root@master kubernetes]# ls
admin.conf  controller-manager.conf  kubelet.conf  manifests  pki  scheduler.conf  tmp
 

admin.conf 保存了证书的私钥，每次kubectl去认证都会携带。

scheduler.conf    认证文件，认证到特殊的集群上

ll ~/.kube/config   kubectl不指定默认加载这个配置文件
  [root@master .kube]# md5sum  ~/.kube/config
e925dcab8e08a244e64657d393c16f3a  /root/.kube/config
[root@master .kube]# md5sum /etc/kubernetes/
admin.conf               kubelet.conf             pki/                     tmp/
controller-manager.conf  manifests/               scheduler.conf
[root@master .kube]# md5sum /etc/kubernetes/admin.conf
e925dcab8e08a244e64657d393c16f3a  /etc/kubernetes/admin.conf

 这个用户名被识别为k8s 的管理员

用户类型：

pod也有一个默认有的令牌，能连入apiserver更新自己的信息的。

创建pod时，准入控制器自动为pod 赋予一个serviceaccount   name,自动将这个服务账号的令牌以存储卷的方式让当前pod所挂载。pod 中的容器中的守护进程需要连入apiserver 时就拿着这些信息去认证到apiserver 当中去。并获得应该获得的最小权限。

kubeconfig 由四部分组成。 1.用户列表   2.集群列表  3.上下文，用户和集群的组合关系   4.当前上下文

解析查看用户账号的相关信息

[root@master kubernetes]# kubectl --kubeconfig=/etc/kubernetes/admin.conf config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.0.0.110:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
 

------

自己也可以做账号，但是如果想认证到k8s 上去。可以使用1 证书认证    2令牌认证     3.密码认证

如果使用3必须启用账号密码文件

如果使用令牌，需要使用令牌文件。

还可以使用私有ca 往外签证书

k8s 信任的证书是谁呢？

[root@master kubernetes]# ll  /etc/kubernetes/pki/ca*
-rw-r--r-- 1 root root 1025 Sep 25 16:32 /etc/kubernetes/pki/ca.crt
-rw------- 1 root root 1675 Sep 25 16:32 /etc/kubernetes/pki/ca.key
 

CN代表用户名称，不用之前在k8s 存在，你说你是谁你就是谁。

k8s 有哪些地方需要证书？

 第一组：

etcd 是服务端，etcd 是apiserver的客户端

 对等证书，既是服务端又是客户端：peer cert   。etcd 各节点之间通信。

为每个节点发一个服务端证书----server cert

给api server 发一个客户端证书。叫做client cert.api-server 与etcd 通信时要拿着客户端证书认证到etcd .etcd 要通过etcd-ca 的证书校验是否允许通过。

1. etcd-ca 自己有一套（自签的）。2 etcd的peer cert    3. server 证书   4.api-server 客户端证书

第二组：

7个证书

第三组

案例：做一个普通用户，连入到k8s 上去

1.生成一个私钥：

[root@node1 pki]# openssl genrsa -out ilinux.key 2048
Generating RSA private key, 2048 bit long modulus
.........+++
.....................................+++
e is 65537 (0x10001)
 

2.生成一个证书签署请求，并且用可信任ca 进行签署。

openssl req -new -key ilinux.key -out ilinux.csr -subj "/CN=ilinux/O=kubeusers"

[root@master pki]# openssl  x509 -req -in ilinux.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out ilinux.crt -days 3650
Signature ok
subject=/CN=ilinux/O=kubeusers
Getting CA Private Key
 

3.建立一个kubeconfig 文件。certificate-authority 证书签署机构是谁。--embed-Certs  是不是要打包起来。 

 kubectl  config set-cluster -h

[root@master pki]#  kubectl config set-cluster mykube --server="https://10.0.0.110:6443"  --certificate-authority=/etc/kubernetes/pki/ca.crt--embed-Certs=true --kubeconfig=/tmp/ilinux.kubeconfig
Cluster "mykube" set.

4.指定用户

 kubectl config set-credentials ilinux --client-certificate=/etc/kubernetes/pki/ilinux.crt --client-key=/etc/kubernetes/pki/ilinux.key --username=ilinux --embed-certs=true --kubeconfig=/tmp/ilinux.kubeconfig
[root@master pki]# cat /tmp/ilinux.kubeconfig
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt--embed-Certs=true
    server: https://10.0.0.110:6443
  name: mykube
contexts: null
current-context: ""
kind: Config
preferences: {}
users:
- name: ilinux
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN0akNDQVo0Q0NRQzhZTnB3RXBlNm16QU5CZ2txaGtpRzl3MEJBUXNGQURBVk1STXdFUVlEVlFRREV3cHIKZFdKbGNtNWxkR1Z6TUI0WERUSXpNVEV3TXpBME5EQXlPRm9YRFRNek1UQXpNVEEwTkRBeU9Gb3dKVEVQTUEwRwpBMVVFQXd3R2FXeHBiblY0TVJJd0VBWURWUVFLREFscmRXSmxkWE5sY25Nd2dnRWlNQTBHQ1NxR1NJYjNEUUVCCkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDcy9Ma1d2OUp2c2pxTHluRVRGL01lMU53dVdXazQ5YzFxVExTbTVHazEKSW8wQXNYUGZCY0NCL1BWSWQ4dU1McHRWTXJTOVhQM0pKcmxiT3dNTC9lNzY1UGlMbWlqTitRMXhBK1lkd0o0aQpCTjE3VjA4RURTL3M0Q1R3Z3hLTzhNOXpzb3hKV2xjQWxiZy9FZDVxcE1NeHBaSVNydklNeVNMVDF5V0E0L09iCm15N0RlQnNqTW5ubm8vSGovaVhTTEFNT1BXT3hlYy9vYjRzWkpqUUcxcVNneGEyWmtiaXhHajlSNE1qQkpnRGEKak5ybFBiZW9DTzBkbGR6UU9pUFhvYmduUmZaeE02cUQ5dnkwaHFuMThGNi9SbkVaM2V6OURoYnNJaUN0TXlMdwpxZ1EwMGR2ZU9kc1MxUndHQ01zN2cwTlkrSmhCcmE0ZHo1bFRzZDkxaVVXWEFnTUJBQUV3RFFZSktvWklodmNOCkFRRUxCUUFEZ2dFQkFJK2tkMjRmekdCVzh5ZTVpcm0zK2JMWGlmYzhaaDZnVDdXcE5YUVh4Z3pGVFdIbEEvQksKditZcDhySE9qcVNGV1BzYzl2U1MvYkd0dlgyV3ZpRkozNGlUcHpmMTl5TldkOVN4MVMzenJta0NhR2dMNFQ4bApCb0dXRXQ4cEdzOWp1MURaWjhySFZOSnVXVm1Od1NhWVRwK2JheWVVOExvMXhyT0ttZG5SY1RUSkV0YlAyUHRVCmZpU3p5cUFyNlVibW5aT1lkOExMU2RSeXgvRlN6WVFLRTVwODc1TTZMWVhDNU9kVC8vT3VDcXVML3lGZkx3b3MKMnR2d2tuNEEwVms1a2k0M2JtWFFxZjBSbEdwUUh3Sm9QVEtYZjdVNGRwOXM2cmY4YU1IN21Nb1NBUVhjNi9HLwpBZkFkMSszdnZ6ekVsNU40L243Tk5PQ3B6TyszSlVRQU9VVT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBclB5NUZyL1NiN0k2aThweEV4ZnpIdFRjTGxscE9QWE5ha3kwcHVScE5TS05BTEZ6CjN3WEFnZnoxU0hmTGpDNmJWVEswdlZ6OXlTYTVXenNEQy8zdSt1VDRpNW9vemZrTmNRUG1IY0NlSWdUZGUxZFAKQkEwdjdPQWs4SU1TanZEUGM3S01TVnBYQUpXNFB4SGVhcVRETWFXU0VxN3lETWtpMDljbGdPUHptNXN1dzNnYgpJeko1NTZQeDQvNGwwaXdERGoxanNYblA2RytMR1NZMEJ0YWtvTVd0bVpHNHNSby9VZURJd1NZQTJvemE1VDIzCnFBanRIWlhjMERvajE2RzRKMFgyY1RPcWcvYjh0SWFwOWZCZXYwWnhHZDNzL1E0VzdDSWdyVE1pOEtvRU5OSGIKM2puYkV0VWNCZ2pMTzRORFdQaVlRYTJ1SGMrWlU3SGZkWWxGbHdJREFRQUJBb0lCQVFDQ3JrU1E2QVpzTlFNLwplWWFrZXZKQ04ySENiZThzaFp4UmtuTGlwU2pKYURtRzdZZHdVdU1VRCttb2ZqODV2amZBVEJiMyt0a0o3WVFYClpHUXYyZnlBY3h0RU13aGlXYVFLM1h3b3U4dDZQWnlud2RSQ1prZnZOWUVTWktKUGM2SDBjRXpFV1VmaWZEaDkKQk4yMlNKUGczSWlXTHExU2RWd25GcUFSVjZNL3grU3o5SzZjN0hNWGRMUUtOUmFsNTdYbDZobm9yTEpRcU1QdAphZDY3d2F0dFdXK2Q5OXZLRld2Znl0ZittemhKdWUwYUZNQUdqU09MSFZVRHlLbW9NUEZ0dUxWNjRCQmpaMWRZCk9uUWhCdWZiUzFDR0RIaUlLSXRidFQ1M0w5RmNYUEZxRjlqNytRSENxaDZSNUtoWmpMOTVEeDVRUTliaFY2cm8KNHp4bHNiTnhBb0dCQU5YNnBSdlRsUHp5QmI5SzlPcWc4Slo4ZmxBaVZYc095YVdqMDlsODkzTFg2VnZ5RmtrRgoxb3k5WnpkWXRKS0xwUUo2enlZOVl3N1VwVG9LZWU0cUlGaE5ETUhDdjd2L0ZObVJvekJYMGU5RGNrbTNMaTlXCkFUbHVMeGZRd2Q0SzJQcEtua3BvMWxlNHI2cTdoREoxajNlTFB3REV1dVkxVU4zZndYL2YwNmsvQW9HQkFNNzEKUzh0SGpibytkYktUTXBVcDh5YzE0SkF5WEFxY2kyZEZER0hIa3BsTENuS1lYRUNrSGduOXFRZ2JJNHlYLzZjTApqZGh6Zjl1QWNabDVqUDJvaHltWTRvTHhmVG8zZ2wyTUwvUkZhMUN3MFdZVm53cVllb1k5THFodktXc1pObWNTClJnc0E5cXRzRkVKRFJ4YlFwbkR3UkpNOFdBakhvY1gyVXhPdG03V3BBb0dBUGRPR0VWdzVHRHoxM0NmVVRGYmsKTFJjYmlCdmpod0xtMEsxZGNPSGl2WlFWSVRQNXJHKzdaajd6cTlJOW1ub3UyMkNRcWdQaXMwNU56MDlubTZFZwpaMk1iNUlCWTFnRUdEVGMvWjZCNFVDRzB6QWZabUdQSlJzYkhaS0kwNGV0UWRrRkpLMGJQWjlrOUtKKzF1cjZ0CkRXVjJkc3BoRmxNaFlucGNkbzQ5b2hFQ2dZQktkQks5WWRPSjhoaHprdUw2cUtuU0xGN0tZV09kYWEzNUMrMGwKYkIvQVNDL05CQ1VFR0VhNlAyaEZBMFpwdVBEL0RuZ01LNWtPeFltWXRoTFQyb0l0bzlPeFdlRThSV1gvODRQNAo4OVJrcGdmZkd0NHBlS3R6aWFVMGNURk1WemlzSWZYUzFaam9HS3k5SGVrQU96WDFvV3A2TVpaV0trTjNyV003CnpCUWRhUUtCZ1FDM3g3aEtjWkUvbUJxT1dUek4wczNDcWQ1VU9vUnNIZ0syRFhiUW8zT0E1Skc1WThBU1JwUDkKOFI2R3NaZnplMVpsZk04OUZsM3NUVWFoYVpkNXRKSjZtOTZ4VkZxRHNQNmI0N0ZId0tIcFFHZGNEeFJ3QzdiTgpqdWxRNUZwSHpOb1RZdUZsWVFJaG9YQ3JDNitDRzNnRlhlNVhid0F4THlmdWdNZExLV0gzZ1E9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
    username: ilinux

用户和集群组合起来

[root@master pki]# kubectl config set-context ilinux@mykube --cluster=mykube --user=ilinux   --kubeconfig=/tmp/ilinux.kubeconfig
Context "ilinux@mykube" created.
 

使用普通用户将没有权限。

查看当前文件

root@master pki]# kubectl config view  --kubeconfig=/tmp/ilinux.kubeconfig
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt--embed-Certs=true
    server: https://10.0.0.110:6443
  name: mykube
contexts:
- context:
    cluster: mykube
    user: ilinux
  name: ilinux@mykube
current-context: ""
kind: Config
preferences: {}
users:
- name: ilinux
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    username: ilinux
 

]# kubectl config use-context ilinux@mykube --kubeconfig=/tmp/ilinux.kubeconfig
 

案例2：如何创建sa

[root@master chapter10]# cat serviceaccount-demo.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-demo
  namespace: default
 

kubectl apply -f serviceaccount-demo.yaml

[root@master chapter10]# kubectl get sa
NAME      SECRETS   AGE
default   1         38d
sa-demo   1         56s
 

如果创建时没指定sa 。那么默认使用default 的sa

oot@master chapter10]# kubectl describe sa   default
Name:                default
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   default-token-5567g
Tokens:              default-token-5567g
 

[root@master chapter10]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-5567g   kubernetes.io/service-account-token   3      38d
sa-demo-token-fk7zd   kubernetes.io/service-account-token   3      6m41s
[root@master chapter10]#

总结：创建一个sa 账号，自动创建一个secret 。那么这个token 默认就能进行访问。所以授权才是下一步主要该做的

[root@master manifests]# cat /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.0.0.110:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.0.0.110
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
 

步骤

1.先有账号

2.创建角色

3.将上述进行绑定

k8s在诞生之初，除了对docker运行支持之外，没有更好的选择。但现在有了选择

 containerd:docker高级 运行时环境，为了让用户使用起来更方便，易用的命令行，使用容器的管理工具，不包含docker build 镜像管理工具，捐献出来的仅仅是docker 运行时环境，不包含打包服务之类。 

containerd-shim :是为了让containerd ,runc 和oci 兼容的垫片。与k8s 进入的也是此处

runc :低级运行时环境

容器的安全上下文：

        k8s为了安全运行pod和容器。专门设计了安全上下文的概念，允许用户和管理员定义pod 或容器的特权或 访问控制机制以配置容器与主机以及主机之上的其他容器之间的隔离方式或者称为隔离级别。因此从这个意义上来讲，安全上下文就是一组用来决定容器如何创建和运行的约束条件

Pod上的Security Context 有两个级别

        Pod 级别：对pod 所有容器都生效

        容器级别：

        PSP:

apiVersion: v1
kind: Pod
metadata: {…}
spec:
  securityContext:        # Pod级别的安全上下文，对内部所有容器均有效
    runAsUser <integer>   # 以指定的用户身份运行容器进程，默认由镜像中的USER指定
    runAsGroup <integer>   # 以指定的用户组运行容器进程，默认使用的组随容器运行时
    supplementalGroups  <[]integer>  # 为容器中1号进程的用户添加的附加组；
    fsGroup <integer>  # 为容器中的1号进程附加的一个专用组，其功能类似于sgid
    runAsNonRoot <boolean>  # 是否以非root身份运行
    seLinuxOptions <Object>  # SELinux的相关配置
    sysctls  <[]Object>  # 应用到当前Pod上的名称空间级别的sysctl参数设置列表
    windowsOptions <Object>  # Windows容器专用的设置
  containers:
  - name: …
    image: …
    securityContext:       # 容器级别的安全上下文，仅生效于当前容器
      runAsUser <integer>   # 以指定的用户身份运行容器进程
      runAsGroup <integer>   # 以指定的用户组运行容器进程
      runAsNonRoot <boolean>  # 是否以非root身份运行
      allowPrivilegeEscalation <boolean> # 是否允许特权升级
      capabilities <Object>  # 于当前容器上添加（add）或删除（drop）的内核能力
        add  <[]string>  # 添加由列表定义的各内核能力
        drop  <[]string>  # 移除由列表定义的各内核能力
      privileged <boolean>  # 是否运行为特权容器
      procMount <string>   # 设置容器的procMount类型，默认为DefaultProcMount；
      readOnlyRootFilesystem <boolean> # 是否将根文件系统设置为只读模式
      seLinuxOptions <Object>  # SELinux的相关配置
      windowsOptions <Object>  # windows容器专用的设置

镜像拉去策略：

 案例1，改变容器运行的用户。容器内的进程以普通用户身份运行。 runasuser

securitycontext-runasuser-demo.yaml  

 案例2：设定容器记得内核能力capabilities

securitycontext-capabilities-demo.yaml 

CAP_CHOWN：改变UID和GID； 
CAP_MKNOD：mknod()，创建设备文件； 
CAP_NET_ADMIN：网络管理权限； 
CAP_SYS_ADMIN：大部分的管理权限； 
CAP_SYS_TIME：设定系统和内核时钟
CAP_SYS_MODULE：装载卸载内核模块

CAP_NET_BIND_SERVER：允许绑定特权端口

command :在容器上可以使用command去改变镜像启动为容器默认要运行的程序。

args:向自定义要运行的程序传递参数

容器内的用户时root 用户，依然没有权限运行iptables规则，这个用户是虚拟的。映射的是宿主机的一个普通用户

 drop :chown ,不许容器内的root 改变主组

案例三：特权容器：

kubectl get pods kube-proxy-nscnl -n kube-system -o yaml
系统自带的容器拥有的特殊权限

kube-proxy 是拥有所有的管理宿主机内核权限。将apiserver所有service的变动转换对应节点的iptables 或lvs规则

kubectl get pods kube-proxy-nscnl -n kube-system -o yaml

 案例四：改变pod 内部的  网络名称空间的内核参数。但是只允许改变三个，如果改变更多那就需要做更多设置

securitycontext-sysctls-demo.yaml

Pod内可安全内核参数只有三个：kernel.shm_rmid_forced, net.ipv4.ip_local_port_range, net.ipv4.tcp_syncookies, 
额外参数：每个节点都要添加此文件和参数，并且重启kubelet

探针

通过docker学习， 以镜像格式打包并托管于运行于编排系统或者容器引擎之上的容器就是一个黑核，想探测下内部的应用进程运行的健康与否都被容器边界所阻挡。因此，正常情况下为云原生环境所开发的应用程序，都应考虑这个问题。所以，为了便于监控容器自身运行的api .检测自身运行的状况。云原生应用都应该将自身内部的各种指标向外输出。例如，健康状态必须有健康探测状态的接口。基于uri或者特殊端口。暴漏于容器边界的外部

readiness:就绪状态探测 

liveness:存活状态探测

tracing :分布式链路追踪的埋点

logs:

LivenessProbe：周期性检测，检测未通过时，kubelet会根据restartPolicy的定义来决定是否会重启该容器；未定义时，Kubelet认为只容器未终止，即为健康； 
ReadinessProbe：周期性检测，检测未通过时，与该Pod关联的Service，会将该Pod从Service的后端可用端点列表中删除；直接再次就绪，重新添加回来。未定义时，只要容器未终止，即为就绪； 
StartupProbe：便于用户使用同livenessProbe不同参数或阈值； 

三种探针：
  ExecAction：直接执行命令，命令成功返回表示探测成功； 
  TCPSocketAction：端口能正常打开，即成功； 
  HTTPGetAction：向指定的path发HTTP请求，2xx, 3xx的响应码表示成功；

spec:
  containers:
  - name: …
    image: …
    livenessProbe:
      exec <Object>     # 命令式探针
      httpGet <Object>  # http GET类型的探针
      tcpSocket <Object>  # tcp Socket类型的探针
      initialDelaySeconds <integer>  # 发起初次探测请求的延后时长
      periodSeconds <integer>         # 请求周期
      timeoutSeconds <integer>        # 超时时长
      successThreshold <integer>      # 成功阈值
      failureThreshold <integer>       # 失败阈值

案例1：命令方式探针

kubectl apply -f liveness-exec-demo.yaml

 kubectl describe  pods  liveness-exec-demo

 模仿失败

案例2： tcp Socket类型的探针

cat liveness-tcpsocket-demo.yaml

 模拟失败命令

kubectl exec liveness-tcpsocket-demo -- iptables -A INPUT -p tcp --dport 80 -j REJECT

案例三：http探针

容器中的钩子

启动后钩子：容器创建完成后 立即运行的钩子处理器，post start hook

 为容器做初始化的

pre stop hook:清理操作  。通过如下，只有这个执行完，才会正常终止

只有post start hook 启动成功了，main container才能正常工作。整个pod 才会正常进入running 状态

root@node01 chapter4]# kubectl exec lifecycle-demo -- iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 7 packets, 420 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 redir ports 80

Chain INPUT (policy ACCEPT 7 packets, 420 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
[root@node01 chapter4]# curl 10.244.2.9:8080
iKubernetes demoapp v1.0 !! ClientIP: 10.244.0.0, ServerName: lifecycle-demo, ServerIP: 10.244.2.9!
[root@node01 chapter4]# cat lifecycle-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
    livenessProbe:
      httpGet:
        path: '/livez'
        port: 80
        scheme: HTTP
      initialDelaySeconds: 5
    lifecycle:
      postStart:
        exec:
          command: ['/bin/sh','-c','iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-ports 80']
      preStop:
        exec:
          command: ['/bin/sh','-c','while killall python3; do sleep 1; done']
  restartPolicy: Always
 

多容器pod:

    sidecar:为主容器提供辅助功能，为主容器提供日志收集器。数据同步器，配置代理，代理服务

    adapater:为容器适配到外部环境，nginx 不兼容promethus ,为了让status兼容，多个export ,

    ambassador:为主容器更好接入外部环境，访问数据库。把请求发到大使容器，大使容器再向外转发，适配到相应类型数据库

初始化容器：如果此容器不执行完，其他容器都不能执行。例如定义了两个初始化容器，意味着，pod 一启动，先运行第一个初始化容器，完成后，执行第二个初始化容器。（串行）完成后。执行主容器。如主容器之外定义了sidecar,sidecar 与主容器同步执行，但那个先执行完，不可确定。结束pod 时，两个容器都要结束。初始化容器为了比启动钩子更需要的，甚至在启动主容器前就要进行的初始化操作。（启动后钩子有可能在运行前，主容器进程已经启动，只不过只能在钩子的代码执行成功后，才会将pod 改为running 状态。主容器进程什么时候启动的，钩子是无法确定的）

可以使用初始化容器做特权操作

启动好后，并无权限查看规则。

sidecar 案例

资源：

        cpu:可压缩

        memory:不可压缩

 资源单位：

1核=1000m核

Memory   i:1024

        1ki 1mi

resource:

        request：

               cpu:

                memory:

        limit:

           cpu：

         memory:

案例： resource-requests-demo.yaml 

重点命令：kubectl get pods -o wide --watch

一个进程，如果不支持并行。那么只能占用一个cpu,运行在一个核心上。最多只能跑满一个核心。就再也上不去了

Qos  Class:

QoS Class：服务质量类别，代表了Pod的资源被优先满足的类别
  Guaranteed：Pod内的每个容器都分别设定了CPU和Memroy资源需求和资源限制，CPU的需求与限制相等，而且Memory的需求与限制也相等； 
  Bustable：
  BestEffort：未为任何一个容器设定任何需求或限制；