linux基础
uptime命令：当前时间，系统运行时间，当前登录用户数，系统负载，既任务队列的平均长度，三个数值分别是1分钟、5分钟、15分钟前到现在的平均值
系统负载的值，如果服务器的CPU为1核心，则load average中的数字>=3负载过高，
如果服务器的核心为4核心，则load average中的数字>=12负载过高。
理论上：单核心，1分钟的系统平均负载不要超过3

top—P—CPU使用排序
top—M—CPU使用排序
top—1：能清楚知道是几核CPU

linux系统参数配置文件：sysctl.conf

http状态码
500 服务器在执行请求时发生了错误，也可能是web应用存在BUG和某些临时的故障
502 网关故障
503 服务器暂时处于超负荷或正在停机维护，现在无法处理请求

405 请求的方法不被允许
404 服务器上无法找到请求的资源
403 请求资源的访问被服务器拒绝，权限问题
401 认证失败
400 请求报文语法错误

301 永久重定向
302 临时重定向

200 成功

tcp三次握手
第一次，Client—》Server：发送seq syn包，请求建立连接
第二次，Server—》Client：发送ack syn包，响应请求连接，同意建立连接
第三次，Clinet—》Server：发送ack，确认建立连接

tcp四次挥手
第一次，Client—》Server：发送fin=1 ack=z seq=x包，请求关闭数据连接
第二次，Server—》Client：返回ack=x+1 seq=z包，问client是否要关闭数据连接通道
第三次，Server—》Client：返回fin=1 ack=x，seq=y数据包，确认关闭数据连接通道
第四次，Client—》Server：确认关闭通道

为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。
其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

tcp是全双工的

发了FIN，但还没收到ACK，状态会变为 FIN_WAIT

1.k8s主要有哪些必备组件
apiserver、controller-manager、scheduler、kubelet、kube-proxy、containered、etcd
2.kubelet主要功能？
容器管理
3.kubectl是什么？
管理集群的命令行工具
4.Deployment与Statefulset有什么区别？
Deployment部署无状态应用，StatefulSet部署有状态应用
5.pause容器是起什么作用的？
共享网络和存储
6.怎么限制Pod最大使用内存量？
resources.limits.memory
7.怎么扩容/缩容pod的副本数？
kubectl scale
8.Service如何关联到对应Pod？
label
9.Service是由哪个组件负责的？
kube-proxy
10.emptyDir数据卷类型有什么作用？
在宿主机上创建一个临时空目录并挂载到容器
11.pod删除，emptyDir数据卷会删除吗？
会
12.hostPath数据卷类型有什么作用？
挂载宿主机目录或文件到容器
13.RBAC是做什么的？
基于角色的访问控制
14.ServiceAccount做什么的？
给运行的Pod中的进程提供一个身份访问Kubernetes API
15.Deployment滚动更新实现原理？
两个ReplicaSet进行不断扩容/缩容，直到新RS扩容预期达到副本数，旧RS缩容为0

1.pod的正确说法
k8s的最小部署单元、pod由一个或多个容器组成、一个pod中的多个容器在同一台node运行
2.属于部署应用程序的资源对象有：deployment、statefulset、daemonset
3.pod启动失败通过哪些命令排查
kubectl describe pod
kubectl logs
kubectl get pod
4.Service有哪几种类型？ 4 种 kubectl get svc
ClusterIP：其实就是一个vip，通过iptables或ipvs实现，只能集群内访问
Nodeport：能通过集群外访问
Loadblanner：能集群外访问，支持公有云产商
ExternalName：
5.Service有几种代理模式？
Iptables、Ipvs、userspace
6.Kubernetes安全机制经历哪几个阶段处理？
ad
7.Pod健康检查支持哪几种方法？
httpget、exec、tcpsocket
8.限制pod中容器最大可用1核 resource.limits.cpu?
1000m 1
9.PV与PVC绑定（静态）依据哪几个属性？
ad
10.
11.kube-proxy组件主要功能？
abd
12.拉取镜像的策略有？
Always、Never、IfNotPresent
13.CNI网络插件主要解决什么问题？
abd
一个pod一个唯一ip
所有的pod可以与任何其他pod直接通信
所有节点可以与所有pod直接通信
14.deployment.yaml文件中有哪几部分组成？
deployment控制器属性、预期副本数、pod模板、数据卷
15.部署有状态应用程序主要考虑哪些问题？
稳定的网络ID、稳定的数据存储、有序的启动/停止/更新

