Tự động thay đổi tỷ lệ là một tính năng trong OpenShift nơi các ứng dụng được triển khai có thể mở rộng quy mô và chìm khi có yêu cầu theo các thông số kỹ thuật nhất định. Trong ứng dụng OpenShift, tính năng autoscaling còn được gọi là pod autoscaling. Có hai kiểu mở rộng ứng dụng như sau.
Tỷ lệ theo chiều dọc
Chia tỷ lệ dọc là tất cả về việc tăng thêm ngày càng nhiều năng lượng cho một máy duy nhất, có nghĩa là thêm nhiều CPU và đĩa cứng. Đây là một phương pháp cũ của OpenShift hiện không được các bản phát hành OpenShift hỗ trợ.
Chia tỷ lệ ngang
Kiểu chia tỷ lệ này rất hữu ích khi có nhu cầu xử lý nhiều yêu cầu hơn bằng cách tăng số lượng máy.
Trong OpenShift, có hai phương pháp để bật tính năng mở rộng quy mô .
- Sử dụng tệp cấu hình triển khai
- Trong khi chạy hình ảnh
Sử dụng tệp cấu hình triển khai
Trong phương pháp này, tính năng chia tỷ lệ được bật thông qua tệp yaml cấu hình của người triển khai. Đối với điều này, lệnh OC tự động tỷ lệ được sử dụng với số lượng bản sao tối thiểu và tối đa, lệnh này cần chạy tại bất kỳ thời điểm nhất định nào trong cụm. Chúng ta cần một định nghĩa đối tượng để tạo autoscaler. Sau đây là một ví dụ về tệp định nghĩa pod autoscaler.
apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
name: database
spec:
scaleRef:
kind: DeploymentConfig
name: database
apiVersion: v1
subresource: scale
minReplicas: 1
maxReplicas: 10
cpuUtilization:
targetPercentage: 80
Khi chúng ta đã có tệp tại chỗ, chúng ta cần lưu nó với định dạng yaml và chạy lệnh sau để triển khai.
$ oc create –f <file name>.yamlTrong khi chạy hình ảnh
Người ta cũng có thể chỉnh tỷ lệ tự động mà không cần tệp yaml, bằng cách sử dụng lệnh oc tự động tỷ lệ sau trong dòng lệnh oc.
$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled
Lệnh này cũng sẽ tạo ra một loại tệp tương tự mà sau này có thể được sử dụng để tham khảo.
Chiến lược triển khai trong OpenShift
Chiến lược triển khai trong OpenShift xác định luồng triển khai với các phương pháp có sẵn khác nhau. Trong OpenShift, sau đây là các loại chiến lược triển khai quan trọng .
- Chiến lược cuộn
- Tạo lại chiến lược
- Chiến lược tùy chỉnh
Sau đây là một ví dụ về tệp cấu hình triển khai, được sử dụng chủ yếu để triển khai trên các nút OpenShift.
kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
name: "database"
spec:
template:
metadata:
labels:
name: "Database1"
spec:
containers:
- name: "vipinopenshifttest"
image: "openshift/mongoDB"
ports:
- containerPort: 8080
protocol: "TCP"
replicas: 5
selector:
name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
imageChangeParams:
automatic: true
containerNames:
- "vipinopenshifttest"
from:
kind: "ImageStreamTag"
name: "mongoDB:latest"
strategy:
type: "Rolling"
Trong tệp Deploymentconfig ở trên, chúng ta có chiến lược là Rolling.
Chúng ta có thể sử dụng lệnh OC sau để triển khai.
$ oc deploy <deployment_config> --latestChiến lược lăn bánh
Chiến lược cuộn được sử dụng để cập nhật hoặc triển khai luân phiên. Quá trình này cũng hỗ trợ các móc vòng đời, được sử dụng để đưa mã vào bất kỳ quá trình triển khai nào.
strategy:
type: Rolling
rollingParams:
timeoutSeconds: <time in seconds>
maxSurge: "<definition in %>"
maxUnavailable: "<Defintion in %>"
pre: {}
post: {}
Tạo lại chiến lược
Chiến lược triển khai này có một số tính năng cơ bản của chiến lược triển khai cuốn chiếu và nó cũng hỗ trợ móc vòng đời.
strategy:
type: Recreate
recreateParams:
pre: {}
mid: {}
post: {}
Chiến lược tùy chỉnh
Điều này rất hữu ích khi một người muốn cung cấp quy trình hoặc luồng triển khai của riêng mình. Tất cả các tùy chỉnh có thể được thực hiện theo yêu cầu.
strategy:
type: Custom
customParams:
image: organization/mongoDB
command: [ "ls -l", "$HOME" ]
environment:
- name: VipinOpenshiftteat
value: Dev1
OpenShift – Administration Quản trị
Trong chương này, chúng tôi sẽ đề cập đến các chủ đề như cách quản lý một nút, cấu hình tài khoản dịch vụ, v.v.
Cấu hình chính và nút
Trong OpenShift, chúng ta cần sử dụng lệnh start cùng với OC để khởi động một máy chủ mới. Trong khi khởi chạy một cái chính mới, chúng ta cần sử dụng cái chính cùng với lệnh bắt đầu, trong khi khi khởi động nút mới, chúng ta cần sử dụng nút cùng với lệnh bắt đầu. Để làm được điều này, chúng ta cần tạo các tệp cấu hình cho cái chính cũng như cho các nút. Chúng ta có thể tạo một tệp cấu hình cơ bản cho nút chính và nút bằng cách sử dụng lệnh sau.
Đối với tệp cấu hình chính
$ openshift start master --write-config = /openshift.local.config/masterĐối với tệp cấu hình nút
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>Khi chúng tôi chạy các lệnh sau, chúng tôi sẽ nhận được các tệp cấu hình cơ sở có thể được sử dụng làm điểm bắt đầu cho cấu hình. Sau đó, chúng ta có thể có cùng một tệp để khởi động các máy chủ mới.
apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
logoutURL: ""
masterPublicURL: https://172.10.12.1:7449
publicURL: https://172.10.2.2:7449/console/
servingInfo:
bindAddress: 0.0.0.0:7449
certFile: master.server.crt
clientCA: ""
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
bindAddress: 0.0.0.0:53
etcdClientInfo:
ca: ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.key
urls:
- https://10.0.2.15:4001
etcdConfig:
address: 10.0.2.15:4001
peerAddress: 10.0.2.15:7001
peerServingInfo:
bindAddress: 0.0.0.0:7001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
servingInfo:
bindAddress: 0.0.0.0:4001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
kubernetesStoragePrefix: kubernetes.io
kubernetesStorageVersion: v1
openShiftStoragePrefix: openshift.io
openShiftStorageVersion: v1
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: MasterConfig
kubeletClientInfo:
ca: ca.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key
port: 10250
kubernetesMasterConfig:
apiLevels:
- v1beta3
- v1
apiServerArguments: null
controllerArguments: null
masterCount: 1
masterIP: 10.0.2.15
podEvictionTimeout: 5m
schedulerConfigFile: ""
servicesNodePortRange: 30000-32767
servicesSubnet: 172.30.0.0/16
staticNodeNames: []
masterClients:
externalKubernetesKubeConfig: ""
openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
clusterNetworkCIDR: 10.1.0.0/16
hostSubnetLength: 8
networkPluginName: ""
serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
assetPublicURL: https://172.10.2.2:7449/console/
grantConfig:
method: auto
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
masterPublicURL: https://172.10.2.2:7449/
masterURL: https://172.10.2.2:7449/
sessionConfig:
sessionMaxAgeSeconds: 300
sessionName: ssn
sessionSecretsFile: ""
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
policyConfig:
bootstrapPolicyFile: policy.json
openshiftInfrastructureNamespace: openshift-infra
openshiftSharedResourcesNamespace: openshift
projectConfig:
defaultNodeSelector: ""
projectRequestMessage: ""
projectRequestTemplate: ""
securityAllocator:
mcsAllocatorRange: s0:/2
mcsLabelsPerProject: 5
uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
subdomain: router.default.svc.cluster.local
serviceAccountConfig:
managedNames:
- default
- builder
- deployer
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
servingInfo:
bindAddress: 0.0.0.0:8443
certFile: master.server.crt
clientCA: ca.crt
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 3600
Tệp cấu hình nút
allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
execHandlerName: native
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
mtu: 1450
networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig:
path: "/path/to/pod-manifest-file"
fileCheckIntervalSeconds: 30
servingInfo:
bindAddress: 0.0.0.0:10250
certFile: server.crt
clientCA: node-client-ca.crt
keyFile: server.key
volumeDirectory: /root/openshift.local.volumes
Đây là cách các tệp cấu hình nút trông như thế nào. Khi chúng ta đã có các tệp cấu hình này, chúng ta có thể chạy lệnh sau để tạo máy chủ chính và máy chủ nút.
$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml
Quản lý các nút
Trong OpenShift, chúng ta có tiện ích dòng lệnh OC, tiện ích này chủ yếu được sử dụng để thực hiện tất cả các hoạt động trong OpenShift. Chúng ta có thể sử dụng các lệnh sau để quản lý các nút.
Để liệt kê một nút
$ oc get nodes
NAME LABELS
node1.example.com kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com kubernetes.io/hostname = vklnld1447.int.example.com
Mô tả chi tiết về một nút
$ oc describe node <node name>Xóa một nút
$ oc delete node <node name>Liệt kê các nhóm trên một nút
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]Đánh giá nhóm trên một nút
$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]Xác thực cấu hình
Trong OpenShift master, có một máy chủ OAuth tích hợp, có thể được sử dụng để quản lý xác thực. Tất cả người dùng OpenShift đều nhận được mã thông báo từ máy chủ này, giúp họ giao tiếp với API OpenShift.
Có nhiều loại cấp độ xác thực khác nhau trong OpenShift, có thể được định cấu hình cùng với tệp cấu hình chính.
- Chấp nhận tất cả
- Phủ nhận tất cả
- HTPasswd
- LDAP
- Xác thực cơ bản
- Tiêu đề yêu cầu
Trong khi xác định cấu hình chính, chúng ta có thể xác định chính sách nhận dạng nơi chúng ta có thể xác định loại chính sách mà chúng ta muốn sử dụng.
Chấp nhận tất cả
Chấp nhận tất cả
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
Phủ nhận tất cả
Điều này sẽ từ chối quyền truy cập vào tất cả tên người dùng và mật khẩu.
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HTPasswd
HTPasswd được sử dụng để xác thực tên người dùng và mật khẩu so với mật khẩu tệp được mã hóa.
Để tạo một tệp được mã hóa, sau đây là lệnh.
$ htpasswd </path/to/users.htpasswd> <user_name>Sử dụng tệp được mã hóa.
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /path/to/users.htpasswd
Nhà cung cấp danh tính LDAP
Điều này được sử dụng để xác thực LDAP trong đó máy chủ LDAP đóng một vai trò quan trọng trong xác thực.
oauthConfig:
...
identityProviders:
- name: "ldap_authontication"
challenge: true
login: true
provider:
apiVersion: v1
kind: LDAPPasswordIdentityProvider
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- uid
bindDN: ""
bindPassword: ""
ca: my-ldap-ca-bundle.crt
insecure: false
url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"
Xác thực cơ bản
Điều này được sử dụng khi xác thực tên người dùng và mật khẩu được thực hiện dựa trên xác thực từ máy chủ đến máy chủ. Xác thực được bảo vệ trong URL cơ sở và được trình bày ở định dạng JSON.
oauthConfig:
...
identityProviders:
- name: my_remote_basic_auth_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: BasicAuthPasswordIdentityProvider
url: https://www.vklnld908.int.example.com/remote-idp
ca: /path/to/ca.file
certFile: /path/to/client.crt
keyFile: /path/to/client.key
Định cấu hình tài khoản dịch vụ
Tài khoản dịch vụ cung cấp một cách linh hoạt để truy cập API OpenShift, làm lộ tên người dùng và mật khẩu để xác thực.
Kích hoạt tài khoản dịch vụ
Tài khoản dịch vụ sử dụng một cặp khóa công khai và khóa riêng tư để xác thực. Xác thực API được thực hiện bằng cách sử dụng khóa riêng tư và xác thực nó dựa trên khóa công khai.
ServiceAccountConfig:
...
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
- ...Tạo tài khoản dịch vụ
Sử dụng lệnh sau để tạo tài khoản dịch vụ
$ Openshift cli create service account <name of server account>Làm việc với HTTP Proxy
Trong hầu hết các môi trường sản xuất, truy cập trực tiếp vào Internet bị hạn chế. Chúng không được tiếp xúc với Internet hoặc chúng được hiển thị qua proxy HTTP hoặc HTTPS. Trong môi trường OpenShift, định nghĩa máy proxy này được đặt làm biến môi trường.
Điều này có thể được thực hiện bằng cách thêm định nghĩa proxy trên tệp chính và tệp nút nằm trong / etc / sysconfig . Điều này tương tự như chúng tôi làm đối với bất kỳ ứng dụng nào khác.
Máy chủ
/ etc / sysconfig / openshift-master
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY=master.vklnld908.int.example.com
Máy nút
/ etc / sysconfig / openshift-node
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY=master.vklnld908.int.example.com
Sau khi thực hiện xong, chúng ta cần khởi động lại máy chủ và máy nút.Đối với Docker Pull
/ etc / sysconfig / docker
HTTP_PROXY = http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY = https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY = master.vklnld1446.int.example.com
Để làm cho một nhóm chạy trong môi trường proxy, nó có thể được thực hiện bằng cách sử dụng:
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
Lệnh OC môi trường có thể được sử dụng để cập nhật env hiện có.
OpenShift Storage với NFS
Trong OpenShift, khái niệm khối lượng liên tục và yêu cầu khối lượng liên tục tạo thành bộ nhớ liên tục. Đây là một trong những khái niệm chính trong đó tập liên tục đầu tiên được tạo ra và sau đó là tập tương tự được xác nhận. Đối với điều này, chúng ta cần có đủ dung lượng và không gian đĩa trên phần cứng bên dưới.
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle
Tiếp theo, sử dụng lệnh OC create, tạo Ổ đĩa liên tục.
$ oc create -f storage-unit1.yamlYêu cầu khối lượng đã tạo.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Tạo xác nhận quyền sở hữu
$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created
Quản lý Người dùng và Vai trò
Quản trị vai trò và người dùng được sử dụng để quản lý người dùng, quyền truy cập và kiểm soát của họ trên các dự án khác nhau.
Tạo người dùng
Các mẫu được xác định trước có thể được sử dụng để tạo người dùng mới trong OpenShift.
kind: "Template"
apiVersion: "v1"
parameters:
- name: vipin
required: true
objects:
- kind: "User"
apiVersion: "v1"
metadata:
name: "${email}"
- kind: "Identity"
apiVersion: "v1"
metadata:
name: "vipin:${email}"
providerName: "SAML"
providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
name: "vipin:${email}"
user:
name: "${email}"
Sử dụng oc create –f <tên tệp> để tạo người dùng
$ oc create –f vipin.yamlSử dụng lệnh sau để xóa người dùng trong OpenShift.
$ oc delete user <user name>Giới hạn quyền truy cập của người dùng
ResourceQuotas và LimitRanges được sử dụng để giới hạn mức độ truy cập của người dùng. Chúng được sử dụng để giới hạn các vỏ và thùng chứa trên cụm.
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"
Tạo báo giá bằng cách sử dụng cấu hình trên
$ oc create -f resource-quota.yaml –n –Openshift-sampleMô tả báo giá tài nguyên
$ oc describe quota resource-quota -n Openshift-sample
Name: resource-quota
Namespace: Openshift-sample
Resource Used Hard
-------- ---- ----
pods 3 10
Việc xác định giới hạn vùng chứa có thể được sử dụng để giới hạn tài nguyên sẽ được sử dụng bởi các vùng chứa đã triển khai. Chúng được sử dụng để xác định các giới hạn tối đa và tối thiểu của các đối tượng nhất định.
Giới hạn dự án của người dùng
Điều này về cơ bản được sử dụng cho số lượng dự án mà người dùng có thể có tại bất kỳ thời điểm nào. Về cơ bản, chúng được thực hiện bằng cách xác định cấp độ người dùng trong các danh mục đồng, bạc và vàng. Trước tiên, chúng ta cần xác định một đối tượng có giá trị bao nhiêu dự án mà một loại đồng, bạc và vàng có thể có. Chúng cần được thực hiện trong tệp master-confif.yaml.
admissionConfig:
pluginConfig:
ProjectRequestLimit:
configuration:
apiVersion: v1
kind: ProjectRequestLimitConfig
limits:
- selector:
level: platinum
- selector:
level: gold
maxProjects: 15
- selector:
level: silver
maxProjects: 10
- selector:
level: bronze
maxProjects: 5
Khởi động lại máy chủ chính.
Chỉ định người dùng cho một cấp cụ thể.
$ oc label user vipin level = goldDi chuyển người dùng ra khỏi nhãn, nếu được yêu cầu.
$ oc label user <user_name> level-Thêm vai trò cho người dùng.
$ oadm policy add-role-to-user <user_name>Xóa vai trò khỏi người dùng.
$ oadm policy remove-role-from-user <user_name>Thêm vai trò cụm cho người dùng
$ oadm policy add-cluster-role-to-user <user_name>Xóa vai trò cụm khỏi người dùng.
$ oadm policy remove-cluster-role-from-user <user_name>Thêm một vai trò vào một nhóm.
$ oadm policy add-role-to-user <user_name>Xóa vai trò khỏi nhóm.
$ oadm policy remove-cluster-role-from-user <user_name>Thêm vai trò cụm vào một nhóm.
$ oadm policy add-cluster-role-to-group <groupname>Xóa vai trò cụm khỏi một nhóm.
$ oadm policy remove-cluster-role-from-group <role> <groupname>Người dùng quản trị cụm
Đây là một trong những vai trò mạnh mẽ nhất mà người dùng có khả năng quản lý một cụm hoàn chỉnh bắt đầu từ khi tạo cho đến khi xóa một cụm.
$ oadm policy add-role-to-user admin <user_name> -n <project_name>Người dùng có sức mạnh tối thượng
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>