增加存储类

k8s知识笔记/三、service/1、service类型.conf

@@ -0,0 +1,5 @@
+一、service的类型
+    1、clusterip: 默认类型, 自动分配一个仅Cluster内部可以访问的虚拟IP
+    2、nodeport: 在每个Node上开放一个端口, 通过<nodeip>:<nodeport>的方式访问服务
+    3、loadbalancer: 通过云服务商的负载均衡器(LB)来暴露服务, 在nodeport的基础上, 借助cloud provider创建一个外部负载均衡器, 将请求转发到<nodeip>:<nodeport>
+    4、externalname: 把集群外部的服务引入到集群内部来, 在集群内部直接使用, 没有任何类型代理被创建, 通过返回CNAME记录将服务映射到外部服务

k8s知识笔记/三、service/2、clusterip类型.conf

@@ -0,0 +1,55 @@
+一、集群内部通信
+1.1、ClusterIP类型的Service
+
+    ClusterIP是Kubernetes中Service的默认类型。
+    它为Service分配一个虚拟IP地址, 这个IP地址只能在集群内部访问。
+    ClusterIP类型的Service通常用于集群内部的服务发现和负载均衡。
+
+    例如, 假设有一个名为my-service的Service, 它的ClusterIP地址  是10.96.0.1。集群内的Pod可以通过访问这个IP地址来与my-service通信, 而不需要知道my-service背后的Pod的具体IP地址。
+
+
+1.2、svc选中pod的逻辑
+    pod 是处于就绪状态
+    pod 的标签和 svc 的 selector 匹配(是serviced的标签子集)
+    pod 与 svc 在同一命名空间下
+
+
+1.4 svc在集群内会被解析成一个集群内域名, cluster.local是默认域名: 
+
+    <service-name>.<namespace>.svc.cluster.local
+
+    例如, 如果有一个名为my-service的Service, 它位于default命名空间下, 那么它的集群内域名就是my-service.default.svc.cluster.local
+    集群内的Pod可以通过这个域名来访问my-service
+
+
+1.5、internalTrafficPolicy
+    ClusterIP类型的Service有一个internalTrafficPolicy字段, 用于控制集群内部流量的路由策略。
+    该字段有两个可选值: Local和Cluster。
+
+    Local: 只将流量路由到与请求源节点相同节点上的Pod。这种策略可以减少跨节点的网络延迟, 但可能导致某些节点上的Pod过载, 而其他节点上的Pod闲置。
+    Cluster: 将流量路由到集群中所有匹配的Pod, 无论它们位于哪个节点上。这种策略可以实现更均匀的负载分布, 但可能增加跨节点的网络延迟。
+
+1.6、示例配置文件
+
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+  namespace: default
+spec:
+  type: ClusterIP
+  clusterIP: 10.96.0.1
+  ports:
+    - port: 80                     # Service暴露的端口
+      targetPort: 8080             # 后端Pod监听的端口
+  selector:
+    app: my-app                    # 选择标签为app=my-app的Pod作为后端
+
+
+二、命令行示例
+# 基于文件创建Service
+kubectl apply -f my-service.yaml
+
+# 试运行并生成yaml文件
+kubectl create svc clusterip myapp --tcp=80:80 --dry-run -o yaml > myapp-clusterip.yaml
+

k8s知识笔记/三、service/3、NodePort类型.conf