docker
docker存储方式：aufs、devicemapper、overlay2
docker4种网络方式：none、bridge、host、container

none模式：除了lo接口外，没有其他别的接口
bridge模式：docker容器初始化完成后，会生成一个docker0的网桥（可以理解为软件模拟出来的交换机），动态分配ip地址的资源池，类似dhcp，只要是加入这个网桥的容器都会获得一个ip

container模式、host模式是共享网络模式，只是共享底层网络名称空间，其他空间还是独享的
共享网络名称：network、uts、ipc都是共享的
container模式是共享容器间的网络名称空间
Host模式是容器能共享宿主机的网络名称空间

k8s架构组件
Master node
API Server
kube-Controller Manager
Route Controller
Volume Controller
Service Controller
Node Controller
Deployment Controller
ReplicaSet Controller
Scheduler
Etcd: kv存储数据库
worker node
kubectl
kube-proxy
container engine：docker

CNI：Network Plugins
CSI（Volume）：Storge Device
CRI：Container runtime

pod
pod的三种健康检查探针
readlinessProbe 检测容器进程是否健康，健康则接受流量
livelinessProbe 检测容器是否存活
startupProbe 检测容器是否存活
pod的三种探针检查方式：
execaction：操作命令
tcpsocket：tcp端口
HttpGetAction: http请求命令，返回在200~400之间，则容器健康

pod的生命周期（相位）：Pending、Running、Succeeded、Failed、Unknown（kubelte、网络可能有问题）
除了上面五种相位状态，有时候也会出现其他状态的，如CrashLoopBackOff,Error，这应该算是容器的状态，不是pod状态

一旦调度器将 Pod 分派给某个节点，kubelet 就通过 容器运行时 开始为 Pod 创建容器。 容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

pod的重启策略
Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。

pod中可以存在多个容器，方式有：
Sidecar
Adapater
ambassador

pod启动流程
1.init containers，初始化容器，初始化完成，退出
2.main container，主容器，有2个钩子3个探针：（允许人为的设置一些运行命令，做些触发操作）
post start hook：容器启动前的操作
startup probe：容器存活探针
liveliness probe：容器存活探针
readliness Probe：容器就绪探针，成功则接收流量
pre stop hook：容器停止前操作

创建pod流程：
1. kubectl创建pod，kubectl会通知到apiserver，client create pod—api server
2. apiserver会将需要创建的新pod的信息记录到etcd中
3. scheduler监测到这个新pod还没有被调度，scheduler会选择一个合适的node将该node和新pod建立绑定关系 bind pod，再将绑定关系告知apiservice，apiserver会将该绑定关系存储到etcd中
4. kubectl与apiserver通信，kubectl监测到有新的pod调度信息，通过container runtime运行该pod
5. kubectl创建成功容器后，把信息同步给apiserver，apiserver再将信息写入etcd中

用户通过REST API创建一个Pod
apiserver将其写入etcd
scheduluer检测到未绑定Node的Pod，开始调度并更新Pod的Node绑定
kubelet检测到有新的Pod调度过来，通过container runtime运行该pod
kubelet通过container runtime取到pod状态，并更新到apiserver中

拉取镜像三种方式：
Never：从不执行拉取操作，意味着只使用被绑定的节点上本地镜像；
IfNotPresent：被绑定的节点上不存在目标镜像去拉取；非latest标签的默认值；
Always：总是去拉取镜像；latest标签的默认值

重启pod三种方式：Always、Never、OnFailure

资源对象
deployment.yaml 内容有
api
kind
metadata
spec
replicas
selector
template
spec
containers
image
name
resources
volumeMounts
volumes

service.yaml 内容有
api
kind
metadata
spec
type: # NodePort、ClusterIP
ports:
- port: # Service暴露端口
targetPort: # 真正提供服务的Pod端口
nodePort: # 宿主机暴露端口
selector:

port是service端口，即k8s中服务之间的访问端口
targetport是pod（也就是容器）的端口
nodeport是容器所在node节点的端口，即外部机器可访问的端口。（通过nodeport类型的service暴露给集群节点）

ingress.yaml 内容有
api
kind
metadata
spec
rules
- host
http
ports
- backend
tls
- hosts
secretName
status
loadBalancer
ingress

