[toc]

kubernetes 笔记

CI: 持续集成
CD: 持续交付，Delivery
CD: 持续部署，Deployment

kubernetes的releases版本

kubernetes 自动装箱、自我修复、自动实现水平扩展
自动实现服务发现和负载均衡，自动发布和回滚
密钥和配置集中化管理、存储编排(动态供给)
任务批处理

master/node 
    master: API Sserver,Scheduler, Controller-Manager
    node: kubelet, docker(容器引擎), kube-proxy
Pod， Label, Label Selector 
    Label: key=value
    Label: Selector:
Pod:
    自主式Pod
    控制器管理的Pod
    ReplicationController
    ReplicaSet
    Deployment
    StateFulSet(有状态副本集)
    DaemonSet
    Job,Ctonjob
    AddOns: 附加组件
HPA
    HorizontalPodAutoscaler

Master 节点: 整个k8s集群的司令部
核心组件: api_server 负责接收并处理请求
schechuler 调度容器的创建请求
控制器管理器: 确保控制器是健康状态的
k8s 并不直接调度容器，而调度的是pod。pod对容器做为封装;

服务的自动发现功能，就是把自己信息注册上去;
NMT: 一般开放给外部访问的只有N，而N 在集群内其实是也是客户端;
在一个大的集群中，只把有特殊需求的，开放给客户端;
LBaaS: 负载均衡及服务;

多种通信
同一个Pod内的多个容器间通信:lo
各Pod之间的通信 Overlay Network,叠加网络通信(二层叠加，三层叠加)
Pod与Service之间的通信

CNI插件体系:容器网络接口
    flannel: 网络配置
    calico: 网络配置，网络策略
    canel: 网络配置，网络策略

客户端—> API server
user: username, uid
group:
extra:

环境:

    master: etcd: 10.180.66.11
    node1: 10.180.66.12
    node2: 10.180.66.13
    注意这三台服务器需要时间同步

前提:

    1、基于主机名通信: /etc/hosts;
    2、时间同步;
    3、关闭firewalld和iptables.service;

    OS: CentOS 7.3.1611， Extras仓库中;

安装配置步骤:

    1、etcd cluster，仅Master节点;
    2、flannel,集群的所有节点;
    3、配置k8s的master:仅master节点;
        kubernetes-master
        启动的服务:
            kube-apiserver,kub-scheduler,kube-controller-manager
    4、配置k8s的各Node节点;
        kubernetes-node
        先设定启动docker服务;
        启动的k8s的服务:
            kube-proxy,kubelet

kubeadm

1、master, nodes:安装kubelet,kubeadm,docker
2、master: kubeadm init
3、nodes: kubeadm join
    https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.10.md
无论server 还是node  一般服务

master:
# cd /etc/yum.repos.d/
# wget https://mirrors.aliyun.com/docker-ce/linux/centos-ce.repo
# vim kubernetes.repo  
[kubernetes]
name=Kubernetes Repo 
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kuberentes-el7-x86_64/
gpgcheck=1
pgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
enabled=1
# yum -y install docker-ce kubelet kubeadm kubectl

补充:
清华大学mirrors地址
阿里云k8s地址

提供网络功能
RESTful
GET, PUT, DELETE, POST, …
kubectl run, get, edit, …
资源:对象
工作负载性资源对象 workload: Pod,ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, Cronjob, …
服务发现及服务均衡: Service, Ingerss, …
配置与存储: Volume,CSI
ConfigMap,Secret,
DownwardAPI,
集群级资源:
Namespace,Node,Role,ClusterRole,RoleBinding, ClusterRoleBinding
无数据型资源:
HPA,PodTemplate,LimitRange
创建资源的方法:
apiserver仅接收JSON格式的资源定义;
yaml格式提供配置清单，apiserver可自动将其转为json格式，而后再提交;

大部分资源的配置清单:
apiversion:group/version;
$ kubectl api-versions
kind:资源类别
metadata:元数据
name必需是唯一的
namespace
labels
annotations
每个资源的引用PATH
/api/GROUP/VERSION/namspace/NAMESAPCE/TYPE/NAME
spec:期望的状态，disired state
status: 当前状态，current state,本字段由kubernetes集群维护;
资源配置清单:
自主式Pod资源
资源的清单格式:
一级字段: apiVersion(group/version),kind,metadata(name,namespace,lables,annotations,…)spec,status(只读)
Pod资源:
spec.container<[]object>

    - name <string>
    - image <string>
      imagePullPloicy <string>
        Always(下载), Never(不下载), IfNotPresent(本地不存在镜像则下载)

修改镜像中的默认应用:
command,args
https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/

liveness probe:存活状态检测

