K8S API服务器

---

一、与API服务器交互

1.主机访问K8S API服务器

[root@k8s-node1 k8s-study]# kubectl cluster-info
Kubernetes master is running at https://192.168.43.3:6443
KubeDNS is running at https://192.168.43.3:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

直接通过curl https://192.168.43.3:6443 -k
会报无权限的错误
因为服务器使用https协议并且需要授权。

解决
通过Kubectl proxy 访问API服务器
后面直接通过curl https://192.168.43.3:6443

2.pod访问K8S API服务器

a.运行一个简单的pod尝试与API服务器通信

准备一个curl镜像 运行一个什么都不做的pod（sleep），然后通过k exec 在容器内运行，尝试使用curl 访问K8S服务器

apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - name: main
    image: tutum/curl
    command: ["sleep", "999999"]

[root@k8s-node1 k8s-study]# k get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   10d

在每个pod中都配置了对应的环境变量，在容器内可以获取到api服务器的ip地址和port

root@curl:/# env | grep KUBERNETES_SERVICE
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT_HTTPS=443

通过curl https://kubernetes

root@curl:/# curl https://kubernetes
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

b.验证服务器身份

有一个Secret被自动创建，并挂载到每个容器的/var/run/secrets/kubernetes.io/serviceaccount/目录下。

root@curl:/# ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt	namespace  token

可以观察到里面有一个ca.crt的CA证书。我们需要检查服务器的证书是否是由CA签发的。curl 允许使用-cacert选项指定CA证书。

root@curl:/# curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

服务器使用了我们信任的CA签名的证书，但是被拒绝了Forbidden，我们需要获得API服务器的授权。
为了获得授权，需要token，凭证可以使用之前提到的defalt-token产生，同时凭证可以被存放在secret卷的token文件中。

可以用凭证访问API服务器，第一步，将凭证挂载到环境变量中
将ca写入环境变量

root@curl:/# export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

root@curl:/# TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

root@curl:/# curl -H "Authorization: Bearer $TOKEN" https://kubernetes
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
    "/apis/admissionregistration.k8s.io",
    "/apis/admissionregistration.k8s.io/v1",
    "/apis/admissionregistration.k8s
    。。。。。。。。。。。。。。。。。。。。。

3.default-token

1.对任意pod使用命令

[root@k8s-node1 k8s-study]# k get pod
Volumes:
  default-token-h4t7h:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-h4t7h
    Optional:    false

可以观察到每个pod挂载了一个secret卷。

[root@k8s-node1 k8s-study]# k describe secrets
Name:         default-token-h4t7h
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: default
              kubernetes.io/service-account.uid: 5e348780-f680-4c93-97e6-196c642b0a2e

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImNfeW5OMlpKei1FYldBZ25SRUxGdHFLenJIcXg2cFNjallCUFNodHRoSFkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4taDR0N2giLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjVlMzQ4NzgwLWY2ODAtNGM5My05N2U2LTE5NmM2NDJiMGEyZSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.pvXsZYBXgVXvalgjnPkhasS_wJcbjurGlCBK0cRKduRHIi9vw-NXdgDic6B-0lfn6QISIklUR6aOp3xKiHub9GOZ4Cp-pMi1VYyb5dz4D0-54gXN0Ewt21x4N5jU5vz9RnGZE2ROpVi7zAfosKrk_dtzv2cn2rsEmGsVvq4Ez1BoVeKr60WVt200SCp55I8ZzpcJvTW1X7gcB7wFFPA0XKMJAdEFYVp56UyrezRPMrrFeDcsToCpnDXtd32-Rqq-pXygXMb7yblToSYvPu-Ji_gOA6elbH209Cj6_dqq6PbkKSPP-XVtKNcbEvLmlqbg7PGEmtqDZFT7EzuI_LXjsQ

secret包含三个条目——ca.crt、namespace和token,包含了从pod内部访问K8S的API服务器所需的全部信息。

4.通过ambassador容器简化与api的交互

上述的问题，当在pod内部使用https、证书和授权凭证等，还是比较复杂的。
主机可以通过kube proxy代理，代理来处理授权、加密和服务器验证。同样，在pod中也可以这么做。

a.ambassador容器模式介绍

在这种模式下，运行在著容器中的应用不是直接与api服务器进行交互，而是通过http协议与ambassador连接，并有ambassador通过https协议来连接api服务器。

因为pod中共享回送的网络接口，所以我们的应用可以通过本地的端口来访问代理。

二、K8S的RABC

1.详细看图总结

a.单命名空间访问

1. 每个命名空间中有一个默认的serviceAccount

2. serviceAccount挂着一个secrets，secrets保存着crt，token信息

3. 当foo命名空间的pod创建时候，如果未指定serviceAccount则使用默认的default-token

4. pod中的xxx目录挂载着default-token的信息，当pod访问K8S资源时候需要带ca证书和token对k8S的api访问。

5. 当无权list svc的时候，需要创建一个role角色规定可以list 本命名空间中的svc。

6. Role的角色绑定rolebing到serviceAccount。

7. 当foo中的pod list svc的时候，带上绑定好角色的sa给K8S的RABC认证机制验证，然后通过访问。

b.跨命名空间访问

1.当bar命名空间需要访问foo命名空间的svc的时候，需要将foo中的role绑定到bar中的serviceAccount。2.这样bar中的serviceAccount就绑定了foo中的list foo中的svc的权限3.这样bar中的pod就可以通过该sergiceAccount list foo中的svc

总结

提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。