pod中的容器包含：基础容器、初始化容器、业务容器 （没有回收容器）
Kubernetes架构共分为几层：接口层、治理层、应用层、内核层

网络
容器网络
每个Pod分配单独的Ip地址
使用NetworkPolicy实现访问控制
负载均衡（Service IP）
内部的虚拟Ip映射到后端多个容器
服务名称映射到虚拟IP(ServiceIP)并可通过DNS解析服务名
KUbe-proxy检测service的改变并更新Iptables（现在不用iptables了，用lvs），实现虚拟Ip端口到容器Ip，端口的映射
外部访问
外部负载均衡
Ingress的反向代理

Container Network Interface (CNI)容器网络
Kubernetes使用CNI插件来组建容器网络
当Pod的创建和销毁时，kubernetes将调用CNI插件的接口来生成网络配置
CNI插件将生成虚拟NIC，将其挂载在主机网络之上，并和Pod的namespace关联

CNI创建网络
1.kubelet runtime创建network namespace
cd /var/lib/cni
touch myns
unshare -n mount —bind /proc/self/ns/net myns
2.kubelet触发CNI插件，并传递一些配置变量

3.CNI收到配置参数后，开始创建网络
CNI插件内部先创建veth path(虚拟设备接口)
brctl addbr mynet
ip link add veth123 type veth peer name $CNI_IFNAME
brctl addif mynet veth123
ip link set $CNI_IFNAME netns $CNI_IFNAME
ip link set veth123 up

通过IPAM插件获取空闲的Ip地址
brctl addbr mynet
ip link add veth123 type veth peer name $CNI_IFNAME
brctl addif mynet veth123
ip link set $CNI_IFNAME netns $CNI_IFNAME
ip link set veth123 up

将ip配置到容器net namespace的网络设备
switch to container namespace
ip addr add 10.0.5.9/16 dev $CNI_IFNAME

实现同集群中不同节点网络互联：Calico、Flannel、NSX-t
# Calico
利用linux内核ip转发机制实现高效网络传输
基于三层路由，不依赖二层软件交换机等
通过BGP协议分发路由表
calico会在每个node上创建一个calico agent，使用自己的calico cni插件，calico plugin，这个插件会创建network namespace并分配ip地址，每个calico agent会运行各自的BGP agent，然后发现路由，从而建立起来路由表，也就实现了不同节点的network互联

Flannel
calico主要是使用第三层路由方式，而Flannel是使用overlay network方式
每个节点上，也会运行一个flannel agent
container会连接到一个叫flannel0的bridge上，fannel agent会截获这个packet，然后对这个packet进行包装，也就是把这个packet包放到udp中，不同的flannel agent之间会建立udp连接，通过udp的方式转发这个包，不同flannel之间使用tcp为总的存储，来实现不同flannet agent之间的ip包的发现和路由

Network Policy 网络策略，类似acl
基于容器标签实现网络端口的访问控制
kubernetes 1.8加入egress的控制
作用：实现不同容器间的网络隔离

Calico BGP协议 ipip(隧道方案) bgp(路由方案)
Flannel TCP协议 vlan(隧道方案) host-gw(路由方案) udp(在用户态实现的数据封装解封装，由于性能较差已经被弃用)

flannel vxlan和calico ipip模式都是隧道方案，但是calico的封装协议IPIP的header更小，
所以性能比flannel vxlan要好一点点
常见的路由方案包括了flannel的host-gw模式，以及calico的bgp模式

pod—docker0—flannel0—NAT—node
172.16.80.2/16 172.16.80.1/16 172.16.80.0/12

calico网络
calico也是业界的主流容器网络解决方案之一，同时支持CNI和CNM。calico本身也有两种模式，分别是BGP和IPIP。其中IPIP模式为overlay的方式，与flannel类似，且性能与flannel的host-gw模式相当。另一种BGP模式是基于BGP的动态路由学习。需要在每个宿主机上安装bgp的agent来实现路由学习，且需要在物理网络设备上启用bgp协议。

优点：网络性能基本无损耗，支持网络策略，安全组，多租户隔离等。
缺点：

1. 如果使用ipip模式，则面临和flannel等overlay网络方案同样的问题。
   2. 如果使用bgp模式，则需要物理网络路由支持，需要在物理网络路由器上配置表态路由转发或者bgp动态路由协议。

