K8S 基础概念备忘

configmap

configmap是k8s的一个配置管理组件，可以将配置以key-value的形式传递，通常用来保存不需要加密的配置信息，加密信息则需用到Secret，主要用来应对以下场景：

1. 使用k8s部署应用，当你将应用配置写进代码中，就会存在一个问题，更新配置时也需要打包镜像，configmap可以将配置信息和docker镜像解耦。
2. 使用微服务架构的话，存在多个服务共用配置的情况，如果每个服务中单独一份配置的话，那么更新配置就很麻烦，使用configmap可以友好的进行配置共享。

其次，configmap可以用来保存单个属性，也可以用来保存配置文件。

给容器内应用程序传递参数的实现方式:

　　1. 将配置文件直接打包到镜像中，但这种方式不推荐使用，因为修改配置不够灵活。

　　2. 通过定义Pod清单时，指定自定义命令行参数，即设定 args:["命令参数"]，这种也

　　 可在启动Pod时，传参来修改Pod的应用程序的配置文件.

　　3. 使用环境变量来给Pod中应用传参修改配置

　　 但要使用此种方式，必须符合以下前提之一:

　　 1) Pod中的应用程序必须是Cloud Native的应用程序，即支持直接通过环境变量来加载配置信息。

　　 2) 通过定义Entrypoint脚本的预处理变量来修改Pod中应用程序的配置文件，这些Entrypoint脚本

　　　 可以使用set，sed，grep等工具来实现修改，但也要确保容器中有这些工具。

　　4.存储卷: 我们可将配置信息直接放到存储卷中，如PV中,Pod启动时，自动挂载存储卷到配置文件目录，

　　 来实现给Pod中应用提供不同的配置。

　　5.configMap 或 secret

Annotation（注解）

Annotation与Label类似，也使用key/value键值对的形式进行定义。

Label具有严格的命名规则，它定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selector。

Annotation则是用户任意定义的“附加”信息，以便于外部工具进行查找。

用Annotation来记录的信息包括：

build信息、release信息、Docker镜像信息等，例如时间戳、release id号、PR号、镜像hash值、docker registry地址等；

日志库、监控库、分析库等资源库的地址信息；

程序调试工具信息，例如工具名称、版本号等；

团队的联系信息，例如电话号码、负责人名称、网址等。

cluster ip /node ip/pod ip

Kubernetes集群里有三种IP地址，分别如下：

• Node IP：Node节点的IP地址，即物理网卡的IP地址。
• Pod IP：Pod的IP地址，即docker容器的IP地址，此为虚拟IP地址。
• Cluster IP：Service的IP地址，此为虚拟IP地址。

可以是物理机的IP（也可能是虚拟机IP）。每个Service都会在Node节点上开通一个端口，外部可以通过NodeIP:NodePort即可访问Service里的Pod,和我们访问服务器部署的项目一样，IP:端口/项目名

在kubernetes查询Node IP

1.kubectl get nodes

2.kubectl describe node nodeName

3.显示出来的InternalIP就是NodeIP

Pod IP是每个Pod的IP地址，他是Docker Engine根据docker网桥的IP地址段进行分配的，通常是一个虚拟的二层网络

同Service下的pod可以直接根据PodIP相互通信

不同Service下的pod在集群间pod通信要借助于 cluster ip

pod和集群外通信，要借助于node ip

Cluster IP是一个虚拟的IP，但更像是一个伪造的IP网络，原因有以下几点

Cluster IP仅仅作用于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址

Cluster IP无法被ping，他没有一个“实体网络对象”来响应

Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备通信的基础，并且他们属于Kubernetes集群这样一个封闭的空间。

在不同Service下的pod节点在集群间相互访问可以通过Cluster IP

三种IP网络间的通信

service地址和pod地址在不同网段，service地址为虚拟地址，不配在pod上或主机上，外部访问时，先到Node节点网络，再转到service网络，最后代理给pod网络。