@@ -0,0 +1,43 @@
+一、NodePort类型的Service
+
+    NodePort是Kubernetes中Service的另一种类型。
+    它为Service分配一个静态端口, 这个端口在每个节点上都是开放的, 可以通过节点的IP地址和这个端口来访问Service。
+    NodePort类型的Service通常用于将集群内的服务暴露给集群外部的客户端。
+
+    例如, 假设有一个名为my-nodeport-service的Service, 它的NodePort端口是30007。
+    集群外部的客户端可以通过访问任意一个节点的IP地址和端口30007来与my-nodeport-service通信, 而不需要知道my-nodeport-service背后的Pod的具体IP地址。
+    
+    集群外 → NodeIP:NodePort → ClusterIP → Pod
+
+1.1、NodePort的端口范围
+    NodePort的端口范围是30000到32767, 这是Kubernetes默认
+    可以通过修改kube-apiserver的--service-node-port-range参数来更改这个范围。
+
+
+1.2、NodePort的工作原理
+    当创建一个NodePort类型的Service时, Kubernetes会在每个节点上开放一个指定的端口。
+    当集群外部的客户端发送请求到这个端口时, 请求会被转发到Service的ClusterIP, 然后再由ClusterIP将请求路由到后端的Pod。
+    这种转发和路由通常是通过kube-proxy来实现的, kube-proxy会在每个节点上运行, 负责监听NodePort端口并将请求转发到相应的ClusterIP。
+
+1.3、externalTrafficPolicy
+    NodePort类型的Service有一个externalTrafficPolicy字段, 用于控制外部流量的路由策略。
+    该字段有两个可选值: Local和Cluster。
+
+    Local: 只将流量路由到与请求源节点相同节点上的Pod。这种策略可以减少跨节点的网络延迟, 但可能导致某些节点上的Pod过载, 而其他节点上的Pod闲置。
+    Cluster: 将流量路由到集群中所有匹配的Pod, 无论它们位于哪个节点上。这种策略可以实现更均匀的负载分布, 但可能增加跨节点的网络延迟。
+
+1.4、示例配置文件
+
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nodeport-service
+  namespace: default
+spec:
+  type: NodePort
+  selector:
+    app: my-app
+  ports:
+    - port: 80                  # Service暴露的端口
+      targetPort: 8080          # Pod监听的端口
+      nodePort: 30007           # NodePort端口

k8s知识笔记/三、service/4、loadbalancer类型.conf

@@ -0,0 +1,7 @@
+一、loadBalancer类型的Service
+
+    LoadBalancer是Kubernetes中Service的另一种类型, 通常用于将集群内的服务暴露给集群外部的客户端。
+
+    当创建一个LoadBalancer类型的Service时, Kubernetes会向[云提供商]请求一个外部负载均衡器, 并将该负载均衡器与Service关联起来。
+
+    这样, 集群外部的客户端可以通过访问负载均衡器的IP地址来与Service通信, 而不需要知道Service背后的Pod的具体IP地址。

k8s知识笔记/三、service/5、ExternalName.conf

@@ -0,0 +1,39 @@
+一、ExternalName类型的Service
+    ExternalName是Kubernetes中Service的另一种类型, 用于将Service映射到集群外部的DNS名称。
+
+    当创建一个ExternalName类型的Service时, 你需要指定一个externalName字段, 该字段包含一个有效的DNS名称。
+    当集群内的Pod访问这个Service时, Kubernetes会将请求重定向到指定的DNS名称, 而不是将请求路由到集群内的Pod。
+
+    例如, 假设有一个名为my-external-service的Service, 它的externalName字段设置为example.com。
+    集群内的Pod可以通过访问my-external-service来与example.com通信, 而不需要知道example.com背后的具体IP地址。
+
+
+    ExternalName类型的Service通常用于以下场景:
+    1. 访问集群外部的服务: 例如, 你可以使用ExternalName类型的Service来访问外部的数据库服务, API服务等。
+    2. 服务迁移: 当你需要将服务从集群内迁移到集群外部时, 可以使用ExternalName类型的Service来实现无缝迁移。
+    3. 简化DNS管理: 使用ExternalName类型的Service可以简化DNS管理, 因为你只需要在Service中指定一个DNS名称, 而不需要在每个Pod中配置具体的IP地址。
+    需要注意的是, ExternalName类型的Service不支持端口映射, 因为它只是将请求重定向到一个DNS名称, 而不是将请求路由到集群内的Pod。
+    因此, 当使用ExternalName类型的Service时, 你需要确保外部服务已经正确配置了端口和协议。
+
+二、命令行示例
+kubectl create service externalname my-external-service --external-name=example.com
+
+三、示例配置文件
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-external-service
+  namespace: default
+spec:
+  type: ExternalName
+  externalName: example.com         # 指定外部的域名
+
+# 通过DNS解析查看
+kubectl exec -it <pod-name> -- nslookup my-external-service
+
+# 通过curl访问
+kubectl exec -it <pod-name> -- curl http://my-external-service
+
+当集群内的Pod访问这个Service时, Kubernetes会将请求重定向到指定的DNS名称, 而不是将请求路由到集群内的Pod。
+例如, 假设有一个名为my-external-service的Service, 它的externalName字段设置为example.com。
+集群内的Pod可以通过访问[my-external-service.default.svc.cluster.local]来与[example.com]通信, 而不需要知道[example.com]背后的具体IP地址。