flannel网络
一种overlay的网络解决方案，每个主机负责一个网段，通过overlay的方式 实现容器网络的虚拟路由选路。比较灵活，应用比较广泛。flannel一共有三种模式，分别为udp、vxlan以及host-gw模式。host-gw的性能表现最好，较为接近原生网络性能。但host-gw只支持物理的大二层网络，使用有较大限制。

优点：overlay网络，灵活，使用广泛
缺点：

1. 除了host-gw，vdp和vxlan性能都比较差，但host-gw又有物理网络的使用限制
   2. overlay网络无法直接与物理网络打通
   3. 对使用者封装了网络底层，从系统设计和运维人员的角度来说，对系统底层的可控性稍差。

集群网络
flannel方案
基于calico和弹性网卡eni的terway方案
Terway 和 flannel 类似，不同的地方在于，terway 支持 Pod 弹性网卡，以及 NetworkPolicy 功能

pod可以完成四种通信：
本地通信：pod内网容器之间共享一个网络协议栈，可以通过loopback通信
同节点pod通信：通过cni0虚拟网桥内部通信，相当于二层局域网内部设备通信
跨节点pod通信：A pod发送端数据包，通过cni0网桥网关，流转到节点，经过节点的eth0发送给VPC路由，这时会查询路由表，确认数据包目的地址，并把数据包发送给对应的ECS节点。到达目的节点后，再通过cni0路由进入目的pod
pod与非pod网络实体通信：经过节点上iptables规则做snat，此规则是flanneld依据命令行—ip-masq选项做的配置

集群CIDR—VPC路由表—节点网络—节点的podCIDR—节点上的虚拟网桥cni0—pod及网桥veth
主要是三种情况配置：集群配置、节点配置、pod配置
对应对集群网络IP段的三次划分：集群CIDR—-每个节点分配podCIDR(即集群CIDR的子网段)—-在podCIDR里为每个pod分配自己的ip

负载均衡（Service IP）
kubernetes 1.8引入lvs作为实验性的kube-proxy backend
解决iptables性能问题
解决iptables无法保留源Ip地址头的问题
可提供多种不同负载均衡算法，如最少连接和加权路由等

外部访问
Kubernetes提供三种外部访问方式：
NodePort：Kubernetes将服务暴露在节点Ip地址的特定端口范围内(30000-32767)
Loadbalancer：Kubernetes使用外部laaS cloud provider动态创建负载均衡将外部请求重定向到Pods
Ingress Controller：使用Kubernetes ingress提供七层反向代理并支持tls等功能

存储
本质上，K8s volume是一个目录，这点和Docker volume差不多，当Volume被mount到Pod上，这个Pod中的所有容器都可以访问这个volume，在生产场景中，我们常用的类型有这几种：
emptyDir
hostPath
PersistentVolume(PV) & PersistentVolumeClaim(PVC)
StorageClass
pv 持久卷
pvc 持久卷消费
先创建pv.yaml，再创建pvc.yaml，把pv绑定到pvc上
pvc挂载到pv上，status为Bound
pv被pvc消费，claim为pvc
deployment.yaml则开始挂载这个pvc
如何回收pvc以及pv

HPA水平自动扩容
hpa 中设置的自动扩容cpu%计算：(是根据实际使用的cpu和设置的最小运行资源来判定的)
先看设置的最小运行资源是多少：resources.request.cpu
假设使用率超过50%自动扩容：
autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 6
targetCPUUtilizationPercentage: 50
如果resources.request.cpu=200m
那 pod 使用超过100m，则会自动扩容

prometheus架构组件：
prometheus server：监控服务端
Retrieval：内置的数据采集器，是基于http来实现的，即每一个被抓取的指标就得是http协议的，https的话就要配置证书，
TSDB：内置的数据存储，时序存储，这个存储只是短暂的，需要长期存储还得对接远程存储，或者存储到磁盘上 HDD/SSD
PromQL：内置数据处理语言
HTTP server：服务端
pushgateway：推送网关，有些短期任务或者批处理作业不能被prometheus server直接拉取数据，就会把数据先推送到pushgateway上，prometheus server再到pushgateway拉取数据
Alertmanager：监控管理器
prometheus web ui：自带的数据展示web，但是不够清晰，外接入grafana
service discovery：服务发现机制，

