AI 助理
备案控制台
开发者社区 云原生 文章 正文

纯手工搭建k8s集群-(三)认证授权和服务发现

2018-12-14 1221
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云解析DNS，个人版 1个月
云解析 DNS，旗舰版 1个月
公共DNS（含HTTPDNS解析），每月1000万次HTTP解析
简介： 1. 理解认证授权 1.1 为什么要认证 想理解认证，我们得从认证解决什么问题、防止什么问题的发生入手。 防止什么问题呢？是防止有人入侵你的集群，root你的机器后让我们集群依然安全吗？不是吧，root都到手了，那就为所欲为，防不胜防了。

1. 理解认证授权

1.1 为什么要认证


想理解认证，我们得从认证解决什么问题、防止什么问题的发生入手。
防止什么问题呢？是防止有人入侵你的集群，root你的机器后让我们集群依然安全吗？不是吧，root都到手了，那就为所欲为，防不胜防了。
其实网络安全本身就是为了解决在某些假设成立的条件下如何防范的问题。比如一个非常重要的假设就是两个节点或者ip之间的通讯网络是不可信任的，可能会被第三方窃取，也可能会被第三方篡改。就像我们上学时候给心仪的女孩传纸条，传送的过程可能会被别的同学偷看，甚至内容可能会从我喜欢你修改成我不喜欢你了。当然这种假设不是随便想出来的，而是从网络技术现状和实际发生的问题中发现、总结出来的。kubernetes的认证也是从这个问题出发来实现的。

1.2 概念梳理

为了解决上面说的问题，kubernetes并不需要自己想办法，毕竟是网络安全层面的问题，是每个服务都会遇到的问题，业内也有成熟的方案来解决。这里我们一起了解一下业内方案和相关的概念。

1.3 什么是授权

授权的概念就简单多了，就是什么人具有什么样的权限，一般通过角色作为纽带把他们组合在一起。也就是一个角色一边拥有多种权限，一边拥有多个人。这样就把人和权限建立了一个关系。

2. kubernetes的认证授权

Kubernetes集群的所有操作基本上都是通过kube-apiserver这个组件进行的，它提供HTTP RESTful形式的API供集群内外客户端调用。需要注意的是：认证授权过程只存在HTTPS形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiserver，那么是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用HTTP，集群外部就使用HTTPS，这样既增加了安全性，也不至于太复杂。
对APIServer的访问要经过的三个步骤，前面两个是认证和授权，第三个是 Admission Control，它也能在一定程度上提高安全性，不过更多是资源管理方面的作用。

2.1 kubernetes的认证

kubernetes提供了多种认证方式，比如客户端证书、静态token、静态密码文件、ServiceAccountTokens等等。你可以同时使用一种或多种认证方式。只要通过任何一个都被认作是认证通过。下面我们就认识几个常见的认证方式。

  • 客户端证书认证
    客户端证书认证叫作TLS双向认证，也就是服务器客户端互相验证证书的正确性，在都正确的情况下协调通信加密方案。
    为了使用这个方案，api-server需要用–client-ca-file选项来开启。
  • 引导Token
    当我们有非常多的node节点时，手动为每个node节点配置TLS认证比较麻烦，这时就可以用到引导token的认证方式，前提是需要在api-server开启 experimental-bootstrap-token-auth 特性，客户端的token信息与预先定义的token匹配认证通过后，自动为node颁发证书。当然引导token是一种机制，可以用到各种场景中。
  • Service Account Tokens 认证
    有些情况下，我们希望在pod内部访问api-server，获取集群的信息，甚至对集群进行改动。针对这种情况，kubernetes提供了一种特殊的认证方式：Service Account。 Service Account 和 pod、service、deployment 一样是 kubernetes 集群中的一种资源，用户也可以创建自己的 Service Account。
    ServiceAccount 主要包含了三个内容：namespace、Token 和 CA。namespace 指定了 pod 所在的 namespace，CA 用于验证 apiserver 的证书，token 用作身份验证。它们都通过 mount 的方式保存在 pod 的文件系统中。

2.2 kubernetes的授权

在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
目前 Kubernetes 中有一系列的鉴权机制，因为Kubernetes社区的投入和偏好，相对于其它鉴权机制而言，RBAC是更好的选择。具体RBAC是如何体现在kubernetes系统中的我们会在后面的部署中逐步的深入了解。