标签:
key=value
key: 字母、数字、_、-、.
value: 可以为空,只能字母或数字开头及结尾，中间可使用
标签选择器:
等值关系:=，==，!=
集合关系:
KEY in (VALUE1,VALUE2,…)
KEY notin (VALUE1,VALUE2,…)
KEY 存在这个键就可以
!KEY 不存在这个键的资源

# kubectl get pods -l "release notin (canary,beta,alpha)"

许多资源支持内嵌字段定义其使用的标签选择器:
matchLables: 直接给定键值
matchLables: 基于给定的表达式来定义使用的标签选择器,{key:”KEY”,operator:”OPERATOR”, value:[VAL1,VAL2,…]}
操作符:
IN, NotIN:vlaues字段的值必须为空列表;
Exists, NotExists:values字段的值必须为空列表;

nodeSelector
节点标签选择器,
nodeName
annotations:
与label不同的地方在于， 它不能用于挑选资源对象，仅用于为对象提供”元数据”。
Pod的生命周期
状态:Pending(挂起)，已经创建，但未找到运行它的节点;
Running;
Failed;
Succeede;
Unknown
Pod生命周期中的重要行为：
实始化容器
容器探测：
liveness
readliness
restartPolicy:
Always, OnFailure, Never. Default to Always.

探针类型有三种:
ExecAction、 TCPSocketAction、 HTTPGetAction

Pod控制器:
ReplicationController:
ReplicaSet: 代用户创建指定数量的Pod副本，多退少补，滚动更新;新一代的ReplicationController
Deployment: 建构在ReplicaSet之上的，流动更新，回滚，声明式配置;
DemonSet:
Job:
CronJob:
StatefulSet
TRR: Third Party Resources, 1.2+, 1.7
CDR: Custom Defined Resources, 1.8+
Operator:
一个坏的脚本在k8s集群中，很有可能导致整个k8s集群岩掉;

apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: myapp
    namespace: default 
spec:
    replicas: 2 
    relector:
        matchLabels:
            app: myapp
            replease: canary
    template:
        metadata:
            name: myapp-pod
            labels:
                app: myapp
                replease: canary
                environment:qa
        spec:
            contrainers:
            - name: myapp-container
              image: ikuberentes/myapp:v1
              ports:
              - name: http
                containerPort: 80
# kubectl create -f rs-demo.yaml

Helm: 外壳 类似于redhat系统上的yum管理器一样

Service
工作模式:userspace, iptables, ipvs
userspace: 1.1-
iptables: 1.10-
ipvs: 1.11+
类型:
ExternalName, CluseterIP, NodePort, and LoadBalancer
资源记录:
SVC_NAME.NS_NAME.DOMAIN.LTD.
svc.cluster.local.
redis.default.svc.custer.local.

NodePort:client —> NodeIP:NodePort —>ClusterIP:ServciePort —> PodIP:containerPort
LoadBalancer
ExternelName
FQDN
CNAME —> FQDN
No ClusterIP: Headless Service
ServiceName —> PodIP

解决方案
多组nginx server 对应多个pod;
多个url 映射多个pod;

配置容器化应用的方式:

1、 自定义命令行参数;
args: []

2、 把配置文件直接焙进镜像;

3、 环境变量
(1) Cloud Native的应用程序一般可以直接 通过环境变量加载配置;
(2) 通过entrypoint脚本来预处理变量为配置文件中的配置信息;

4、 存储卷

CoreOS: operator
StatefulSet:

1、稳定且惟一的网络标识符;
2、稳定且持久的存储;
3、有序、平滑地部署和扩展;
4、有序、平滑地删除和终止;
5、有序的滚动更新;

三个组件: headless service、 StatefulSet 、 volumeClaimTemplate
pod_name.service_name.ns_name.svc.cluster.local
myapp-0.myapp.default.svc.cluster.local

API
Request path
http://172.20.0.70:6443/apls/apps/v1/namespaces/default/deployment/myapp-deploy/

HTTP request verb:
get, post, pub, delete
API request verb:
get, list, create, update, patch, watch, redirect, delete, deletecollection

Resource:
Subresource:
Namespace
API group

Object URL:
/apis///namespaces//

role:
operation
objects
rolebinding:
user account OR service account
role

clusterrole, clusterrolebinding

role 授权: get * ; get pod ; get deployment;

授权插件: Node, ABAC, RBAC, Webhook(基于httpd的回调机制)
RBAC: Role-based AC ‘
角色(role)
许可(permission)

当用户权限 rolebinding 绑定到 clusterrolebinding 时，clusterrolebinding 会被降权为rolebinding;

spec.serviceAccountName
rolebinding
serviceaccount
role