prometheus server 监控数据采集是基于pull模式的，就是是主动拉数据的，所以对server 端压力较大
但也有一些是拉不到的，比如批处理作业，这时候就得需要别的组件协助了，叫作Pushgateway，推送网关，批处理作业先把数据推送到pushgateway上，然后prometheus server再到pushgateway上拉取
prometheus server内置的TSDB存储数据只是短期的，需要长期存储的话需要对接远程存储系统，比如influencedb数据库
prometheus server 还内置有自己独特的查询语言 PromQL，告警也是建立在这个QL实现的
通过PromQL查询出现的数据展示出来，就这样一个web ui，用得上grafana
prometheus server自己通过PromQL清楚一些数据异常，判断告警，但不能实现告警，这就还需要一个告警管理器，Alertmanager

Istio
《Istio 服务网格技术解析与实践》
《云原生服务网格Istio》
《Go专家编程》

0 istio brief introduction 原理介绍
1 architecture and core component
data plane: 数据平面 envoy，负责服务与服务之间通信用的
control plane: 控制平面
mixer：策略的制定和遥测
pilot：中文是 领航员，舵手，有观测者角度，是做服务发现的，类似zookeeper
galley：istio整个知识体系的配置中心，类比微服务的apollo，主要是做配置的校验和分发
citadel：负责服务间的tls证书的

2 traffic management
流量管理、路由
3 security
4 policies and telemetry
类似acl，访问策略
5 observability
可观察性，负责流量进入集群的入口、集群的内部、集群的出口，流量的跟踪、记录、监控、流测
6 install
7 update
8 operations
操作
9 diagnostic tools
istio 诊断工具
10 configuration analysis message
统计分析配置信息
11 commands
istio 命令
galley
istio_ca
istioctl
mixs
sidecar-injector
node_agent
operator
pilot-agent
pilot-discovery

其他：CoreDNS vitess Fluentd Jaeger containerd envoy

istio：1.5.0
互联网 拥抱变化

vim ~/.bash_profile
cp tools/istioctl.bash ~/.istioctl.bash
source ~/.istioctl.bash
istioctl manifest 自动补全
istioctl version —remote=false

istio安装有两种：istioctl 和 helm

istioctl manifest apply —set profile=demo
istio安装有多种profile，不同的profile有不同的功能格式
申请demo的profile 文件清单来安装istio

istioctl profile list # 查看现1.4.5有几种profile
sds default demo minimal remote

安装成功后会罗列组件情况
tracing 链路监控相关
pilot 服务发现、服务配置
kiali 服务网格的可视化工具，类似k8s的dashboard，32075 端口
prometheus 监控
telemetry 遥测，请求报告展示，比如请求需要多少资源
galley istio配置中心
ingressGateway 入口网关
EgressGateway 出口网关
citadel 流量加密，身份认证，就k8s中的证书
injector 注入
policy 策略，人为配置的策略，类似acl

默认命名空间：istio-system

确认各个组件情况：
kubectl get all -n instio-system -o wide

修改入口网关的服务类型
kubectl patch svc -n istio-system istio-ingressgateway -p ‘{“spec”: {“type”: “NodePort”}}’
kubectl get svc -n istio-system

卸载istio
istioctl manifest generate -set profile=demo | kubectl delete -f -

懂微服务、docker、k8s，再来学istio
istio 号称第二代 微服务

istio-ingressgateway NodePort 10.103.176.12
查看接口是否成功，通的话注入流量，开始测试
curl http://10.103.176.12/productpage
which true; do curl http://10.103.176.12/productpage; done

可以到可视化工具kiali-graph-namespace 中查看具体应用的流量图
三角形 代表 service
圆圈 代表 pod

华为Istio 课程
https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXI038+Self-paced/courseware/23636d77d57540dba09d63dfcc7f1abd/f63accf801a0446eb79bc05a910c140c/?child=first

What：Istio是什么？
Istio的发展历程
Istio的基本概念和架构
Why：为什么要用Istio？
Istio的基本功能
Istio的独有优势
Istio的应用场景
How：怎么使用Istio？
Istio入门实践

1.服务网格的概念介绍
1.1 服务网格的发展历程
1.2 服务网格的相关概念
2.Istio服务网格架构及使用场景介绍
2.1 Istio的概念初识
2.2 Istio的技术架构
2.3 Istio的特性功能
2.4 Istio的应用场景

1.云原生业界定义和技术发展趋势

2.服务网格是承载微服务架构理念的云原生技术形态
在每个服务前面加入一个代理层，服务网格还有一个控制面

3.Istio项目发展历程