k8s知识笔记/三、service/6、IPVS 持久化连接.conf

@@ -0,0 +1,13 @@
+一、会话保持
+
+    IPVS支持会话保持功能, 可以通过以下方式实现: 
+    1. 使用--persistent参数, 该参数指定会话保持的时间, 单位为秒. 例如, --persistent=300表示会话保持300秒.
+    2. 使用--hash参数, 该参数指定用于会话保持的哈希算法. 常用的哈希算法包括:
+        - sourceip: 基于源IP地址进行哈希计算, 适用于客户端IP地址不变的场景.
+        - sourceipport: 基于源IP地址和源端口进行哈希计算, 适用于客户端IP地址可能变化但端口不变的场景.
+        - destinationip: 基于目标IP地址进行哈希计算, 适用于服务端IP地址不变的场景.
+        - destinationipport: 基于目标IP地址和目标端口进行哈希计算, 适用于服务端IP地址可能变化但端口不变的场景.
+
+
+# 资源清单内开启基于客户端的会话保持：默认3个小时超时（3个小时内有连接会重置3小时超时）
+service.spec.sessionAffinity:ClientIP 

k8s知识笔记/三、service/7、Endpoint.conf

@@ -0,0 +1,27 @@
+一、Endpoint 与 Service 和 Pod 的关系
+
+    Kubernetes中的Service, 它定义了一组Pods的逻辑集合和一个用于访问它们的策略。
+    一个Service的目标Pod集合通常是由Label Selector来决定的。
+
+    Endpoints是一组实际服务的端点集合。
+    一个Endpoint是一个可被访问的服务端点,即一个状态为running的pod的可访问端点。
+    一般Pod都不是一个独立存在,所以一组Pod的端点合在一起称为EndPoints。
+    只有被Service Selector匹配送选中并且状态为Running的才会被加入到和Service同名的Endpoints中。
+
+创建service时, 会自动创建一个和service同名的endpoints对象, 该对象中包含了所有匹配service selector的pod的IP地址和端口信息。
+
+    例如, 假设有一个名为my-service的Service, 它的selector是app=my-app。
+    如果有两个Pod, 分别是pod-1和pod-2, 它们都有标签app=my-app, 并且它们都在运行状态。
+    那么, Kubernetes会自动创建一个名为my-service的Endpoints对象, 其中包含pod-1和pod-2的IP地址和端口信息。
+
+    Service通过Endpoints对象来实现负载均衡和服务发现。
+    当客户端请求Service时, Kubernetes会从Endpoints对象中选择一个Pod的IP地址和端口, 并将请求转发给该Pod。
+    这样, 客户端就可以通过Service来访问一组Pod, 而不需要知道它们的具体IP地址。
+
+Endpoint的类型
+    Endpoint对象中的每个端点都包含了Pod的IP地址和端口信息。
+    这些端点可以是IPv4地址, IPv6地址, 或者是主机名。
+    端点还可以包含一些元数据, 例如Pod的名称, 命名空间, 和标签等。
+
+    自动关联: 当创建一个Service时, Kubernetes会自动创建一个与该Service同名的Endpoints对象。
+    手动创建: 也可以手动创建Endpoints对象, 并将其与Service关联起来。

