无论service还是ipvs都是四层调度，四层调度工作在七层模型的第四层，如果用户访问https,那么四层是无法解析https回话，如果要使用https便只能在后端pod配置https来使用https，这样一来，那便意味着客户端与后端服务器之间直接建立ssl会话(图1)，此刻，如果下一个请求被调度
2023-07-16
在之前的Ingress Controller介绍中，我们已经知道了Ingress用途。我们开始准备ingress使用和配置，资源清单包括之前所述的apiVersion,kind,metadata,spec等，在spec中较为特别：其中rules调度的是host或者http,如果是https则是tls
2023-07-16
在之前的一篇中简单的安装配置了Ingress Controller和Ingress Controller概述，唯独缺少后端的配置和https七层的配置，这里涉及到secret，secret存储卷在后面将会提到，先看下如何配置一个ingress backend规则那么现在，按照之前的配置Ingress
2023-07-16
大多数有状态的应用都是需要持续存储数据的。容器本身有生命周期，容器终结后，或者编排到其他节点运行，那就意味着数据不能存放在容器内，否则在删除或者容器损坏时数据会丢失引言在k8s中，pod一直运行在机器上，除非机器宕机pod才会被调度到其他机器，顶多重启。一旦这个pod被删除(故障)，或者机器宕机(被
2023-07-16
此前，在的存储卷类型介绍中，emptyDir只在节点本地使用。创建一个pod，一个存储卷，pod被删除，存储卷也会被删除.empryDir数据随着pod的创建而创建，随着删除而删除empryDir可以当临时目录，或者缓存使用(关联宿主机的目录可以是宿主机的内存，将内存放到pod存储卷)。没有持久化。
2023-07-16
此前在存储卷类型中提到，hostPath位于主机路径，在宿主机创建目录挂载。一定意义的持久性。pod所在宿主机之上的，脱离pod容器名称空间之外的，宿主机的文件系统某一个目录与pod建立关系。当pod被删除，存储卷不会被删除。只要同一个pod调度到同一个节点，数据依然可被正常使用。volumes：
2023-07-16
共享存储特性是不管node是否挂掉，pod中容器是否在同一个节点，数据都不丢失，数据不存放在某一个单独的node之上。这和之前的主机存储卷hostPath，empryDir在持久化存储上效果更好。在yml配置文件中定义，且被volumeMounts挂载即可，如下： - name: linuxea-
2023-07-16
此前在存储卷类型中介绍过pvc，以及其他的存储卷类型，本节笔记介绍pvc和nfs的使用PVC在pod中只需要定义存储卷，定义时只需要说明需要用到的大小，这个类型就是pvcl类型存储卷而pvc存储卷必须与当前名称空间中的pvc，建立直接绑定关系，而pvc必须与pv建立绑定关系，而pv则是某个真正存储设
2023-07-16
在之前的描述中，我们知道pv和pvc在使用中存在一种问题。pvc申请的的大小并不意味着就有符合pvc申请条件的pv。之前有意设定了符合pvc条件的pv，并成功的被pod绑定所使用。StorageClassk8s也考虑到这种情况，于是有意的设计了一种工作逻辑，能够让pvc在申请pv时候，借助存储类--
2023-07-16
在之前ConfigMap介绍中，我们知道ConfigMap存在的目的并不是为pod提供存储空间来用的，而是给用户提供从集群外部向pod内部应用注入配置信息，本篇笔记简单介绍如何注入一些配置信息，发分别是环境变量和文件的方式。在configMap中，会用到configMapKeyRef和secretK
2023-07-16
在之前的ingress的tomcat https中已经使用过secret，secret适用于密钥文件，密码等。secret也有很多类型generic：通用的，保存密码tls：保存私钥和证书docker-registry：docker的认证信息：当up一个容器的时候，首选会检查本地是否有这个镜象，如果
2023-07-16
在之前，我们知道应用程序分为两类，一种是有状态，一种无状态。无状态的有nginx等。有状态的居多。如：redis,mysql,zook集群等，其中一些不单单有主从状态，更有启动顺序等的区分。这时候可使用statefulse，但是statefulse在完成一些配置的时候仍然是非常麻烦的，很多时候需要手
2023-07-16
在前面的一节中了解过SatefulSet控制器. 在看看如何创建satefulset，在创建之前，先准备好pv以便于使用VolumeClaimTemplate创建PV尽管使用VolumeClaimTemplate会自动创建pvc并且绑定pv，但是pv在这里仍然需要自己手动创建(如果你有动态供给的话另
2023-07-16
kubernetes上运行着众多的应用，特别是无状态的应用，更甚有一些核心的数据。对于这些数据的访问或者管理，并不是任何人可以随意的管理使用的。因此，kubernetes对于整个系统的认证，授权，以及后续的访问控制做了非常紧密和精心的设计。通常，客户端通过客户端工具kubectl来访问kuberne
2023-07-16
在kubernets上有一些服务和客户端需要与api server交涉，并且集群内部会运行类似的pod资源，这些资源是需要访问api server的 ，如: CoreDNS,以及dashboarddashboard提供一个web界面来管理kubernetes，通过service暴漏到外部，通过浏览器
2023-07-16
RBAC是基于角色的访问控制。Api server的客户端在认证时，如果要基于配置文件来保存配置信息，而并不是使用serviceAccount使用token认证，就应该配置为一个配置文件。事实上，kubenetes中大大多数组件要连接api server都需要认证，这些都可以算作客户端。这些组件能够
2023-07-16
之前我们知道kubernetes的授权是用插件来实现，并且支持很多插件，并且支持很多插件同时使用，且只要通过其中一个授权检查通过则不会在进行其他插件进行检查，而后由准入控制插件后续检查。授权插件常用有四个：节点Node，ABAC属性访问控制，RBAC，Webhook回掉机制实现授权、RBACRBAC
2023-07-16
不管是role，rolebinding还是clusterRole，clusterRolebinding都是资源清单中的标准资源我们创建linuxea-readpod和linuxea-cluster-read分别示例RBAC对权限的控制，图示如下：可以使用kubectl create role --h
2023-07-16
延续上一篇Role和Cluster Role示例,其中绑定都是role绑定rolebinding，clusterrole绑定clusterrolebinding，现在使用rolebinding绑定clusterrole，这样以来权限就会降级到rolebinding所在的权限我们先切换到kuberne
2023-07-16
dashboard也是做为kubernetes核心附件存在，这种附件还有就是作为名称解析和服务发现的coredns，通常系统部署后会自动安装。Dashboard在新的版本里面有这复杂的权限检查机制在使用kubeadm安装的RBAC默认强制启用的，而Dashboard接口是管理整个集群的接口，认证管理
2023-07-16