4.Istio已日趋成为服务网格标准
Istio是一种云原生的、应用层、网络技术，用于解决组成应有的组件之间的连接、安全、策略、可观察性等问题

对于云原生应用，采用kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置

5.Istio概念初识
项目组件：frontend advertisement:v1 advertisement:v2 DB
使用istio控制流量流向：如80%流量流向v1,20%流向v2；v2到DB如果出现问题，可进行熔断
使用istio安全性控制：服务间通信可使用mTLS

通过策略来实现服务间灵活访问

istio三个基础资源
Ingress gateway：
Virtual Service：策略就是配置在这里的，故障注入 流量超时 重试等
Destination Rule：定义些服务的集合，流量治理的方式 负载均衡模式

控制面的组件及功能：
Galley：解析yaml，转换成istio可理解的格式
Pilot： 下发给数据面
Citadel：负责跟安全相关的服务治理
Istiod = Galley + Pilot + Citadel

Istio技术架构
逻辑划分
数据平面：由一组智能代理(Envoy)组成，被部署为sidecar
控制平面：管理并配置代理来进行流量路由
istio核心组件：
Pilot：为Envoy sidecar提供服务发现、用于智能路由的流量管理功能(例如，A/B测试、金丝雀发布等)以及弹性功能（超时、重试、熔断等）
Citadel：通过内置的身份和证书管理，可以支持强大的服务到服务以及最终用户的身份验证。
Galley：Istio的配置验证、提取、处理和分发组件

Istio功能特性
核心理念
1.非侵入式Sidercar注入技术，将数据面组件注入到应用所在的容器，通过劫持应用流量来进行功能实现，应用无感知。
2.北向API基于K8s CRD实现，完全声明式，标准化
3.数据面与控制面通过xDS gRPC标准化协议通信，支持订阅模式
核心特性：
1.服务&流量治理：熔断，故障注入，丰富的负载均衡算法，限流，健康检查，灰度发布，蓝绿部署等
2.流量与访问可视化：提供应用级别的监控，分布式调用链，访问日志等
3.安全连接：通过mTLS、认证、鉴权等安全措施帮助企业在零信任的网络中运行应用

Istio应用场景
灰度发布：版本升级平滑过渡的一种方式，金丝雀发布、蓝绿发布等
流量管理：负载均衡、连接池管理、熔断、故障注入等
访问可视化：监控数据采集、运行指标分析、应用拓扑和调用链展示等
应用场景：电商应用、政企业务、视频业务等

https://istio.io/

Istio灰度发布管理
What：什么是灰度发布？
灰度发布的基本概念和分类
Why：为什么要用灰度发布？
灰度发布的功能和独特优势？
灰度发布的使用场景
How：怎么使用灰度发布？
灰度发布入门实践

1.业务灰度发布概述
1.1 灰度发布的定义和分类
1.2 灰度发布的流程
2.ASM灰度发布功能与使用场景介绍
3.实验：基于ASM实现web app版本的灰度发布

蓝绿发布指的是引一部分实际流量对一个新版本进行测试
灰度发布具体包括：蓝绿发布、基于权重的灰度发布、基于内容的灰度发布
灰度发布流程：添加灰度版本、配置灰度策略、观察灰度版本工作状态、检查灰度版本正常上线

Istio流量治理与监控管理
1.了解Istio基本的流量治理策略
2.了解Istio基本的API对象
3.了解Istio基本的监控功能

目录
1.服务治理介绍
微服务框架与服务治理的差别
2.Istio常用的流量治理策略
更多典型、常用的流量治理策略
3.Istio监控介绍
Istio的可观测性：访问日志、调用链、监控指标

服务网格就是在微服务基础上发展起来的
istio：数据平面(流量管理：envoy) + 控制平面(组件管理：pilot(流量管理) + Citadel(证书管理) + Galley(sidecar代理分发、注入))

RESTful 资源状态转换

URI 就是一个资源
http://localhost:9200/test/test.txt
请求接口符合http方法，如：GET POST PUT DELETE HEAD

路径是对资源的定位，方法是对资源的操作
使用http方法暴露url资源
get head put delete 请求是安全的，无论请求多少次，都不会改变服务器资源状态，post就不是幂等性的
post是没有幂等性的，对同一个资源进行两次post操作，可能结果不一样

es 请求响应都是json格式的
JSON JavaScript Object Notation
json字符串：网络中传递的字符串的格式符合JSON格式