k8s知识笔记/三、service/8、publishNotReadyAddresses.conf

@@ -0,0 +1,9 @@
+一、创建为就绪pod的serveice
+
+
+
+二、命令行示例
+使用打补丁的命令修改: 
+# kubectl patch service myapp -p '{"spec":{"publishNotReadyAddresses": true}}
+
+三、示例配置文件

k8s知识笔记/二、k8s pod 控制器/3、deployment控制器.conf

@@ -4,7 +4,7 @@ Deployment 控制器是 Kubernetes 中用于管理应用程序部署和更新的
 它提供了一种声明式的方法来定义和管理应用程序的生命周期, 包括创建、更新和回滚等操作。
 Deployment 控制器(通过管理 ReplicaSet 来确保应用程序的期望状态与实际状态保持一致)，从而实现高可用性和弹性伸缩。
 
-
+#-----------------------------------------------------------------------------------------------
 
 二、声明式与命令式
 
@@ -20,6 +20,7 @@ Deployment 控制器(通过管理 ReplicaSet 来确保应用程序的期望状
 # kubectl diff -f deployment.yaml
 比较当前集群实际运行的资源清单对象与当前资源清单文件对象的差异
 
+#-----------------------------------------------------------------------------------------------
 
 三、Deployment 控制器资源清单
 
@@ -48,6 +49,7 @@ spec:
 
 # 上边的Deployment控制器清单没在spec中设置replicas，默认为 1
 
+#-----------------------------------------------------------------------------------------------
 
 三、Deployment常用命令
 
@@ -75,3 +77,35 @@ spec:
 # kubectl set image deployment/myapp-deployment myapp-container=nginx/nginx:1.9.1
 更新Deployment控制器的镜像
 
+#-----------------------------------------------------------------------------------------------
+
+四、金丝雀部署思想
+利用Deployment控制器的滚动更新特性, 可以实现金丝雀部署。
+先设置Deployment控制器允许多n个pod, 允许少0个pod, 然后逐步更新pod的镜像版本, 观察新版本的稳定性, 如果新版本稳定, 则继续更新剩余的pod, 如果新版本不稳定, 则回滚到旧版本。
+
+Deployment 控制器回滚的原理是etcd内存了这个Deploymen控制器控制的对应的RS的历史版本
+
+1、通过补丁方式 设置Deployment控制器的滚动更新策略, 允许多1个pod, 允许少0个pod
+# kubectl patch deployment myapp-deployment -p '{"spec":{"straegy":{"rollingUpdate":{"maxSurge":"1", "maxUnavailable":"0"}}}}'
+
+2、更新Deployment控制器的镜像版本 (由于 1 的设置, 会多创建一个新pod, 然后停止删除旧pod)
+# kubectl patch deployment myapp-deployment --patch '{"spec":{"template":{"spec":{"containers":[{"name":"myapp-container","image":"nginx:1.9.1"}]}}}}' && kubectl rollout rollout pause deploy myapp-deployment
+
+3、恢复滚动更新 (恢复新建一个新pod, 删除一个旧pod, 创建一个新pod)
+# kubectl rollout resume deploy myapp-deployment
+
+  暂停滚动更新
+# kubectl rollout pause deploy myapp-deployment
+
+4、回滚到上一个版本【注】回滚只能回滚到上一个版本, 不能回滚到更早的版本
+# kubectl rollout undo deploy myapp-deployment && kubectl rollout status deployments myapp-deployment
+
+5、查看回滚的历史记录
+# kubectl rollout history deployment myapp-deployment
+
+[注意] 更新命令在尾部加上 --record 参数, 可以记录变更历史, 方便后续查看和回滚
+
+6、回滚到制定版本(这里的版本号数字是命令5查询出来的历史记录中的版本号)
+# kubectl rollout undo deploy myapp-deployment --to-revision=2 && kubectl rollout status deployments myapp-deployment
+
+

k8s知识笔记/二、k8s pod 控制器/4、daemonSet控制器.conf

@@ -0,0 +1,37 @@
+一、DeamonSet 简介
+DaemonSet 是 Kubernetes 中的一种控制器, 用于确保在集群中的每个节点上运行有且只有一个 Pod 的副本。
+它通常用于部署需要在每个节点上运行的后台服务, 例如日志收集、监控代理等。
+当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。
+删除DaemonSet将会删除它创建的所有Pod
+
+使用场景:
+1. 集群日志收集: 在每个节点上运行日志收集代理, 如Fluentd, Logstash等
+2. 监控代理: 在每个节点上运行监控代理, 如Prometheus Node Exporter, Datadog Agent等
+3. 网络插件: 在每个节点上运行网络插件, 如Calico, Weave等
+4. 存储插件: 在每个节点上运行存储插件, 如Ceph, GlusterFS等
+5. 安全代理: 在每个节点上运行安全代理, 如Falco, Sysdig等
+
+#-----------------------------------------------------------------------------------------------
+
+二、DaemonSet 控制器清单示例
+
+apiVersion: apps/v1
+kind: DaemonSet
+metadata:
+  name: my-daemonset
+    labels:
+      app: my-daemonset
+spec:
+  selector:
+    matchLabels:
+      app: my-daemonset
+  template:
+    metadata:
+      labels:
+        app: my-daemonset
+    spec:
+      containers:
+      - name: my-container
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80

k8s知识笔记/二、k8s pod 控制器/5、job控制器.conf

@@ -0,0 +1,35 @@
+一、Job 控制器简介
+    Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。
+    Job 控制器用于管理批处理任务, 确保指定数量的 Pod 成功完成其任务。
+    它适用于需要一次性执行的任务, 如数据处理、备份等。Job 控制器会创建一个或多个 Pod 来执行任务, 并监控其状态, 直到所有 Pod 成功完成任务为止。
+    如果某个 Pod 失败, Job 控制器会根据配置重新创建 Pod 以确保任务完成。
+
+特殊说明：
+    * spec.template 格式同 Pod
+    * RestartPolicy 仅支持 Never 或 OnFailure
+    * 单个 Pod 时, 默认 Pod 成功运行后 Job 即结束
+    * .spec.completions 标志 Job 结束需要成功运行的 Pod 个数, 默认为 1
+    * .spec.parallelism 标志并行运行的 Pod 的个数, 默认为 1
+    * spec.activeDeadlineSeconds 标志失败 Pod 的重试最大时间, 超过这个时间不会继续重试
+
+
+#-----------------------------------------------------------------------------------------------
+
+二、job 控制器资源清单
+
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: my-job
+spec:
+  completions: 3               # 需要成功运行的 Pod 个数, 默认为 1
+  parallelism: 2               # 并行运行的 Pod 的个数, 默认为 1
+  backoffLimit: 4              # 失败 Pod 的重试次数, 默认为 6
+  activeDeadlineSeconds: 100   # 失败 Pod 的重试最大时间, 超过这个时间不会继续重试, 单位秒
+  template:
+    spec:
+      containers:
+      - name: my-job
+        image: my-job-image
+      restartPolicy: Never
+

k8s知识笔记/二、k8s pod 控制器/6、cronjob控制器.conf

@@ -0,0 +1,84 @@
+一、cronjob控制器简介
+
+    CronJob管理基于时间的Job,即:
+        * 在给定时间点只运行一次
+        * 周期性地在给定时间点运行
+
+    使用条件:当前使用的Kubernetes集群,版本>=1.8(对CronJob)
+
+    典型的用法如下所示:
+        * 在给定的时间点调度Job运行
+        * 创建周期性运行的Job,例如:数据库备份、发送邮件
+        * 创建周期性运行的任务,例如:定期清理临时文件
+    
+    #-----------------------------------------------------------------------------------------------
+
+    CronJob 控制器用于在 Kubernetes 集群中定期运行任务。它类似于传统的 cron 作业, 但具有更强大的功能和灵活性。CronJob 控制器允许用户定义定时任务的调度时间、任务执行的命令或脚本, 以及任务的并发策略等。
+    
+    CronJob 控制器通过创建和管理 Job 资源来实现定期任务的执行。每当达到预定的时间点时, CronJob 控制器会创建一个新的 Job 资源, Job 资源负责实际执行任务。用户可以通过配置 CronJob 的 spec 字段来定义任务的调度规则和执行细节。
+    
+    CronJob 控制器支持多种调度方式, 包括基于时间间隔的调度和基于特定时间点的调度。用户可以使用类似于 cron 表达式的语法来定义调度规则, 例如 "0 0 * * *" 表示每天午夜执行一次任务。
+    
+    除了基本的调度功能外, CronJob 控制器还提供了一些高级功能, 例如并发策略、失败重试机制和历史记录保留等。用户可以根据需要配置这些选项, 以满足不同的任务执行需求。
+    
+    总之, CronJob 控制器是 Kubernetes 中用于管理定期任务的重要组件, 它简化了任务调度和执行的过程, 提高了系统的自动化水平和可靠性。
+    
+    #-----------------------------------------------------------------------------------------------
+
+
+
+    
+二、CronJob 常用命令
+    
+    # 创建 CronJob
+    kubectl apply -f cronjob.yaml
+    
+    # 查看 CronJob 列表
+    kubectl get cronjob
+    
+    # 查看特定 CronJob 的详细信息
+    kubectl describe cronjob <cronjob-name>
+    
+    # 删除 CronJob
+    kubectl delete cronjob <cronjob-name>
+    
+    # 查看由 CronJob 创建的 Job 列表
+    kubectl get jobs
+    
+    # 查看由 Job 创建的 Pod 列表
+    kubectl get pods --selector=job-name=<job-name>
+    
+    # 查看特定 Pod 的日志
+    kubectl logs <pod-name>
+    
+    # 手动触发 CronJob 创建一个 Job
+    kubectl create job --from=cronjob/<cronjob-name> <new-job-name>
+    
+    #-----------------------------------------------------------------------------------------------
+    
+三、CronJob 控制器资源清单
+    
+资源清单字段：
+
+.spec.schedule: 调度, 必需字段, 指定任务运行周期, 格式同Cron
+
+.spec.jobTemplate: Job模板, 必需字段, 指定需要运行的任务, 格式同Job
+
+.spec.startingDeadlineSeconds: 启动Job的期限(秒级别), 
+    该字段是可选的
+        如果因为任何原因而错过了被调度的时间,那么错过执行时间的Job将被认为是失败的
+        如果没有指定,则没有期限
+
+.spec.concurrencyPolicy: 并发策略
+    该字段也是可选的。它指定了如何处理被CronJob创建的
+    Job的并发执行, 只允许指定下面策略中的一种:
+        Allow(默认): 允许并发运行Job
+        Forbid: 禁止并发运行, 如果前一个还没有完成, 则直接跳过下一一个
+        Replace: 取消当前正在运行的Job, 用一个新的来替换
+        注意, 当前策略只能应用于同一个CronJob创建的Job, 如果果存在多个CronJob, 它们创建的Job之间总是允许并发运行。
+
+.spec.suspend: 挂起, 该字段也是可选的。 
+    如果设置为'true',后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为'false'
+
+.spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit: 历史限制, 是可选的字段。
+    它们指定了可以保留多少完成和失败的Job。默认情况下,它们分别设置为'3'和'1'。设置限制的值为'0',相关类型的Job完成后将不会被保留

k8s知识笔记/四、存储分类/1、configmap.conf

@@ -0,0 +1 @@
+一、configmap