Kubernetes:认证、授权
API server:
subject —> action —> object
认证: token,tls,user/password
账号:UserAccount, ServiceAccount
授权:RBAC
role,rolebinding
clusterrole,clusterrolebinding
subject:
user
group
serviceaccount
object:
resource group
resource
non-resource url
action:get,list,watch,patch,delete,deletecollection…

Dashboard
1、部署

kubectl apply -f https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

2、将Service 改为NodePort

    kubectl patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n kube-system

3、 认证:
认证时的账号必须为ServiceAccount: 被dashboard pod拿来由kubernetes进行认证的;
token:
(1) 创建ServiceAccount，根据其管理目标，使用rolebinding或clusterrolebinding 绑定至合理role或clusterrole;
(2) 获取到此ServiceAccount的secret，查看secret的详细信息，其中就有token;

kubeconfig:把ServiceAccount的token封装为kubeconfig文件
(1) 创建ServiceAccount，根据其管理目标，使用rolebinding或clusterrolebinding 绑定至合理role或clusterrole;
(2)

    kubectl get secret | awk '/^ServiceAccount/{print $1}'
    DEF_NS_ADMIN_TOKEN=$(kubectl get secret SERVCIEACCOUNT_SERRET_NAME -o jsonpath={.data.token} | base64 -d )

(3)生成kubeconfig 文件

kubectl config set-cluster --kuberconfig=/PATH/TO/SOMEFILE
kubectl config set-credentials NAME --token=$KUBE_TOKEN --kubeconfig=/PATH/TO/SOMEFILE
kubectl config set-context
kubectl config use-context

kubernetes集群的管理方式
1、命令式: create, run, expose, delete, edit, …
2、命令式配置文件:create -f /PATH/TO/RESOURCE_CONFIGURATION_FILE, delete -f , replace -f
3、声明式配置文件: apply -f,path,

docker 常用的四种网络模型 bridge/joined/open/none

Kubernetes网络通信:
（1）容器间通信: 同一个Pod内的多个容器间的通信，lo
（2）Pod通信: Pod IP <—> Pod IP
（3）Pod与Service通信:PodIP <—> ClusterIP
（4）Service与集群外部客户端的通信
CNI: Container Network Interface
flanner
calico
canel
kube-router
…
解决方案:
虚拟网桥
多路复用: MacVLAN
硬件交换: SR-IOV
kubelet, /etc/cni/net.d/
flannel:
支持多种后端:
VxLAN
（1）vxlan
（2）Directrouting
host-gw: Host Gateway
UDP
flannel的配置参数
Network: flannel使用的CIDR格式的网络地址，用于为Pod的配置网络功能;
master:10.244.0.0/24
node01:10.244.1.0/24
…
node255:10.244.255.0/24
SubneteLen:把Network切分子网供各节点使用时，使用多长的掩码进行切分，默认为28位;
SubnetMin:10.244.10.0/24 开始
SubnetMax:10.244.100.0/24 结束
Backend:vxlan, host-gw, udp
vxlan:
网络策略:
名称空间:
拒绝所有出站，入站;
放行所有出站目标本名称空间内的所有Pod;

调度器:
预选策略:
CheckNodeCondition
GeneralPredicates:
HostName: 检查Pod对象是否定义了pod.spec.hostname
PodFitsHostPorts:pods.spec.containers.ports.hostPort
MatchNodeSelector:pod.spec.nodeSelector
PodFitsResources:检查Pod的资源需求是否能被节点所满足;
NoDiskConflict:检查Pod依赖的存储卷是否能满足需求;
PodToleratesNodeTaints:检查Pod的specl.tolerations可容容忍的污点是否完全包含节点上的污点;
PodToleratesNodeNoExecuteTaints: 对应的行为是默认不检查的;
CheckNodeLabelPresence: 检查节点指定标签的存在性;
CheckServiceAffinity: 亲和性，将同一Service的Pod尽可能放在一块;
MaxEBSVolumeCount
MaxGCEPDVolumeCount
MaxAzureDiskVolumeCount
CheckVolumeBinding
NoVolumeZoneConflict
CheckNodeMemoryPressure: 检查内存节点是否存在压力;
CheckNodePIDPressure: 检查PID数量是否过多;
CheckNodeDiskPressure: 检查磁盘压力是否过大;
MatchInterPodAffity: 检查节点是否满pod足亲和性与反亲和性
优选函数
LeastRequested:(cpu((capacity-sum(requested))10/capacity)+memory((capacity-sum(requested))10/capacity))
BalancedResourceAllocation: CPU和内存资源被占用率相近的胜出;
NodePreferAvoidPods:节点注解信息”scheduler.alpha.kubernetes.io/perferAvoidPods”
TaintToleration: 将Pod对象的spec.tolerations列表项与节点的 taints列表项进行匹配度检查，匹配条目越多，得分越低;
SeletorSpreading:与当前Pod对象同属的标签选择器选择适配的其它选择其Pod对象所在的节点，越多的表示越低，否则越高;
NodeAffinity:基于节点亲和性的;
InterPodAffinity:遍历Pod对象的亲和性条目，并将能匹配到给定节点的条目的权重相加，结果值越大的，表示越高;