ElasticSearch Index(索引) Type(类型) Documents(文档) Fileds(字段)
MySql Database(库) Table(表) Row(行) Column(列)

ElasticSearch 7.X中，Type已经被删除

操作
PUT http://127.0.0.1:9200/shopping # 创建索引，索引名称为shopping
GET http://127.0.0.1:9200/_cat/indices?v # 显示详细信息，展示当前所有索引
DELETE http://127.0.0.1:9200/shopping # 删除索引
POST http://127.0.0.1:9200/shopping/_doc # 添加文档/数据

RESTful中，POST是创建，PUT是更新/创建
PUT http://127.0.0.1:9200/shopping/_create/1001 # 创建数据

完全覆盖性修改 PUT
局部修改 POST

web性能看两个指标：吞吐量、响应时间

从一个HTTP请求开始：
1.用户浏览器发送请求经过网络到达web服务器 （dns解析）
2.web服务器处理请求，并响应数据 （建立tcp连接）
3.响应数据从web服务器发送到用户端 （客户发起http请求）
4.用户浏览器接收数据，本地计算和渲染 （前端会做优化，加快渲染速度）

解析时间 —- 浏览器dns缓存、系统Host文件、系统dns缓存、系统dns、x.x.x.IP、dns预获取
等待响应时间 —- tcp握手
建立连接
服务器响应
数据传输时间 —- 客户发起的http请求
发送请求时间
数据接收时间
浏览器渲染时间

单机性能优化 （找到瓶颈点）
使用集群、使用缓存、业务逻辑优化、多机房部署，就近访问
单机时代：集群系统—文件存储—缓存应用—数据缓存—异地灾备

web性能优化
几个方面：cpu、内存、磁盘、网络
cpu：进程数、CPU绑定
内存：JVM设置、GC优化、大页内存、内存合并ksmd
磁盘io：openfile、sendfile、IO调度算法
网络：Epool、Socket优化(time_wait)、持久连接

Socket 就是 套接字
Socket五元组：源地址、源端口、目的IP地址、目的端口、类型：TCP/UDP
TCP Socket四元组：源ip地址、源端口、目的ip地址、目的端口

查看系统可用端口
[root@base ~]# cat /proc/sys/net/ipv4/ip_local_port_range
1024 65000
可直接修改，不要超过65535就行

yum -y install httpd-devel
ab -n 100000 -c 1000 http://www.baidu.com
-n 发起的请求
-c 并发

ulimit -a 查看open files 数量，即连接数
socket连接受open files限制的，linux一切皆文件

nc 网络军刀
yum -y install nc
nc -l -4 -p 9999 -k
-l 监听
-4 ipv4
-p 监听端口
-k socket连接

nc 192.168.56.12 9999 （这边服务端发送信息，上面监听端就能收到信息了）

lsof -i:9999 -n

应用层
表示层
会话层
传输层
网络层 tcp udp 路由器 ip
数据链路层 mac 交换机
物理层 物理设备

只要是网络问题，都可以从iso7层模型，从下往上逐层分析问题

tcp 11种状态
syn=1：标志位 设为1

C语言
任何一种程序设计语言都需要以下几个方面的内容：
数据类型：
简单数据类型：整型int、浮点型float、字符型char
复合数据类型：数组、指针、字符串、结构体、枚举类型
对应的常量、变量及其运算
流程控制：
顺序
分支（或选择）
循环
函数：
函数定义
函数调用
递归函数
输入输出：
键盘输出、屏幕输出（也称为标准输入输出）
文件输入输出

C程序由各种令牌组成，令牌可以是关键字、标识符、常量、字符串值，或者是一个符号

分号是语句结束符，每个语句必须以分号结束
// 单行注释
/ / 多行注释

//stdio.h 是一个头文件(标准输入输出头文件)没有的话会编译出错，#include是一个预处理命令，用来引入头文件

所有C语言程序都需要包含main()函数。代码从main()函数开始执行

2021.10.09
区块链
区（结点）+ 链表 + hash + 分布式

实际问题—模型—模型的性质—解决方案—评估—提出新的问题—产生新的实际应用（创新）

两个重要能力
抽象
还原：编程能力

普林斯顿大学对本科生的12项衡量指标

课内外学时比 1(课内):2(课外)