2.3 kubernetes的AdmissionControl

AdmissionControl – 准入控制本质上为一段准入代码，在对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。这个准入代码在api-server中，而且必须被编译到二进制文件中才能被执行。
在对集群进行请求时，每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的error信息。
常用组件（控制代码）如下：

  • AlwaysAdmit：允许所有请求
  • AlwaysDeny：禁止所有请求，多用于测试环境
  • ServiceAccount：它将serviceAccounts实现了自动化，它会辅助serviceAccount做一些事情，比如如果pod没有serviceAccount属性，它会自动添加一个default，并确保pod的serviceAccount始终存在
  • LimitRanger：他会观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中。如果在kubernetes中使用LimitRange对象，则必须使用这个插件。
  • NamespaceExists：它会观察所有的请求，如果请求尝试创建一个不存在的namespace，则这个请求被拒绝。

3. 环境准备

3.1 停止原有kubernetes相关服务

开始之前我们要先把基础版本的集群停掉，包括service，deployments，pods以及运行的所有kubernetes组件

#删除services
$ kubectl delete services nginx-service

#删除deployments
$ kubectl delete deploy kubernetes-bootcamp
$ kubectl delete deploy nginx-deployment

#停掉worker节点的服务
$ service kubelet stop && rm -fr /var/lib/kubelet/*
$ service kube-proxy stop && rm -fr /var/lib/kube-proxy/*
$ service kube-calico stop

#停掉master节点的服务
$ service kube-calico stop
$ service kube-scheduler stop
$ service kube-controller-manager stop
$ service kube-apiserver stop
$ service etcd stop && rm -fr /var/lib/etcd/*

3.2 生成配置（所有节点）

跟基础环境搭建一样，我们需要生成kubernetes-with-ca的所有相关配置文件

$ cd ~/kubernetes-starter
#按照配置文件的提示编辑好配置
$ vi config.properties
#生成配置
$ ./gen-config.sh with-ca

3.3 安装cfssl（所有节点）

cfssl是非常好用的CA工具，我们用它来生成证书和秘钥文件
安装过程比较简单，如下：

#下载
$ wget -q --show-progress --https-only --timestamping \
 https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
 https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 #修改为可执行权限
$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64
#移动到bin目录
$ mv cfssl_linux-amd64 /usr/local/bin/cfssl
$ mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
#验证
$ cfssl version

3.4 生成根证书（主节点）

根证书是证书信任链的根，各个组件通讯的前提是有一份大家都信任的证书（根证书），每个人使用的证书都是由这个根证书签发的。

#所有证书相关的东西都放在这
$ mkdir -p /etc/kubernetes/ca
#准备生成证书的配置文件
$ cp ~/kubernetes-starter/target/ca/ca-config.json /etc/kubernetes/ca
$ cp ~/kubernetes-starter/target/ca/ca-csr.json /etc/kubernetes/ca
#生成证书和秘钥
$ cd /etc/kubernetes/ca
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
#生成完成后会有以下文件（我们最终想要的就是ca-key.pem和ca.pem，一个秘钥，一个证书）
$ ls
ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem

4. 改造etcd

4.1 准备证书

etcd节点需要提供给其他服务访问，就要验证其他服务的身份，所以需要一个标识自己监听服务的server证书，当有多个etcd节点的时候也需要client证书与etcd集群其他节点交互，当然也可以client和server使用同一个证书因为它们本质上没有区别。

#etcd证书放在这
$ mkdir -p /etc/kubernetes/ca/etcd
#准备etcd证书配置
$ cp ~/kubernetes-starter/target/ca/etcd/etcd-csr.json /etc/kubernetes/ca/etcd/
$ cd /etc/kubernetes/ca/etcd/ #使用根证书(ca.pem)签发etcd证书
$ cfssl gencert \
 -ca=/etc/kubernetes/ca/ca.pem \
 -ca-key=/etc/kubernetes/ca/ca-key.pem \
 -config=/etc/kubernetes/ca/ca-config.json \
 -profile=kubernetes etcd-csr.json | cfssljson -bare etcd
#跟之前类似生成三个文件etcd.csr是个中间证书请求文件，我们最终要的是etcd-key.pem和etcd.pem
$ ls
etcd.csr etcd-csr.json etcd-key.pem etcd.pem

4.2 改造etcd服务

建议大家先比较一下增加认证的etcd配置与原有配置的区别，做到心中有数。
可以使用命令比较：

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/etcd.service kubernetes-with-ca/master-node/etcd.service

更新etcd服务：

$ cp ~/kubernetes-starter/target/master-node/etcd.service /lib/systemd/system/
$ systemctl daemon-reload
$ service etcd start
#验证etcd服务（endpoints自行替换）
$ ETCDCTL_API=3 etcdctl \
 --endpoints=https://192.168.1.102:2379 \ --cacert=/etc/kubernetes/ca/ca.pem \
 --cert=/etc/kubernetes/ca/etcd/etcd.pem \
 --key=/etc/kubernetes/ca/etcd/etcd-key.pem \
 endpoint health

5. 改造api-server

5.1 准备证书

#api-server证书放在这，api-server是核心，文件夹叫kubernetes吧，如果想叫apiserver也可以，不过相关的地方都需要修改哦
$ mkdir -p /etc/kubernetes/ca/kubernetes
#准备apiserver证书配置
$ cp ~/kubernetes-starter/target/ca/kubernetes/kubernetes-csr.json /etc/kubernetes/ca/kubernetes/
$ cd /etc/kubernetes/ca/kubernetes/ #使用根证书(ca.pem)签发kubernetes证书
$ cfssl gencert \
 -ca=/etc/kubernetes/ca/ca.pem \
 -ca-key=/etc/kubernetes/ca/ca-key.pem \
 -config=/etc/kubernetes/ca/ca-config.json \
 -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
#跟之前类似生成三个文件kubernetes.csr是个中间证书请求文件，我们最终要的是kubernetes-key.pem和kubernetes.pem
$ ls
kubernetes.csr kubernetes-csr.json kubernetes-key.pem kubernetes.pem

5.2 改造api-server服务

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/master-node/kube-apiserver.service kubernetes-with-ca/master-node/kube-apiserver.service

生成token认证文件

#生成随机token
$ head -c 16 /dev/urandom | od -An -t x | tr -d ' ' 8afdf3c4eb7c74018452423c29433609 #按照固定格式写入token.csv，注意替换token内容
$ echo "8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,\"system:kubelet-bootstrap\"" > /etc/kubernetes/ca/kubernetes/token.csv

更新api-server服务

$ cp ~/kubernetes-starter/target/master-node/kube-apiserver.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-apiserver start

#检查日志
$ journalctl -f -u kube-apiserver

6. 改造controller-manager

controller-manager一般与api-server在同一台机器上，所以可以使用非安全端口与api-server通讯，不需要生成证书和私钥。

6.1 改造controller-manager服务

查看diff

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-controller-manager.service kubernetes-with-ca/master-node/kube-controller-manager.service

更新controller-manager服务

$ cp ~/kubernetes-starter/target/master-node/kube-controller-manager.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-controller-manager start

#检查日志
$ journalctl -f -u kube-controller-manager

7. 改造scheduler

scheduler一般与apiserver在同一台机器上，所以可以使用非安全端口与apiserver通讯。不需要生成证书和私钥。

7.1 改造scheduler服务

查看diff
比较会发现两个文件并没有区别，不需要改造

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-scheduler.service kubernetes-with-ca/master-node/kube-scheduler.service

启动服务

$ service kube-scheduler start
#检查日志
$ journalctl -f -u kube-scheduler

8. 改造kubectl

8.1 准备证书

#kubectl证书放在这，由于kubectl相当于系统管理员，我们使用admin命名
$ mkdir -p /etc/kubernetes/ca/admin
#准备admin证书配置 - kubectl只需客户端证书，因此证书请求中 hosts 字段可以为空
$ cp ~/kubernetes-starter/target/ca/admin/admin-csr.json /etc/kubernetes/ca/admin/
$ cd /etc/kubernetes/ca/admin/ #使用根证书(ca.pem)签发admin证书
$ cfssl gencert \
 -ca=/etc/kubernetes/ca/ca.pem \
 -ca-key=/etc/kubernetes/ca/ca-key.pem \
 -config=/etc/kubernetes/ca/ca-config.json \
 -profile=kubernetes admin-csr.json | cfssljson -bare admin
#我们最终要的是admin-key.pem和admin.pem
$ ls
admin.csr admin-csr.json admin-key.pem admin.pem

8.2 配置kubectl

#指定apiserver的地址和证书位置（ip自行修改）
$ kubectl config set-cluster kubernetes \
 --certificate-authority=/etc/kubernetes/ca/ca.pem \
 --embed-certs=true \
 --server=https://192.168.1.102:6443 #设置客户端认证参数，指定admin证书和秘钥
$ kubectl config set-credentials admin \
 --client-certificate=/etc/kubernetes/ca/admin/admin.pem \
 --embed-certs=true \
 --client-key=/etc/kubernetes/ca/admin/admin-key.pem
#关联用户和集群
$ kubectl config set-context kubernetes \
 --cluster=kubernetes --user=admin
#设置当前上下文
$ kubectl config use-context kubernetes

#设置结果就是一个配置文件，可以看看内容
$ cat ~/.kube/config

验证master节点

#可以使用刚配置好的kubectl查看一下组件状态
$ kubectl get componentstatus
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}

9. 改造calico-node

9.1 准备证书

后续可以看到calico证书用在四个地方：

  • calico/node 这个docker 容器运行时访问 etcd 使用证书
  • cni 配置文件中，cni 插件需要访问 etcd 使用证书
  • calicoctl 操作集群网络时访问 etcd 使用证书
  • calico/kube-controllers 同步集群网络策略时访问 etcd 使用证书
    #calico证书放在这
$ mkdir -p /etc/kubernetes/ca/calico
#准备calico证书配置 - calico只需客户端证书，因此证书请求中 hosts 字段可以为空
$ cp ~/kubernetes-starter/target/ca/calico/calico-csr.json /etc/kubernetes/ca/calico/
$ cd /etc/kubernetes/ca/calico/ #使用根证书(ca.pem)签发calico证书
$ cfssl gencert \
 -ca=/etc/kubernetes/ca/ca.pem \
 -ca-key=/etc/kubernetes/ca/ca-key.pem \
 -config=/etc/kubernetes/ca/ca-config.json \
 -profile=kubernetes calico-csr.json | cfssljson -bare calico
#我们最终要的是calico-key.pem和calico.pem
$ ls
calico.csr calico-csr.json calico-key.pem calico.pem

9.2 改造calico服务

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/all-node/kube-calico.service kubernetes-with-ca/all-node/kube-calico.service

通过diff会发现，calico多了几个认证相关的文件：
/etc/kubernetes/ca/ca.pem
/etc/kubernetes/ca/calico/calico.pem
/etc/kubernetes/ca/calico/calico-key.pem
由于calico服务是所有节点都需要启动的，大家需要把这几个文件拷贝到每台服务器上

更新calico服务

$ cp ~/kubernetes-starter/target/all-node/kube-calico.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-calico start

#验证calico（能看到其他节点的列表就对啦）
$ calicoctl node status

10. 改造kubelet

我们这里让kubelet使用引导token的方式认证，所以认证方式跟之前的组件不同，它的证书不是手动生成，而是由工作节点TLS BootStrap 向api-server请求，由主节点的controller-manager 自动签发。

10.1 创建角色绑定（主节点）

引导token的方式要求客户端向api-server发起请求时告诉他你的用户名和token，并且这个用户是具有一个特定的角色：system:node-bootstrapper，所以需要先将 bootstrap token 文件中的 kubelet-bootstrap 用户赋予这个特定角色，然后 kubelet 才有权限发起创建认证请求。
在主节点执行下面命令

#可以通过下面命令查询clusterrole列表
$ kubectl -n kube-system get clusterrole

#可以回顾一下token文件的内容
$ cat /etc/kubernetes/ca/kubernetes/token.csv
8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,"system:kubelet-bootstrap" #创建角色绑定（将用户kubelet-bootstrap与角色system:node-bootstrapper绑定）
$ kubectl create clusterrolebinding kubelet-bootstrap \
 --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

10.2 创建bootstrap.kubeconfig（工作节点）

这个配置是用来完成bootstrap token认证的，保存了像用户，token等重要的认证信息，这个文件可以借助kubectl命令生成：（也可以自己写配置）

#设置集群参数(注意替换ip)
$ kubectl config set-cluster kubernetes \
 --certificate-authority=/etc/kubernetes/ca/ca.pem \
 --embed-certs=true \
 --server=https://192.168.1.102:6443 \ --kubeconfig=bootstrap.kubeconfig
#设置客户端认证参数(注意替换token)
$ kubectl config set-credentials kubelet-bootstrap \
 --token=8afdf3c4eb7c74018452423c29433609 \
 --kubeconfig=bootstrap.kubeconfig
#设置上下文
$ kubectl config set-context default \
 --cluster=kubernetes \
 --user=kubelet-bootstrap \
 --kubeconfig=bootstrap.kubeconfig
#选择上下文
$ kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#将刚生成的文件移动到合适的位置
$ mv bootstrap.kubeconfig /etc/kubernetes/

10.3 准备cni配置

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/10-calico.conf kubernetes-with-ca/worker-node/10-calico.conf

copy配置

$ cp ~/kubernetes-starter/target/worker-node/10-calico.conf /etc/cni/net.d/

10.4 改造kubelet服务

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/kubelet.service kubernetes-with-ca/worker-node/kubelet.service

更新服务

$ cp ~/kubernetes-starter/target/worker-node/kubelet.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kubelet start

#启动kubelet之后到master节点允许worker加入(批准worker的tls证书请求) #--------*在主节点执行*---------
$ kubectl get csr|grep 'Pending' | awk '{print $1}'| xargs kubectl certificate approve
#----------------------------- #检查日志
$ journalctl -f -u kubelet

11. 改造kube-proxy

11.1 准备证书

#proxy证书放在这
$ mkdir -p /etc/kubernetes/ca/kube-proxy

#准备proxy证书配置 - proxy只需客户端证书，因此证书请求中 hosts 字段可以为空。 #CN 指定该证书的 User 为 system:kube-proxy，预定义的 ClusterRoleBinding system:node-proxy 将User system:kube-proxy 与 Role system:node-proxier 绑定，授予了调用 kube-api-server proxy的相关 API 的权限
$ cp ~/kubernetes-starter/target/ca/kube-proxy/kube-proxy-csr.json /etc/kubernetes/ca/kube-proxy/
$ cd /etc/kubernetes/ca/kube-proxy/ #使用根证书(ca.pem)签发calico证书
$ cfssl gencert \
 -ca=/etc/kubernetes/ca/ca.pem \
 -ca-key=/etc/kubernetes/ca/ca-key.pem \
 -config=/etc/kubernetes/ca/ca-config.json \
 -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy
#我们最终要的是kube-proxy-key.pem和kube-proxy.pem
$ ls
kube-proxy.csr kube-proxy-csr.json kube-proxy-key.pem kube-proxy.pem

11.2 生成kube-proxy.kubeconfig配置

#设置集群参数（注意替换ip）
$ kubectl config set-cluster kubernetes \
 --certificate-authority=/etc/kubernetes/ca/ca.pem \
 --embed-certs=true \
 --server=https://192.168.1.102:6443 \ --kubeconfig=kube-proxy.kubeconfig
#置客户端认证参数
$ kubectl config set-credentials kube-proxy \
 --client-certificate=/etc/kubernetes/ca/kube-proxy/kube-proxy.pem \
 --client-key=/etc/kubernetes/ca/kube-proxy/kube-proxy-key.pem \
 --embed-certs=true \
 --kubeconfig=kube-proxy.kubeconfig
#设置上下文参数
$ kubectl config set-context default \
 --cluster=kubernetes \
 --user=kube-proxy \
 --kubeconfig=kube-proxy.kubeconfig
#选择上下文
$ kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig
#移动到合适位置
$ mv kube-proxy.kubeconfig /etc/kubernetes/kube-proxy.kubeconfig

11.3 改造kube-proxy服务

查看diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/kube-proxy.service kubernetes-with-ca/worker-node/kube-proxy.service

经过diff你应该发现kube-proxy.service没有变化

启动服务

#如果之前的配置没有了，可以重新复制一份过去
$ cp ~/kubernetes-starter/target/worker-node/kube-proxy.service /lib/systemd/system/
$ systemctl daemon-reload

#安装依赖软件
$ apt install conntrack

#启动服务
$ service kube-proxy start
#查看日志
$ journalctl -f -u kube-proxy

12. 改造kube-dns

kube-dns有些特别，因为它本身是运行在kubernetes集群中，以kubernetes应用的形式运行。所以它的认证授权方式跟之前的组件都不一样。它需要用到service account认证和RBAC授权。
service account认证：
每个service account都会自动生成自己的secret，用于包含一个ca，token和secret，用于跟api-server认证
RBAC授权：
权限、角色和角色绑定都是kubernetes自动创建好的。我们只需要创建一个叫做kube-dns的 ServiceAccount即可，官方现有的配置已经把它包含进去了。

12.1 准备配置文件

我们在官方的基础上添加的变量，生成适合我们集群的配置。直接copy就可以啦

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/services/kube-dns.yaml kubernetes-with-ca/services/kube-dns.yaml

大家可以看到diff只有一处，新的配置没有设定api-server。不访问api-server，它是怎么知道每个服务的cluster ip和pod的endpoints的呢？这就是因为kubernetes在启动每个服务service的时候会以环境变量的方式把所有服务的ip，端口等信息注入进来。

12.2 创建kube-dns

$ kubectl create -f ~/kubernetes-starter/target/services/kube-dns.yaml
#看看启动是否成功
$ kubectl -n kube-system get pods

13. 再试牛刀

终于，安全版的kubernetes集群我们部署完成了。
下面我们使用新集群先温习一下之前学习过的命令，然后再认识一些新的命令，新的参数，新的功能。

本文转自kubernetes中文社区-纯手工搭建k8s集群-(三)认证授权和服务发现

文章标签：
容器服务Kubernetes版
云解析DNS
密钥管理服务
日志服务
容器
Kubernetes
Perl
数据安全/隐私保护
网络安全
关键词：
容器服务Kubernetes版集群
容器服务Kubernetes版服务发现
容器服务Kubernetes版授权
容器服务Kubernetes版认证
容器服务Kubernetes版搭建
相关实践学习
容器服务Serverless版ACK Serverless 快速入门：在线魔方应用部署和监控
通过本实验，您将了解到容器服务Serverless版ACK Serverless 的基本产品能力，即可以实现快速部署一个在线魔方应用，并借助阿里云容器服务成熟的产品生态，实现在线应用的企业级监控，提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程，本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术，这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时，本课程也会向您介绍可以采取的工具、方法和可操作步骤，以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后，您将能够： 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
店家小二
目录
相关文章
shiningrise
|
1月前
|
Kubernetes 微服务 容器
Aspire项目发布到远程k8s集群
Aspire项目发布到远程k8s集群
shiningrise
434 2
Aspire项目发布到远程k8s集群
shiningrise
|
1月前
|
Kubernetes Cloud Native 微服务
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
shiningrise
230 3
嘟嘟嘟嘟嘟嘟
|
2天前
|
Kubernetes 应用服务中间件 调度
如何在Kubernetes集群中配置跨可用区的Pod调度
如何在Kubernetes集群中配置跨可用区的Pod调度
嘟嘟嘟嘟嘟嘟
14 7
1941623231718325
|
12天前
|
负载均衡 Kubernetes 算法
K8s服务发现与负载均衡的技术探索
【7月更文挑战第15天】K8s通过Service资源对象和kube-proxy组件实现了高效、灵活的服务发现和负载均衡机制。通过合理选择Service类型、优化kube-proxy配置以及使用Ingress进行高级路由，可以确保应用在K8s集群中高效、可靠地运行。随着云原生技术的不断发展，K8s的服务发现和负载均衡机制也将不断完善和优化，为更多场景提供强大的支持。
1941623231718325
35 9
技术君
|
10天前
|
Kubernetes API 索引
带你读《阿里云产品六月刊》——五、ACK 集群适配和发布 Kubernetes 1.30 版本
ACK 集群适配和发布 Kubernetes 1.30 版本
技术君
59 2
游客uul6wusao3sds
|
17天前
|
存储 Kubernetes 监控
Kubernetes 集群的持续性能优化策略
【5月更文挑战第70天】 随着容器化技术的普及，Kubernetes 已成为管理微服务架构的首选平台。然而，在大规模部署和长期运行过程中，集群往往会遭遇性能瓶颈，影响服务的响应速度和稳定性。本文将探讨针对 Kubernetes 集群的性能优化策略，包括资源调度优化、网络延迟降低、存储效率提升及监控与日志分析等方面，旨在为运维工程师提供一套系统化的持续优化方法，确保集群性能的长期稳定。
游客uul6wusao3sds
53 10
weixin_836869520
|
29天前
|
Kubernetes 网络协议 Docker
k8s 开船记-故障公告：自建 k8s 集群在阿里云上大翻船
k8s 开船记-故障公告：自建 k8s 集群在阿里云上大翻船
weixin_836869520
75 2
weixin_836869520
|
29天前
|
Kubernetes Ubuntu jenkins
超详细实操教程！在现有K8S集群上安装JenkinsX，极速提升CI/CD体验！
超详细实操教程！在现有K8S集群上安装JenkinsX，极速提升CI/CD体验！
weixin_836869520
42 1
www.qqkjcj.com
|
29天前
|
Kubernetes 应用服务中间件 nginx
K8s高可用集群二进制部署-V1.20
2.4 部署Etcd集群 以下在节点1上操作，为简化操作，待会将节点1生成的所有文件拷贝到节点2和节点3. 1. 创建工作目录并解压二进制包 mkdir /opt/etcd/{bin,cfg,ssl} -p tar zxvf etcd-v3.4.9-linux-amd64.tar.gz mv etcd-v3.4.9-linux-amd64/{etcd,etcdctl} /opt/etcd/bin/
www.qqkjcj.com
51 1
嘟嘟嘟嘟嘟嘟
|
8天前
|
缓存 Kubernetes Serverless
阿里云云效操作报错合集之AppStack资源池添加外部k8s集群时报错，该如何解决
本合集将整理呈现用户在使用过程中遇到的报错及其对应的解决办法，包括但不限于账户权限设置错误、项目配置不正确、代码提交冲突、构建任务执行失败、测试环境异常、需求流转阻塞等问题。阿里云云效是一站式企业级研发协同和DevOps平台，为企业提供从需求规划、开发、测试、发布到运维、运营的全流程端到端服务和工具支撑，致力于提升企业的研发效能和创新能力。
嘟嘟嘟嘟嘟嘟
25 0

热门文章

最新文章

  • 1
    Kubernetes全方位日志采集与管理的最佳实践 资料下载
  • 2
    阿里云Kubernetes实战1–集群搭建与服务暴露
  • 3
    K8s为什么需要calico? calico 原理深入理解.
  • 4
    在K8S上部署可扩展的基于Occlum的安全推理实例
  • 5
    k8s部署 coredns 组件
  • 6
    Kubernetes-Service介绍(三)-Ingress(含最新版安装踩坑实践)
  • 7
    k8s教程（service篇）-pod的dns域名
  • 8
    安装kubernetes
  • 9
    Kubernetes - 4.5 Workload - StatefulSet
  • 10
    从零开始，在 Kubernetes 上玩转 Erda（三）
  • 1
    K8S常见的持久化(存储)方案用法详解
    214
  • 2
    构建高效自动化运维体系：Ansible与Kubernetes的协同策略
    118
  • 3
    K8S二进制部署详解，一文教会你部署高可用K8S集群（二）
    165
  • 4
    构建高效自动化运维体系：Ansible与Kubernetes的协同实践
    93
  • 5
    K8S二进制部署详解，一文教会你部署高可用K8S集群（一）
    345
  • 6
    构建高效自动化运维体系：Ansible与Kubernetes的完美结合
    46
  • 7
    构建可扩展的微服务架构：使用Docker和Kubernetes
    30
  • 8
    一文教会你，如何通过kubeadm，在生产环境部署K8S高可用集群（二）
    97
  • 9
    一文教会你，如何通过kubeadm，在生产环境部署K8S高可用集群（一）
    888
  • 10
    kubernetes最小调度单元pod详解（二）
    16

    • 相关课程

    更多
  • 阿里云 EMR on ACK 实战
  • 阿里云K8S微服务部署案例
  • Kubernetes极速入门
  • Serverless 容器从入门到精通: - Serverless Kubernetes
  • Kubernetes云原生管理实践
  • Kubernetes入门

    • 相关电子书

    更多
  • ACK 云原生弹性方案—云原生时代的加速器
  • ACK集群类型选择最佳实践
  • 企业运维之云原生和Kubernetes 实战

    • 相关实验场景

    更多
  • 快速搭建高可用网站服务
  • 容器服务Serverless版ACK Serverless 快速入门：在线魔方应用部署和监控
  • 使用资源编排自动化开通云服务

    • 推荐镜像

    更多
  • kubernetes
  • pouch
  • docker-ce
    • 下一篇
    通义千问API入门教程