1. 通过KubeKey去安装K8S和KubeSphere
- 安装流程参考KubeSphere官网提供的教程:https://www.kubesphere.io/zh/docs/v4.1/03-installation-and-upgrade/02-install-kubesphere/02-install-kubernetes-and-kubesphere/
- K8S文档:https://kubernetes.io/zh-cn/docs/home/。
- KubeKey的文档Github地址:https://github.com/kubesphere/kubekey/blob/master/README_zh-CN.md。
- KubeKey的Github地址:https://github.com:kubesphere/kubekey.git
1.1 所有K8S节点安装提前执行操作
首先,在安装KubeKey之前,我们需要在K8S的所有节点上安装一些必须的依赖,比如K8S集群有三台节点node1
、node2
、node3
,需要在这三台机器上同时执行。
sudo apt install socat conntrack ebtables ipset -y
下面是安装K8S过程中,需要开放的一些防火墙端口,对于云服务器,则需要在云厂商的控制台当中放行下面这些端口。
|services|protocol|action|start port|end port|comment
|—|—|—|—|—|—|
ssh|TCP|allow|22|
etcd|TCP|allow|2379|2380|
apiserver|TCP|allow|6443|
calico|TCP|allow|9099|9100|
bgp|TCP|allow|179||
nodeport|TCP|allow|30000|32767|
master|TCP|allow|10250|10258|
dns|TCP|allow|53|
dns|UDP|allow|53|
local-registry|TCP|allow|5000||offline environment|
local-apt|TCP|allow|5080||offline environment|
rpcbind|TCP|allow|111|| use NFS
ipip|IPENCAP / IPIP|allow| | |calico needs to allow the ipip protocol
上面的操作都需要在所有的节点上进行操作。对于下面提到的操作,都只需要在1台节点上执行就行。
1.2 安装KubeKey(简称KK)
我们如下的命令去下载KubeKey,并给KK加上执行权限。
curl -sfL https://get-kk.kubesphere.io | sh -
sudo chmod +x kk
在给KK加上执行权限之后,我们可以通过如下的命令,去生成一个KK的config-sample配置文件,其中v1.27.4是要安装的K8S版本,可以把它换成你想要安装的K8S版本。
./kk create config --with-kubernetes v1.27.4
1.3 使用KK生成模板文件并完成自定义配置
使用kk create config
命令之后,会生成下面这样的config-sample.yml
的配置文件
kind: Cluster
metadata:
name: sample
spec:
hosts:
- {name: node1, address: 172.16.0.2, internalAddress: 172.16.0.2, user: ubuntu, password: "Qcloud@123"}
- {name: node2, address: 172.16.0.3, internalAddress: 172.16.0.3, user: ubuntu, password: "Qcloud@123"}
roleGroups:
etcd:
- node1
control-plane:
- node1
worker:
- node1
- node2
controlPlaneEndpoint:
## Internal loadbalancer for apiservers
# internalLoadbalancer: haproxy
domain: lb.kubesphere.local
address: ""
port: 6443
kubernetes:
version: v1.27.4
clusterName: cluster.local
autoRenewCerts: true
containerManager: containerd
etcd:
type: kubekey
network:
plugin: calico
kubePodsCIDR: 10.233.64.0/18
kubeServiceCIDR: 10.233.0.0/18
## multus support. https://github.com/k8snetworkplumbingwg/multus-cni
multusCNI:
enabled: false
registry:
privateRegistry: ""
namespaceOverride: ""
registryMirrors: []
insecureRegistries: []
addons: []
其中,我们一定需要修改的地方是下面这些:
spec:
hosts:
- {name: node1, address: 172.16.0.2, internalAddress: 172.16.0.2, user: ubuntu, password: "Qcloud@123"}
- {name: node2, address: 172.16.0.3, internalAddress: 172.16.0.3, user: ubuntu, password: "Qcloud@123"}
roleGroups:
etcd:
- node1
control-plane:
- node1
worker:
- node1
- node2
对于spec.hosts
配置,主要是配置K8S集群的各个节点,name
用于指定节点的名称,address和internalAdress用于指定节点的IP地址,内网的情况,配置成为一样就行,user
和password
(如果是使用SSH私钥的方式,需要指定user
和privateKeyPath
参数,privateKeyPath
指定私钥存放的位置)是登录该目标服务器的密码的情况,因为KK需要登录目标服务器去完成K8S集群的自动配置。
spec:
hosts:
- {name: node1, address: 10.0.0.95, internalAddress: 10.0.0.95, user: root, password: "..."}
- {name: node2, address: 10.0.0.97, internalAddress: 10.0.0.97, user: root, password: "..."}
- {name: node3, address: 10.0.0.152, internalAddress: 10.0.0.152, user: root, password: "..."}
roleGroups当中的相关配置说明:
roleGroups.control-plane
用于指定K8S集群的控制平面需要安装在哪个节点,也就是指定Master节点。roleGroups.ectd
用于指定K8S集群的控制平面中的Etcd需要安装在哪个节点(通常是Master节点,也可以独立部署到其他节点)。roleGroups.worker
则用于配置K8S集群的Worker节点(Node节点)。Worker节点其实对应的也就是用于K8S进行Pod的调度的机器,比如我希望K8S管理的Pod,可以从node1和node2两台机器上去启动容器,那么我就在这里指定worker
为node1和node2。
roleGroups:
etcd:
- node1
control-plane:
- node1
worker:
- node1
- node2
- node3
关于KK的更多配置参考
https://www.kubesphere.io/zh/docs/v4.1/03-installation-and-upgrade/02-install-kubesphere/02-install-kubernetes-and-kubesphere/
1.4 使用配置的KubeKey配置文件创建K8S集群。
接着,我们使用刚刚的KK的配置文件,基于KK去创建K8S集群。
我们首先添加KKZONE
环境变量指定区域为中国,不然可能因为Github和Google的限制导致网速慢,还会下载失败。
export KKZONE=cn
指定好区域之后,我们就可以使用下面的命令,基于KubeKey
去创建K8S集群。
# 创建K8S集群
./kk create cluster -f config-sample.yaml
在这个过程中,KK会自动下载K8S需要的各种依赖。当看到下面的提示语之后,说明我们的K8S集群已经创建好。
19:13:36 CST Pipeline[CreateClusterPipeline] execute successfully
Installation is complete.
Please check the result using the command:
kubectl get pod -A
在主节点执行如下命令,可以查看我们创建的K8S集群运行的POD情况。
kubectl get pod -A
命令执行结果如下:
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-6d7dfcb56d-5hd47 1/1 Running 0 58s
kube-system calico-node-fjnn6 1/1 Running 0 58s
kube-system calico-node-lzmh5 1/1 Running 0 58s
kube-system calico-node-tbpgg 1/1 Running 0 58s
kube-system coredns-76b9f7d479-2x5jt 1/1 Running 0 67s
kube-system coredns-76b9f7d479-jcrhv 1/1 Running 0 67s
kube-system kube-apiserver-node1 1/1 Running 0 83s
kube-system kube-controller-manager-node1 1/1 Running 0 85s
kube-system kube-proxy-dd4nc 1/1 Running 0 67s
kube-system kube-proxy-fwnm2 1/1 Running 0 59s
kube-system kube-proxy-pscwm 1/1 Running 0 61s
kube-system kube-scheduler-node1 1/1 Running 0 84s
kube-system nodelocaldns-4dw6n 1/1 Running 0 67s
kube-system nodelocaldns-4mngt 1/1 Running 0 59s
kube-system nodelocaldns-9cmkj 1/1 Running 0 61s
1.5 安装KubeSphere管理页面
可以使用下面的命令,去安装KubeSphere。
helm upgrade --install -n kubesphere-system --create-namespace ks-core https://charts.kubesphere.io/main/ks-core-1.1.3.tgz --debug --wait
如果访问DockerHub出现问题,下载镜像失败,可以在上面的命令的基础上加上如下的参数信息
--set global.imageRegistry=swr.cn-southwest-2.myhuaweicloud.com/ks
--set extension.imageRegistry=swr.cn-southwest-2.myhuaweicloud.com/ks
如果出现如下的提示信息,则说明KubeSphere安装成功。
NOTES:
Thank you for choosing KubeSphere Helm Chart.
Please be patient and wait for several seconds for the KubeSphere deployment to complete.
1. Wait for Deployment Completion
Confirm that all KubeSphere components are running by executing the following command:
kubectl get pods -n kubesphere-system
2. Access the KubeSphere Console
Once the deployment is complete, you can access the KubeSphere console using the following URL:
http://10.0.0.95:30880
3. Login to KubeSphere Console
Use the following credentials to log in:
Account: admin
Password: P@88w0rd
NOTE: It is highly recommended to change the default password immediately after the first login.
For additional information and details, please visit https://kubesphere.io.
提示你可以在30880端口访问页面,通过访问主节点的30880端口,通过账号admin
和密码P@88w0rd
,可以进入KubeSphere管理页面。
2. Harbor私服镜像仓库安装
Harbor用于存放私服Docker镜像,进行服务发布时,需要从Harbor镜像仓库当中拉取镜像,构建容器并完成服务的发布。
2.1 安装本地的Harbor镜像仓库
Harbor安装,下载地址如下:https://github.com/goharbor/harbor/releases/
。
上面是Github页面,可以选择右边的harbor-online-installer-v1.10.19.tgz
在线版本或者是harbor-offline-installer-v1.10.19.tgz
离线版本进行安装。这里推荐使用offline离线版本进行安装,因为Harbor在线版本需要在线下载依赖可能遇到网速问题,离线版本是包当中已经带了所有的Harbor相关的依赖。
下载完成Harbor之后,我们通过解压并执行安装脚本的方式,去安装Harbor。
tar -xvzf harbor-offline-installer-v1.10.19.tgz
进入到harbor/
目录下,可以看到Harbor的配置文件harbor.yml
,我们可能需要进行一些自定义的配置才能启动Harbor。
# Configuration file of Harbor
# The IP address or hostname to access admin UI and registry service.
# DO NOT use localhost or 127.0.0.1, because Harbor needs to be accessed by external clients.
hostname: xxx.xxx.com
# http related config
http:
# port for http, default is 80. If https enabled, this port will redirect to https port
port: 84
# https related config
# https:
# https port for harbor, default is 443
# port: 444
# The path of cert and key files for nginx
# certificate: /your/certificate/path
# private_key: /your/private/key/path
# Uncomment external_url if you want to enable external proxy
# And when it enabled the hostname will no longer used
# external_url: https://reg.mydomain.com:8433
# The initial password of Harbor admin
# It only works in first time to install harbor
# Remember Change the admin password from UI after launching Harbor.
harbor_admin_password: Harbor12345
# Harbor DB configuration
database:
# The password for the root user of Harbor DB. Change this before any production use.
password: root123
# The maximum number of connections in the idle connection pool. If it <=0, no idle connections are retained.
max_idle_conns: 50
# The maximum number of open connections to the database. If it <= 0, then there is no limit on the number of open connections.
# Note: the default number of connections is 100 for postgres.
max_open_conns: 100
# The default data volume
data_volume: /data
# Harbor Storage settings by default is using /data dir on local filesystem
# Uncomment storage_service setting If you want to using external storage
# storage_service:
# # ca_bundle is the path to the custom root ca certificate, which will be injected into the truststore
# # of registry's and chart repository's containers. This is usually needed when the user hosts a internal storage with self signed certificate.
# ca_bundle:
# # storage backend, default is filesystem, options include filesystem, azure, gcs, s3, swift and oss
# # for more info about this configuration please refer https://docs.docker.com/registry/configuration/
# filesystem:
# maxthreads: 100
# # set disable to true when you want to disable registry redirect
# redirect:
# disabled: false
# Clair configuration
clair:
# The interval of clair updaters, the unit is hour, set to 0 to disable the updaters.
updaters_interval: 12
jobservice:
# Maximum number of job workers in job service
max_job_workers: 10
notification:
# Maximum retry count for webhook job
webhook_job_max_retry: 10
chart:
# Change the value of absolute_url to enabled can enable absolute url in chart
absolute_url: disabled
# Log configurations
log:
# options are debug, info, warning, error, fatal
level: info
# configs for logs in local storage
local:
# Log files are rotated log_rotate_count times before being removed. If count is 0, old versions are removed rather than rotated.
rotate_count: 50
# Log files are rotated only if they grow bigger than log_rotate_size bytes. If size is followed by k, the size is assumed to be in kilobytes.
# If the M is used, the size is in megabytes, and if G is used, the size is in gigabytes. So size 100, size 100k, size 100M and size 100G
# are all valid.
rotate_size: 200M
# The directory on your host that store log
location: /var/log/harbor
# Uncomment following lines to enable external syslog endpoint.
# external_endpoint:
# # protocol used to transmit log to external endpoint, options is tcp or udp
# protocol: tcp
# # The host of external endpoint
# host: localhost
# # Port of external endpoint
# port: 5140
#This attribute is for migrator to detect the version of the .cfg file, DO NOT MODIFY!
_version: 1.10.0
# Uncomment external_database if using external database.
# external_database:
# harbor:
# host: harbor_db_host
# port: harbor_db_port
# db_name: harbor_db_name
# username: harbor_db_username
# password: harbor_db_password
# ssl_mode: disable
# max_idle_conns: 2
# max_open_conns: 0
# clair:
# host: clair_db_host
# port: clair_db_port
# db_name: clair_db_name
# username: clair_db_username
# password: clair_db_password
# ssl_mode: disable
# notary_signer:
# host: notary_signer_db_host
# port: notary_signer_db_port
# db_name: notary_signer_db_name
# username: notary_signer_db_username
# password: notary_signer_db_password
# ssl_mode: disable
# notary_server:
# host: notary_server_db_host
# port: notary_server_db_port
# db_name: notary_server_db_name
# username: notary_server_db_username
# password: notary_server_db_password
# ssl_mode: disable
# Uncomment external_redis if using external Redis server
# external_redis:
# host: redis
# port: 6379
# password:
# # db_index 0 is for core, it's unchangeable
# registry_db_index: 1
# jobservice_db_index: 2
# chartmuseum_db_index: 3
# clair_db_index: 4
# Uncomment uaa for trusting the certificate of uaa instance that is hosted via self-signed cert.
# uaa:
# ca_file: /path/to/ca
# Global proxy
# Config http proxy for components, e.g. http://my.proxy.com:3128
# Components doesn't need to connect to each others via http proxy.
# Remove component from `components` array if want disable proxy
# for it. If you want use proxy for replication, MUST enable proxy
# for core and jobservice, and set `http_proxy` and `https_proxy`.
# Add domain to the `no_proxy` field, when you want disable proxy
# for some special registry.
proxy:
http_proxy:
https_proxy:
# no_proxy endpoints will appended to 127.0.0.1,localhost,.local,.internal,log,db,redis,nginx,core,portal,postgresql,jobservice,registry,registryctl,clair,chartmuseum,notary-server
no_proxy:
components:
- core
- jobservice
- clair
在Harbor配置当中,我们需要配置Harbor的HTTP和HTTPS的相关配置:
- 在hostname出填写域名配置
- 在
http.port
当中配置HTTP服务启动的端口号。 - (选填,在需要使用Harbor的HTTPS时才需要配置)在
https.port
当中配置HTTPS服务启动的端口号,https.certificate
当中配置HTTPS的证书所在的地址,https.private_key
当中配置HTTPS的私钥所在的地址。
hostname: xxx.xxx.com
http:
port: 84
https:
port: 1443
certificate: /your/certificate/path
private_key: /your/private/key/path
在配置好Harbor配置文件之后,我们通过如下的命令安装脚本install
,去安装好Harbor,并启动Harbor。
./install.sh
如果想要启动/关闭Harbor
,我们可以通过如下的命令去进行操作。
# 启动habor
docker-compose up -d
# 关闭habor
docker-compose down
接着通过docker ps
可以查看运行的容器情况,在这里这里可以找到Harbor
的相关的运行的容器。
root@ecm-4fe6:~/tools/habor/harbor# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fc68663a0c75 goharbor/harbor-jobservice:v1.10.19 "/harbor/harbor_jobs…" About a minute ago Up 58 seconds (healthy) harbor-jobservice
294528f398de goharbor/nginx-photon:v1.10.19 "nginx -g 'daemon of…" About a minute ago Up 58 seconds (healthy) 0.0.0.0:84->8080/tcp, [::]:84->8080/tcp nginx
43b3bcdf06cb goharbor/harbor-core:v1.10.19 "/harbor/harbor_core" About a minute ago Up About a minute (healthy) harbor-core
1a7ae4231f1c goharbor/harbor-portal:v1.10.19 "nginx -g 'daemon of…" About a minute ago Up About a minute (healthy) 8080/tcp harbor-portal
9078844124c4 goharbor/harbor-db:v1.10.19 "/docker-entrypoint.…" About a minute ago Up About a minute (healthy) 5432/tcp harbor-db
72f314603d16 goharbor/registry-photon:v1.10.19 "/home/harbor/entryp…" About a minute ago Up About a minute (healthy) 5000/tcp registry
76680fc53a23 goharbor/harbor-registryctl:v1.10.19 "/home/harbor/start.…" About a minute ago Up About a minute (healthy) registryctl
253c363e7abd goharbor/redis-photon:v1.10.19 "redis-server /etc/r…" About a minute ago Up About a minute (healthy) 6379/tcp redis
643df5ccdcb1 goharbor/harbor-log:v1.10.19 "/bin/sh -c /usr/loc…" About a minute ago Up About a minute (healthy) 127.0.0.1:1514->10514/tcp harbor-log
Harbor的HTTP服务,在84端口启动,访问{ip}:84进入Harbor管理如下的Harbor后台页面。
接着使用账号密码登录,账号admin,默认密码在harbor.yml配置文件当中,首次登录需要修改Harbor密码。
2.2 通过已有Nginx服务代理Harbor服务请求(选做)
对于Harbor的SSL配置,如果在已有Nginx服务当中配置有HTTPS的SSL证书,我们也可以使用反向代理,将Harbor的84端口通过Nginx进行反向代理暴露到外部,我们添加如下的配置去进行反向代理。编辑Nginx服务器配置,使用命令如下:sudo vim /etc/nginx/sites-available/default
。
server {
listen 188 default_server;
listen [::]:188 default_server;
# SSL configuration
listen 8443 ssl default_server;
listen [::]:8443 ssl default_server;
ssl_certificate /root/ssl/wanna1314y.top_bundle.crt;
# 私钥文件的相对路径或绝对路径
ssl_certificate_key /root/ssl/wanna1314y.top.key;
ssl_session_timeout 5m;
# 配置加密套件,写法遵循 openssl 标准。
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
# 协议配置
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name wanna1314y.top;
location / {
proxy_pass http://127.0.0.1:84;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
我们想要将Nginx通过1443端口对外HTTPS暴露,代理从而内部的http://127.0.0.1:84
接口(Harbor服务)。(需要修改ssl_certificate和ssl_certificate_key,指定SSL证书所在的位置)
通过如下这样的配置,在防火墙(安全组)当中放开1443端口,接着就可以访问我们的1443端口基于HTTPS协议的方式去访问Harbor啦,地址参考:https://wanna1314y.top:1443
。
2.3 将本地Docker镜像推送到Harbor仓库
我们下面以构建并推送一个nginx镜像举例。我们首先需要拉取(或者构建一个镜像)
docker pull nginx
我们通过docker images
可以查看本地仓库都有哪些镜像,比如我们上面pull了一个nginx镜像,那么这里就可以看到之前我们拉取到的nginx镜像。
root@ecm-4fe6:~# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest f02a7f566928 3 weeks ago 117MB
goharbor/chartmuseum-photon v1.10.19 222e01a0c4f8 6 weeks ago 177MB
goharbor/redis-photon v1.10.19 8abbe7c628db 6 weeks ago 148MB
goharbor/clair-adapter-photon v1.10.19 1f856e990872 6 weeks ago 81.9MB
goharbor/clair-photon v1.10.19 0ccce83decfa 6 weeks ago 181MB
goharbor/notary-server-photon v1.10.19 fe7aae6b169d 6 weeks ago 119MB
goharbor/notary-signer-photon v1.10.19 ca2cfca2baf4 6 weeks ago 116MB
goharbor/harbor-registryctl v1.10.19 fc4186073195 6 weeks ago 109MB
goharbor/registry-photon v1.10.19 b5dc0c94b21e 6 weeks ago 92.1MB
goharbor/nginx-photon v1.10.19 4b6a3a04832e 6 weeks ago 122MB
goharbor/harbor-log v1.10.19 08fa03691200 6 weeks ago 133MB
goharbor/harbor-jobservice v1.10.19 1b5aca7f4143 6 weeks ago 97.8MB
goharbor/harbor-core v1.10.19 85627df50bd9 6 weeks ago 91.6MB
goharbor/harbor-portal v1.10.19 e72ed626ae05 6 weeks ago 130MB
goharbor/harbor-db v1.10.19 c038e2ac8cb3 6 weeks ago 213MB
goharbor/prepare v1.10.19 3abb30b0d645 6 weeks ago 170MB
接着我们需要给镜像打TAG。
# 完整命令格式
# 这里的{repository}/{project}是该镜像在本地的镜像名称,{tag}就是该依赖在本地的版本(默认是latest)
# 这里的{remoteRepository}/{remoteProject}对应的是远程仓库的地址和远程仓库的项目名称, {imageName}是镜像名称(比如nginx),{remoteTag}则是需要推送到远程的版本(默认是latest)
docker tag {repository}/{project}:{tag} {remoteRepository}/{remoteProject}/{imageName}:{remoteTag}
# 我们这里需要将本地的nginx推送到远程仓库(127.0.0.1:84),远程仓库的项目是library(Harbor仓库默认就是library),
# 本地镜像tag为nginx:latest, 远程的镜像tag是127.0.0.1:84/library/nginx:latest
docker tag nginx:latest 127.0.0.1:84/library/nginx:latest
# 如果是版本是latest, 那么可以省略掉, 例如上面的命令可以简写成为下面的
docker tag nginx 127.0.0.1:84/library/nginx
接着使用docker push
尝试推送到本地私服
docker push 127.0.0.1:84/library/nginx
docker push
执行结果如下:
Using default tag: latest
The push refers to repository [127.0.0.1:84/library/nginx]
c13ac49c8f3c: Preparing
5f70bf18a086: Preparing
813c9361c9a1: Preparing
352667057690: Preparing
9f29839ee958: Preparing
8895fa2456bd: Waiting
2ceb45dcc459: Waiting
98b5f35ea9d3: Waiting
denied: requested access to the resource is denied
推送过程中,发现denied: requested access to the resource is denied
,原因在于我们没有权限,我们需要首先使用docker login 127.0.0.1:84
命令,先登录Harbor
账号。
Username: admin
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credential-stores
Login Succeeded
中间过程会让提示用户名和密码,看到Login Succeeded
之后,我们重新推送镜像。
root@ecm-4fe6:~# docker push 127.0.0.1:84/library/nginx
Using default tag: latest
The push refers to repository [127.0.0.1:84/library/nginx]
c13ac49c8f3c: Pushed
5f70bf18a086: Pushed
813c9361c9a1: Pushed
352667057690: Pushed
9f29839ee958: Pushed
8895fa2456bd: Pushed
2ceb45dcc459: Pushed
98b5f35ea9d3: Pushed
latest: digest: sha256:6df8098f056f25e26890a11bbe06fa59a6fd035691d1b2747ff192e1a04b4e0b size: 1986
看到上述的提示说明我们已经成功推送到本地Harbor
私服。
3. KubeSphere接入Harbor镜像仓库拉取镜像并完成项目的部署
3.1 创建K8S项目Namespace
KubeSphere接入Harbor,进入到KubeSphere之后,在左侧的项目一栏,选择创建,去新建一个项目(或者说叫namespace),我们这里起名叫wanna-project
。
需要注意的是:K8S当中,所有的资源都是namespace层面隔离的。
3.2 在"配置-保密字典"当中新建镜像仓库
创建完成项目之后,我们可以选择创建一个保密字典,在保密字典当中,新建一个Harbor仓库地址。进入到保密字典后,给仓库名称起一个名,比如wanna-project-habor
,并选择我们上面创建的namespace(项目),需要注意的是必须选择同一个namespace!
接着就到了下面这个页面,可以填写Harbor机器的服务器地址,授权用户名和密码。
需要注意的是,这里的服务器地址如果填HTTP地址和IP地址,看着都有点问题,我们在这里需要填写Harbor的HTTPS的地址,如果没有HTTPS,需要去弄一下服务器的SSL配置才能好,不然一致pull镜像都无法pull成功。
3.3 通过KubeSpere部署项目并允许外网访问
(1)通过KubeSphere创建K8S工作负载用于Pod(容器)的部署
在保密字典(Secret)当中配置好Harbor仓库的之后,我们可以KubeSphere当中创建创建一个工作负载(Deployment),用于进行容器的发布和运行。
首先,指定一个负载的名称,需要注意的是:项目(namespace)必须选用和上面我们指定的同一个项目"wanna-project”。
接着,下一步进入的是下面的页面,选择运行的配置信息,首先选择Habor仓库地址,从Harbor仓库选择合适的镜像,比如"library/nginx:latest”,并选择容器的运行端口,接着下一步。
其中我们运行的端口号可以选择使用默认的镜像端口号。
需要注意的是:如果指定的项目namespace不对那么这里是没有我们新建的Harbor仓库地址的,必须指定上面我们创建Harbor仓库时指定的namespace项目。
下面两项(“存储设置"和"高级设置”),我们暂时不需要进行配置,接着我们继续下一步。
再下一步,选择我们刚刚创建的负载,就到了下面这样的页面,它是根据Harbor仓库当中拉取到的镜像完成容器的部署。
最终呈现的结果就是如下,提示容器已经部署完成。(如果部署过程中出现了什么问题,可以在"事件"处查看到可能的原因,最常见的原因就是镜像拉取失败。)
(2) 创建K8S服务(Service)允许POD以NodePort方式暴露端口号允许服务外网访问
让容器可以外网访问,需要创建一个服务,我们起个名叫nginx-service,同样选中我们之前创建的namespace项目。
接着,在"服务设置"这里,绑定工作负载为刚刚创建出来的nginx的负载,并选择容器绑定的端口号,下一步即可。
接着,我们在"高级设置"配置当中,设置允许"外部访问”,并指定访问模式为NodePort,也就是创建一个虚拟的节点,通过这个节点对外统一暴露端口号。
接着,我们就可以看到,在服务页面,新增了我们刚刚创建出来的服务,并且给出了端口号为31123,接着,我们就可以通过NodeIP,再加上端口号去访问。
比如我们讲Pod调度到Node2,我们就需要通过Node2的IP+端口号的方式去访问,可以看到如下的页面,至此我们的Nginx就部署完成。
默认情况,NodePort的端口号是从30000-33767这个范围随机分配的,也可以通过yaml配置文件去修改NodePort的端口号。
在KubeSphere当中,默认情况,没有提供指定端口号的方式,但是我们可以通过修改我们自定义的Service的yaml文件去实现。
进入到下面这样的yaml配置文件页面,我们需要修改的是nodePort部分,这部分是对外Node暴露的端口号。
修改nodePort(从31000修改到32000)之后,我们回到服务首页可以发现,端口已经修改成功,此时我们通过32000端口就能正常访问到该服务,也就是说这里修改的nodePort是可以实时生效的,支持动态热配置。
(3) 安装Ingress网关处理Service服务流量
可以基于下面的命令执行资源清单yaml,去进行安装Ingress,但是往往会遇到镜像无法下载问题。
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
原因是镜像仓库用的是registry.k8s.io
,因为外网的原因可能无法导致访问,比如registry.k8s.io/ingress-nginx/kube-webhook-certgen
资源就无法访问。
此时我们就需要下载https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
配置文件,并替换其中的镜像仓库,才能成功按照Ingress。
比如我们这里换成本地的Harbor镜像仓库。
image: wanna1314y.top:1443/library/kube-webhook-certgen:latest
我们参照上面已经构建好的Nginx的服务,构建一个新的Halo的服务,下面演示将会涉及到使用HaloService进行演示。
我们通过K8S的资源清单yaml,去创建一条ingress的路由配置,映射各个域名以及各个域名下的路径的访问是怎么进行访问的,并通过kubectl
去进行应用kubectl apply -f ingress-config.yaml
。
在下面的配置当中,我们无脑将请求打到HaloService。
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: nginx
namespace: wanna-project
spec:
controller: k8s.io/ingress-nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: wanna-project-nginx-ingress
namespace: wanna-project
spec:
ingressClassName: nginx
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: halo-service # 指定要路由到的 Service 名称
port:
number: 8090 # 这里需要配置Service暴露的端口号, 而不是NodePort的端口号
下面的配置当中,通过域名的方式,限定域名的映射关系,比如限制wanna1314y.top
才能访问,则通过IP等方式访问请求该服务的接口都不通。
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: nginx
namespace: wanna-project
spec:
controller: k8s.io/ingress-nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: wanna-project-nginx-ingress
namespace: wanna-project
spec:
ingressClassName: nginx
rules:
- host: wanna1314y.top # 指定当访问这个域名时才将请求交给下面的Service
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: halo-service # 指定要路由到的 Service 名称
port:
number: 8090 # 这里需要配置Service暴露的端口号, 而不是NodePort的端口号
通过KubeSphere查看Ingress Service启动的端口号,在31888端口启动。(可以修改运行的端口号)
接着,我们在31888端口尝试访问,则可以访问到Halo的页面。
其实Ingress服务本质上也是一个Deployment+Service的架构,Ingress的Service也是通过NodePort的方式暴露的端口号,但是我们之前部署的Halo的Service和Nginx的Service,也能以NodePort的方式暴露端口号,那么为什么还需要有Ingress的存在呢?
原因在于,我们这里部署的HaloService和NginxService,对应的其实应该是微服务架构当中的多个微服务,最佳实践是多个微服务最终以Gateway网关的方式(比如SpringCloudGateway),统一对外暴露接口。
- 在传统的微服务架构当中,SpringCloudGateway的承担着网关的架构,通过Eureka,zookeeper,Nacos等作为注册中心,提供服务发现的功能,在网关当中通过注册中心,按照服务的名称实现服务的路由以及负载均衡。
- 在K8S架构当中,Ingress则承担着的网关这样的作用,通过Ingress可以基于Service实现服务发现,Ingress可以将请求打到Service,Service则可以将请求派发给具体的Pod从而实现负载均衡。
评论