必会题：
例1：求n个数的最大值、次最大值
最朴素方法：扫描一次所有元素，找出最大值，在剩余元素中再扫描，找到最大值
void max12(int a[], int n)
{
int max1=a[0],max2,i,k,temp;
for(i=1;i<=n;i++)
if(a[i]>max1) {max1=a[i];k=i;}
temp=a[0];a[0]=max1;a[k]=temp;
max2=a[1];
for(i=2)
}

# 数据结构
2.数据元素
是数据的基本单位，在计算机程序中通常作为一个整体进行考虑和处理。
也简称为 元素，或称为记录、结点或顶点。
一个数据元素可由若干个数据项组成 （Data Item）

数据项
构成数据元素的不可分割的最小单位

数据、数据元素、数据项三者之间的关系：
数据 > 数据元素 > 数据项
例：学生表 > 个人记录 > 学号、姓名

数据对象
是性质相同的数据元素的集合，是数据的一个子集
例：整数数据对象是集合

数据元素与数据对象
数据元素—-组成数据的基本单位
与数据的关系：是集合的个体
数据对象—-性质相同的数据元素的集合
与数据的关系是：集合的子集

数据结构
数据元素不是独立存在的，它们之间存在着某种关系，数据元素相互之间的关系称为结构（Structure）
是指相互之间存在一种或多种特定关系的数据元素集合
或者说，数据结构是带结构的数据元素的集合

1.2.2 数据结构
数据结构包括以下三个方面的内容：
1.数据元素之间的逻辑关系，也称为逻辑结构。
2.数据元素及其关系在计算机内存中的表示（又称为映射），称为数据的物理结构或数据的存储结构。
3.数据的运算和实现，即对数据元素可以施加的操作以及这些操作在相应的存储结构上的实现。

数据结构三要素：逻辑结构、物理结构、数据运算
基本的数据结构 （逻辑结构）
线性结构：线性表、栈和队列、串、数组和广义表
非线性结构：树、图
物理(存储)结构：
顺序结构
链式结构
索引结构
散列结构
基本的数据处理技术：（数据运算）
插入运算
删除运算
修改运算
查找技术
排序技术

数据结构基本概念
1.逻辑结构：
集合结构
线性结构
树形结构
图状结构或网状结构
2.存储结构：
顺序存储结构
链式存储结构
单链表
静态链表
循环链表
双向链表
索引存储结构
散列存储结构
3.抽象数据类型的形式定义 ADT

数据—数据元素—数据对象

时间复杂度
空间复杂度

第二章 线性表
线性表是具有相同特性的数据元素的一个有限序列
若结构是非空有限集，则有且仅有一个开始结点和一个终端结点，并且所有结点都最多只有一个直接前趋和一个直接后继。可表示为：(a1,a2,…,an)

特点：
1.只有一个首结点和尾结点；
2.除首尾结点外，其他结点只有一个直接前驱和一个直接后继
简言之，线性结构反映结点间的逻辑关系是 一对一(1:1) 的
线性结构包括：线性表、堆栈、队列、字符串、数组等，其中最典型、最常用的是 —- 线性表

2.1 线性表的逻辑结构
2.2 线性表的顺序表示和实现
2.3 线性表的链式表示和实现
2.4 应用举例

线性表的定义：用数据元素的有限序列表示

线性表的类型定义：
InitList(&L)
DestroyList(&L)
ClearList(&L)
ListEmpty(L)
ListLength(L)
GetElem(L,i,&e)
LocateElem(L,e,compare())
PriorElem(L,cur_e,&pre_e)
NextElem(L,cur_e,&next_e)
ListInsert(&L,i,e)
ListDelete(&L,i,&e)

按位与&
程序分析：0&0=0; 0&1=0; 1&0=0; 1&1=1
按位或|
程序分析：0|0=0; 0|1=1; 1|0=1; 1|1=1
按位异或^
程序分析：0^0=0; 0^1=1; 1^0=1; 1^1=0
按位取反~
~0=1;-1=0;

输入输出
数据类型：简单数据类型、复杂数据类型
流程控制
函数

dockerfile
CMD
EX

RoleBinding：角色绑定，与namespace无关
ClusterRoleBinding：集群角色绑定，跟namespace有关系
kubectl describe serviceaccount admin -n kube-system # 得到Token名称
kubectl get secret -n kube-system # 根据上面得到的Token名称得到secret
kubectl describe secret admin-toen-gmwsp -n kube-system # 得到具体的token值

拉取数据 pull