7,540
edits
Changes
→Openshift specific object
Indítsuk el a minishift-et.
<pre>
# minishfit minishift start
-- Starting profile 'minishift'
-- Check if deprecated options are used ... OK
<br>
===Törlés===
A '''minishift delete''' paranccsal az aktuális VM-et töröljük csak le, nem a minishift programot. A törlés után egy minishift start új VM-et fog készíteni.
<pre>
# minishift delete
You are deleting the Minishift VM: 'minishift'. Do you want to continue [y/N]?: y
Removing entries from kubeconfig for cluster: 192-168-42-64:8443
Deleting the Minishift VM...
Minishift VM deleted.
</pre>
<br>
}}
<br>
===Új névtér hozzáadása===
Hozzuk létre az új névteret.
<pre>
# kubectl create namespace mynamespace
</pre>
<br>
Rendeljük hozzá az admin clusterrole-t a developer user-hez a mynamespace névtérben. Ezzel teljhatalmat kap a developer a mynamesapce-ben.
<pre>
# kubectl create rolebinding developer-admin --namespace=mynamespace --clusterrole=admin --user=developer
rolebinding.rbac.authorization.k8s.io/developer-admin created
</pre>
<br>
Ezzel létrejött a developer-admin rolebindig a mynamespace-ben, listázzuk ki:
<pre>
# kubectl get rolebinding developer-admin -n mynamespace -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: "2019-09-22T10:51:01Z"
name: developer-admin
namespace: mynamespace
resourceVersion: "35751"
selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/mynamespace/rolebindings/developer-admin
uid: de318108-dd26-11e9-bc53-52540074f436
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: developer
</pre>
<br>
Most lépjünk be a developer-el, láthatjuk, hogy megjelent a névtér listában a mynamespace is:
<pre>
# oc login
Authentication required for https://192.168.42.214:8443 (openshift)
Username: developer
Password:
Login successful.
You have access to the following projects and can switch between them with 'oc project <projectname>':
mynamespace
* myproject
Using project "myproject".
</pre>
<br>
<br>
=Openshift specific object=
==DeploymentConfig== <br> =DeploymentConfig=Service with ssl encryption== Az egésznek a mozgató rugója, hogy a service objektumban szerepeltetjük a '''service.alpha.openshift.io/serving-cert-secret-name''' annotációt. Az itt megadott értékkel (a példában '''my-app-internal-cert''') létre fog jönni automatikusan egy TLS típusú secret mikor kiadjuk a svc-re az apply parancsot. service.yaml<source lang="C++">apiVersion: v1kind: Servicemetadata: annotations: service.alpha.openshift.io/serving-cert-secret-name: my-app-internal-cert labels: app: my-app configurable: "true" name: my-app namespace: mynamespace...</source> Ezt a kulcsot fogja a service titkosításra használni. <pre># kubectl get secret pod-monitor-internal-cert -o yaml------------------------------------------------------apiVersion: v1data: tls.crt: SDGSDFGsda... tls.key: AFGGSDGcs....kind: Secretmetadata: name: my-app-internal-cert namespace: mynamespace ownerReferences: - apiVersion: v1 kind: Service name: my-apptype: kubernetes.io/tls</pre> A '''my-app-internal-cert''' secret-et bele kell tenni a Deployment-hez tartozó service-account-ba is, hogy mount-olni tudjuk majd a pod-ba: <br>service-account.yaml<source lang="C++">apiVersion: v1kind: ServiceAccountmetadata: labels: app: my-app name: my-appsecrets:...- name: my-app-internal-cert</source> deployment.yaml<source lang="C++"> - mountPath: /var/run/secrets/https-internal-cert name: https-internal-cert readOnly: true... volumes: - name: https-internal-cert secret: defaultMode: 420 secretName: my-app-internal-cert</source>
<br>
<br> ==RouteRouter==http://people.redhat.com/jrivera/openshift-docs_preview/openshift-origin/glusterfs-review/install_config/router/index.html<br>http://people.redhat.com/jrivera/openshift-docs_preview/openshift-origin/glusterfs-review/architecture/networking/routes.html<br>
https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#route-types<br>
Default: HAProxy
The controller and HAProxy are housed inside a pod, which is managed by a deployment configuration. The process of setting up the router is automated by the oc adm router command.
The controller watches the routes and endpoints for changes, as well as HAProxy’s health. When a change is detected, it builds a new haproxy-config file and restarts HAProxy. The haproxy-config file is constructed based on the router’s template file and information from OpenShift Origin.
Ez az Ingress megfelelője az OpenShfit-ben. Az alapértelmezett implementációja a HAProxy. A load-balancing-ot OpenShift-ben a szabványos Kubernetes-el szemben a router végzi, nem a service. Alapértelmezetten a router-ek a node-on a 80-as ill a 443-as portokra fognak kapcsolódni.
<br>
<pre>
</pre>
<source lang="C++">
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
type: RunAsAny
groups:
- system:cluster-admins
kind: SecurityContextConstraints
metadata:
annotations:
kubernetes.io/description: anyuid provides all features of the restricted SCC
but allows users to run with any UID and any GID.
name: anyuid
priority: 10
readOnlyRootFilesystem: false
requiredDropCapabilities:
- MKNOD
runAsUser:
type: RunAsAny
seLinuxContext:
type: MustRunAs
supplementalGroups:
type: RunAsAny
users:
- system:serviceaccount:mynamespace:default
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret
</source>
<pre>
</pre>
<pre>
# kubectl oc get svc router template -n default mynamespaceNAME DESCRIPTION PARAMETERS OBJECTS 4 (3 blank) 2mytemplate-1 This template contains the DeploymentConfig, Service, Route and ServiceAccoun... 11 (5 blank) 5</pre> <pre># oc get template mytemplate-1 -n mynamespace -o yamlapiVersion: template.openshift.io/v1kind: ServiceTemplate
metadata:
</pre>
<pre>
</pre>
Pl:
kubectl cp mynamespace/example-pod:/tmp/example.txt /home/adam/
{{note|Fontos, hogy a konténerben legyen rsync vagy tar telepítve, ezek valamelyikével fogja a Kubernetes végrehajtani a másolást}}
A cp OpenShfit megfelelője a oc rsync :
oc rsync mynamespace/example-pod:/tmp/example.txt /home/adam/
<br>
<br>
=Minishfit repositorydocker registry=
https://torstenwalter.de/minishift/openshift/docker/registry/2017/07/25/build-docker-image-and-upload-to-openshift-registry.html<br>
https://github.com/minishift/minishift/issues/817<br>
Ahhoz hogy egy általunk készült docker image-et futtatni tudjunk a minishift klaszteren, elsőként fel kell tölteni azt a minshift image repository-ba, ami nem is annyira egyszerű. A minishift docker registry-t csak a minishfit-et futtató VM-ről lehet elérni, az anyagépről nem.
Az openshfit saját docker registry-je egy deploymentConfig-al definiált pod-ban fut: <pre># kubectl get dc -n defaultNAME REVISION DESIRED CURRENT TRIGGERED BYdocker-registry 1 1 1 config...</pre>A registry pod ebből az image-ből készül: '''openshift/origin-docker-registry:v3.11.0'''<br><br>
Lépésel:
# A minishit-et futó VM-en a docker klienssel be kell lépni a minisfht-ben futó docker registry-be az első pontban szerzett token-el.
:[[File:ClipCapIt-190727-001229002450.PNG]]
</source>
Az openjdk-11 base image-ből indulunk ki, majd belemásoljuk az összes függőséget, rárakjuk classPath-ra az összes bemásolt jar-t, amjd elindítjuk az alkalmazást a '''com.adam.testapp.App''' main osztállyal. A cél, hogy az ebből készült image-et másoljuk fel az opensfhit repository-ba, majd készítsünk belőle egy Kubernetes deploymentet-et service-el együtt.
A Dokcerfile és az abban hivatkozott összes további fájl lehet a host gépen lesz, de mivel a docker-kliens a minishift-en lévő démonhoz csatlakozik, mikor kiadjuk majd a build parancsot, az anyagépenimage a minishfit VM ottani lokális docker repository-ába fog bekerülni.
<br>
===Belépés az openshfit registriy-be===
Ahogy azt már korábban írtuk, át fogjuk irányítani a host gépen futó docker klienst, hogy a minisfhit VM-en futó docker démonhoz kapcsolódjon, így a lokálisan kiadott docker parancsok mind a minishift VM-en futó docker-en fognak végrehajtódni. Irányítsuk át a lokális docker kliensünket a minishfit VM docker démonjára, ugyan úgyEz megegyezik azzal, ahogy ezt a docker swarm esetében is tennénkcsatlakozunk a swarm master node-on futó démonhoz:
<pre>
# minishift docker-env
Ezt le tudjuk ellenőrizni, ha listázzuk vagy a futó konténereket vagy az elérhető image-eketa docker démonon, ahova a docker kliens csatlakozik:
<pre>
# docker image ls
A célunk, hogy a minisfhit VM-en futó docker démon belépjen a minshift saját docker registry-ébe, és oda push-olja a saját lokális registryrepository-ében ban lévő image-et. Ehhez szereznünk kell egy openShift login toke-ent és meg kell szerezzük a registry repository címét.
Lépjünk be az '''oc login'''-al az OpenShift-be. Fontos hogy ne a system hanem a '''developer''' felhasználóval lépjünk be, mert csak neki lesz push joga.
{{note|Ha így lépünk be nem jó: '''oc login -u system:admin'', mert nem keletkezik token.}}
<pre>
myproject
</pre>
<br>
Ellenőrizzük, hogy kaptunk e tokent. Ezt az '''oc whoami''' parancs '''-t''' (token) kapcsolójával lehet megtenni. Ha itt nem látjuk a toke-nt akkor dolgozni kell még a belépésen.
</pre>
<br>
A minishift -nek a '''openshift registry''' parancsával kérhetjük le a docker registry címét.
<pre>
A '''docker login''' paranccsal léphetünk be a minishift registriy-be. Ha ezt lokálisan kiadjuk, akkor már a minishit VM-en fog futni lefutni így el fogjuk érni a '''172.30.1.1:5000''' címen a repositoryregistry-t (Az átirányítás A docker kliens átirányítása nélkül nem érnénk el a lokális gépről ezt a címet). Tehát ezzel Ezzel a minisfhit VM-en futó docker démon csatlakozik a minisfhit repositoryregistry-bahez, tehát nem az anyagépen futó dockerdémon.
<pre>
# docker login -u developer -p $(oc whoami -t) $(minishift openshift registry)
Login Succeeded
</pre>
Fontos, hogy csak token-el engedi a belépést a az openshfit registry, jelszóval nem.
<br>===docker build és push===Az openshfitregistry-be szánt image-nek a neve az alábbi szintaxist kell kövesse:
<registry-host>:<port>/<névtér>/<image-név>:<tag>
Ahhoz hogy push-olni tudjuk az OpenShift registry-be az image-et a "172.30.1.1:5000/" prefixel kell kezdődjön a neve. Innen fogja tudni a docker, hogy melyik registry-be akarjuk push-olni. A második elem a névtér neve, amihez az image tartozni fog. Az image-ek ugyan úgy névterekbe kerülnek mint minden kubernetes objektum.
</pre>
<br>
Nem maradt más dolgunk, mint hogy a '''docker push''' paranccsal felküldjük az image-t az opensfhit repositoryregistry-babe. A nevéből fogja tudni a '''docker push''' hogy melyik repository-ba kell küldeni és ott melyik névtérbe.
<pre>
# docker push 172.30.1.1:5000/mynamespace/test-app:1.1.0
<pre>
# oc get is -n mynamespace
<br>
===Teszt alkalmazás futtatása===
Az egyszerűség kedvéért a '''kubectl run''' paranccsal fogjuk futtatni az alkalmazást. Ha nem adjuk meg a -it kapcsolót, akkor létre fog hozzá hozni egy deployment-et és egy replicaSet-et is, nem csak a pod-ot fogja elindítani.
<pre>
# kubectl run test-app --image=172.30.1.1:5000/mynamespace/test-app:1.1.0 --replicas=1 --port=8080 -n mynamespace
</pre>
Ellenőrizzük, hogy létrejött e a test-app nevű deployment.
<pre>
# kubectl get deployment -n mynamespace
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
..
test-app 1 1 1 1 2m
</pre>
Nézzük meg a deployment definícióját (csak a releváns részeket tüntetem fel):
# kubectl get deployment test-app -n mynamespace -o yaml
<source lang="C++">
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
run: test-app
name: test-app
namespace: mynamespace
spec:
replicas: 1
selector:
matchLabels:
run: test-app
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
run: test-app
spec:
containers:
- image: 172.30.1.1:5000/mynamespace/test-app:1.1.0
imagePullPolicy: IfNotPresent
name: test-app
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always
</source>
<br>
A '''kubectl run''' parancshoz hasonlóan a '''kubectl expose''' paranccsal instant módon készíthetünk service-t a deployment-hez. A deployment-ben megadott portot (8080) fogja kinyitni a pod-ok felé:
<pre>
# kubectl expose deployment test-app --type=LoadBalancer --name=test-app-service -n mynamespace
service/test-app-service exposed
</pre>
<br>Ellenőrizzük, hogy létrejött e a service. Láthatjuk, hogy a '''30534''' porton érhető el kívülről a service. <pre>
# kubectl get svc -n mynamespace
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
test-app-service LoadBalancer 172.30.254.3 172.29.192.241,172.29.192.241 8080:30534/TCP 2m
</pre>
<br>Ha a minishift VM publikus címét beírjuk a fenti port számmal, akkor meg kell tudjuk szólítani az alkalmazásunkat: <br>
http://192.168.42.185:30534/test/slowresponse/2000
:[[File:ClipCapIt-190725-235129.PNG]]
<br>
Hozzunk létre egy opensfhit route-ot is az imént létrehozott service-hez ugyan úgy instant módon az '''oc create route''' paranccsal.
<pre>
# oc create route -n mynamespace edge --service test-app-service --insecure-policy Allow
route.route.openshift.io/test-app-service created
</pre>
Listázzuk ki az imént létrehozott route-ot '''wide''' módban, hogy megtudjuk mi lett a host neve. A minisfhit alapértelmezetten készít egy '''nip.io'''-s host nevet minden route-hoz, ahol nem adjuk meg mi legyen a host név:
<pre>
# kubectl get route test-app-service -n mynamespace
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
test-app-service test-app-service-mynamespace.192.168.42.185.nip.io test-app-service <all> edge/Allow None
</pre>
http://test-app-service-mynamespace.192.168.42.185.nip.io/test/slowresponse/2000
:[[File:ClipCapIt-190727-203903.PNG]]