MostRequested:跟LeastRequested正好相反;
NodeLabel:标签越多，得分越高;
ImageLocality: 镜像越多，得分越高，根据满足当前Pod对象需求的已有镜像体积大小之和;

kubectl describe nodes node node01.ssjinyao.com

节点选择器:nodeSelector, nodeName
节点亲和调度: nodeAffinity

taint的effect定义对Pod排斥效果:
NoSchedule: 仅影响调度过程，对现存的Pod对象不产生影响;
NoExecute: 即影响调度过程，也影响现存的Pod对象;不容忍的Pod对象将被驱逐;
PreferNoSchedule:不能容忍被调度过来，但是实在没有别的节点运行，也可被调度，是NoSchedule的柔性版;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: canary
  template:
    metadata:
      labels:
        app:myapp
        release:canary
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v2
        ports:
        - name: myapp
          image: ikubernetes/myapp: v2
          ports:
          - name: http
            containerPort: 80
        tolerations:
        - key: "node-type"
          operator: "Equal"
          value: "production"
          effect: "NoSchedule"

容器的资源需求，资源限制
requests: 需求，最低保障;
limits: 限制，最高消耗区间，硬限制;
CPU:
1颗逻辑CPU
1=1000微核心,millicores
500m=0.5CPU
内存:
E、P、T、G、M、K
Ei、Pi、Ti、Gi、Mi、Ki
QoS:
Guranteed: 每个容器同时设置CPU和内存的requests和limits;
cpu.limits=cpu.requests
memory.limits=memory.request
Burstable:至少一个容器设置CPU或者内存资源的requests属性;
BestEffort:没有任何一个容器设置了requests或limits属性;最低优先级别;
资源指标:metrics-server
自定义指标:prometheus，k8s-prometheus-adapter
新一代架架构:
核心指标流水线: 由kubelet、metrics-server以及由API server 提供的api组成;CPU累积使用率、内存实时使用率、Pod的资源占用率及容器的磁盘占用率;
监控流水线:用于从系统收集各种指标数据并提供终端用户、存储系统以及HPA，它们包含核心指标及许多非核心指标。非核心指标本身不能被k8s所解析,
metrics-server:API-server
Helm:
核心术语:
Chart: 一个helm程序包的;
Repository: Charts仓库，https/http服务器;
Release: 特定的Chart部署于目标集群上的一个实例;
Chart —> Config —> Release
程序架构:
helm:客户端，管理本地的Chart仓库，管理Chart，与Tiller服务器交互，发送Chart，实例安装、查询、卸载等操作;
Tiller: 服务端，可以运行在kubernetes之上，也可以运行在kubernetes之外、接收helm发来的Charts与Config，合并生成release;
RBAC配置文件示例:
https://github.com/helm/helm/blob/master/docs/rbac.md
官方可用的Chart列表:
https://hub.kubeapps.com
helm常用命令:
release管理

# helm search jenkins
# helm inspect jenkins
# helm list 
# helm install
# helm delete
# helm upgrade
# helm rollback
# helm history # release的部署历史;
# helm status # 获取release状态信息;
# helm install --name redis -f ./values.yaml stable/redis

chart管理

# helm create
# helm fetch
# helm get 
# helm inspect
# helm package 打包chart 文件
# helm verify

# helm lint ../myapp  # 检查语法错语
# helm package myapp/
# helm delete --purge mapp3 
# helm delete --purge mapp2
# helm delete --purge mapp1
# helm repo add --help 
# helm repo list

Chart —> helm,tiller service
Chart —> Config —>Release
Config:values.yaml

ELK: E:elasticsearch L:logstash K: kibana
日志收集的组件（Logstash、Filebeat、Fluentd）

当pod出现挂了的情况，查看pod日志时不方便查看。因此，应该将日志提前放到一个存储中。kubernetes集群应提供一个日志收集器。
完整的kubernetes 集群 (kubdns| kubcurl ,ingress controller,heapster| metrics-server prometheus, dashboard)
四大组件组成部分，另外附加附件efk;

/var/log —> /var/log/containers/
k8s系统关键组件:
Core Infrastructure —> Network(SDN) Storage (Provisioning Congfiguration ) —> Kubernetes Cluster —> Containerzed Worload (image registry)
额外的系统:Logging Monitoring
硬件及负载、软件及负载:LoadBalancer
存储位置:Artifact factory
构建自动化:Build Automation (CI,CD)
自动化发布:Rlease Automation