Kubernetes在其所有节点上开放一个端口给外部访问（所有节点上都使用相同的端口号）， 并将传入的连接转发给作为Service服务对象的pod。这样我们的pod就可以被外部请求访问到

k8s暴露服务给外部访问有三种方式，NodePort、LoadBalane、Ingress三种暴露服务的方式，上图是用了NodePort的方式，缺点是服务一旦多起来，NodePort 在每个节点上开启的端口数量会极其庞大，难以维护

因为ClusterIP并不是传统意义上的一个IP地址，它本质上是由IP:Port组成的一个标识对，这个标识对是用在集群node节点的iptables里面的。在集群中创建一个type为ClusterIP的service时，会在本集群所有的node节点上添加一组iptables转发规则，该规则指定了匹配ClusterIP:Port的请求，会动态的转发到对应service的pod中去。所以，当集群内有请求发送到ClusterIP:Port的时候，并不会把ClusterIP作为数据包的目的地址去找路由，而是直接匹配iptables去做转发。既然ClusterIP无法被路由，iptables规则也只会在集群内部的node上创建，那么跨集群是没法进行ClusterIP间的通信的。

实现不同集群间的通信，正常的做法是用type为NodePort方式的服务暴露到node ip或直接用ingress实现。

使用Service Cluster IP和Port访问Service的客户端可以坐落在任意代理节点上，只能Cluster内部访问。外部要访问Service，我们就需要给Service外部访问IP。

K8S的 cluster IP所在网段由api-server的配置文件确定的。如果要修改也需要修改这个配置

headless service 不需要cluster ip ,直接以DNS方式直接记录PodIP

Pod创建后都会被分配一个dns记录，只要知道这个记录就可以访问到pod，可以用于statefull set对各个容器的访问和维护。

Namespace

你可以认为namespaces是你kubernetes集群中的虚拟化集群。在一个Kubernetes集群中可以拥有多个命名空间，它们在逻辑上彼此隔离。 他们可以为您和您的团队提供组织，安全甚至性能方面的帮助

serviceaccount

Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同
　　1.User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API而设计；
　　2.User account是跨namespace的，而service account则是仅局限它所在的namespace；
　　3.每个namespace都会自动创建一个default service account
　　4.Token controller检测service account的创建，并为它们创建secret
　　5.开启ServiceAccount Admission Controller后
       1.每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccout）
　　　　2.验证Pod引用的service account已经存在，否则拒绝创建
　　　　3.如果Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中
　　　　4.每个container启动后都会挂载该service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/　

pod

k8s最小调度单位，包涵一个初始容器和相关的实际容器。共享一组共同的资源，网络，PID，存储等。

deployments

定义多副本应用（POD）的对象。即定义了多个pod

deployment 的yaml属于典型的控制器模式，前半部分属于控制器定义，后半部分定义了被空控制对象（Pod ）

StatefulSet

使用pod模板创建Pod的时候，对Pod进行编号，按照编号逐一进行创建工作。创建出现问题的时候，同样按照原编号进行重建。主要用于多个有依赖关系的pod在deployment里面无法按照正确顺序启动的情况。

DaemonSet

在所有节点上运行有且仅有一个Pod的deployments,用于比如网络等agent这类pod。

job cronjob

就是任务和定时任务的Pod了，执行完不会被无限重启。

RBAC 授权控制

基于角色的权限控制，这个和其他的基于角色的权限控制没啥两样，就是定义好某个访问权限（在K8S里面就是对某个API对象的权限），然后再定义好用户（k8s里面内置的其实就是serviceaccount）,然后把权限和用户绑定起来。这个用户就能使用这些权限了。

cat >dash-user1.yaml <<END
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
END

比如dashboard的默认示例里面，就让我们创建了1个用户并和一个clusterrole绑定上了。

cat <dash-user2.yaml<<END 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard
END

通过查看系统的cluster-admin角色，发现这是个超级管理员权限了

kubectl describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]

然后通过命令获取token就可以登陆到dashboard了（当然还得kube-proxy）

kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"

浏览器访问

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/