7,540
edits
Changes
→Openshift specific object
=Telepítés=
Telepítsük fel a függőségeket, ha ezek hiányoznának<br>
A minisfhit KVM virtuális gépet hoz létre, amit docker-machine driver-el vezérel.
<pre>
# sudo dnf install libvirt qemu-kvm
</pre>
Telepítsük föl a docker-machine driver-t:
<pre>
# curl -L https://github.com/dhiltgen/docker-machine-kvm/releases/download/v0.10.0/docker-machine-driver-kvm-centos7 -o /usr/local/bin/docker-machine-driver-kvm
# chmod +x /usr/local/bin/docker-machine-driver-kvm
</pre>
Külön fel kell telepítsük az oc scriptet, ami az OpenShfit parancssori eszköze:
https://github.com/CCI-MOC/moc-public/wiki/Installing-the-oc-CLI-tool-of-OpenShift
<pre>
ln -s /path to download/oc /usr/bin/oc
</pre>
Harmadik lépésként le kell tölteni a minishift binárist. Ezzel indíthatjuk el majd a lokális, egy node-os clusterünket. Ez csak az indító script, induláskor le fogja tölteni az oc programot és a centOs-mini-t, majd libvirt-el létrehoz egy qemu virtuális gépet. <br>
https://github.com/minishift/minishift/releases
<pre>
# ln -s /path to download /minishift-1.34.0-linux-amd64/minishift /usr/bin/minishift
</pre>
Indítsuk el a minishift-et.
<pre>
# minishift start
-- Starting profile 'minishift'
-- Check if deprecated options are used ... OK
...
...
The server is accessible via web console at:
https://192.168.42.185:8443/console
You are logged in as:
User: developer
Password: developer
To login as administrator:
oc login -u system:admin
</pre>
Ha letöltötte a CentOS-t és feltelepítette rá az OpenShfit-et, ki fogja írni, hogy az OpenShift konzol milyen címen érhető el. Ez a KVM VM IP címe. Ezen felül láthatjuk, hogy két user-t is létrehozott, egy admin-t és egy developer-t.
Virsh-val nézzük meg hogy fut e a VM:
<pre>
# virsh list --all
Id Name State
----------------------------
1 minishift running
</pre>
<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>
=Login=
Az '''oc login''' paranccsal kell belépni a klaszerbe. A sikeres oc login inicializálja a kubernetes config-ot is.
<pre>
# oc login -u system:admin
Logged into "https://192.168.42.185:8443" as "system:admin" using existing credentials.
You have access to the following projects and can switch between them with 'oc project <projectname>':
default
kube-dns
kube-proxy
kube-public
kube-system
* myproject
...
</pre>
OpenShift-ben a projekt egyenlő a Kubernetes névtérrel. Láthatjuk, hogy a myproject névtérbe vagyunk belépve.
Listázzuk a Kubernetes konfigurációt:
<pre>
# kubectl config view
....
- context:
cluster: 192-168-42-185:8443
namespace: myproject
user: system:admin/192-168-42-185:8443
name: myproject/192-168-42-185:8443/system:admin
</pre>
Láthatjuk, hogy létrehozott az '''oc login''' egy külön kontextust. Innentől kezdve a '''kubectl''' parancsokat tudjuk használni.
Listázzuk ki a felhasználókat. Látni fogjuk hogy a fenti is látott system és developer felhasználók vannak a klaszterben:
<pre>
# kubectl get users
NAME UID FULL NAME IDENTITIES
developer f59113f2-9f30-11e9-ba85-525400efb4ec anypassword:developer
system df29da3c-9f35-11e9-ba85-525400efb4ec anypassword:system
</pre>
A webes konzolon is be tudunk lépni: https://192.168.42.64:8443/console/catalog
:[[File:ClipCapIt-190710-211718.PNG]]
{{note|Ha később újra el akarjuk indítani a minishfit-et, akkor fontos, hogy indulás előtt a kubectl kontextust átállítsuk a minishfit-es kontextusra ha több kontextusunk is van, különben nem fog elindulni a minishfit.
<pre>
# kubectl config use-context myproject/192-168-42-185:8443/system:admin
</pre>
}}
<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>
=Deployment és service létrehozása=
<source lang="C++">
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: bitnami/nginx
ports:
- containerPort: 80
</source>
{{warning|Az OpenShift-el nem kompatibilis a standard ngingx image, mert root felhasználóval kéne futtatni, ahhoz hogy létre tudja hozni a szükséges mappákat a konténerben. Ez ki van küszöbölve a '''bitnami/nginx''' image-ben. }}
<pre>
# kubectl apply -f deployment-demo.yaml
</pre>
<pre>
# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 2d
</pre>
<title>Welcome to nginx!</title>
</pre>
=Openshift sepcific commands=
=Openshift specific object=
<br>
==Service with ssl encryption=Route= 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> ==Router==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.
Íjuk be a böngészőbe: https://nginx-route-dsp.192.168.42.185.nip.io
:[[File:ClipCapIt-190707-225815.PNG]]
<pre>
# kubectl get dc -n default
NAME REVISION DESIRED CURRENT TRIGGERED BY
router 1 1 1 config
</pre>
<pre>
# kubectl get dc router -n default -o yaml
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
spec:
containers:
image: openshift/origin-haproxy-router:v3.11.0
name: router
</pre>
<br>
==SecurityContextConstraints==
https://medium.com/bitnami-perspectives/running-containers-in-openshift-629af79945b5
Névtér független
<pre>
# kubectl get SecurityContextConstraints anyuid -o yaml
</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>
'''Run container as root'''<br>
Azt hogy melyik pod futtathat root nevében konténert a '''SecurityContextConstraints''' objektumok írják le. Itt meg lehet határozni, hogy milyen user-nek és group-nak engedjük meg a konténer futtatását a konténeren belül. A '''SecurityContextConstraints''' definícióban a user szekcióban meg lehet adni service account-okat, és akkor az adott serviceAccount-hoz rendelt deploymenthez tartozó pod-oknak meg lehet engedni hogy a nekik tetsző user-el futtassanak process-eket. Ha nincs megengedi a root futtatás egy pod-nak, akkor egy nem privilegizált user-el fog futni.
<pre>
# oc edit scc anyuid
securitycontextconstraints.security.openshift.io/anyuid edited
</pre>
A '''mynamespace''' névtérben lévő '''default''' nevű service account-al futtatott pod-oknak megengedjük a tetszőleges user választást.
<pre>
- system:serviceaccount:mynamespace:default
</pre>
Ha egy deployment-nek külön nem adjuk meg, akkor az adott névtér default serviceAccount-jával fog futni.
<br>
<br>
==Template==
https://docs.openshift.com/container-platform/3.11/dev_guide/templates.html
<pre>
# oc get template -n mynamespace
NAME DESCRIPTION PARAMETERS OBJECTS 4 (3 blank) 2
mytemplate-1 This template contains the DeploymentConfig, Service, Route and ServiceAccoun... 11 (5 blank) 5
</pre>
<pre>
# oc get template mytemplate-1 -n mynamespace -o yaml
apiVersion: template.openshift.io/v1
kind: Template
metadata:
....
</pre>
<br>
<br>
==Fájl másolása konténerekből==
<pre>
kubectl cp <névtér>/<pod-név>:<fájl elérési út> <cél-mappa-neve>
</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 docker 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>
===Áttekintés===
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 default
NAME REVISION DESIRED CURRENT TRIGGERED BY
docker-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.
# Docker-el build-elni kell az image-t a minishfit VM-en.
# A minisfhit-et futtató VM-ről push-olni kell az image-t a minisfhit image registry-be.
# kubectl run-al el lehet indítani az általunk létrehozott image-et.
Az egyik lehetőségünk az, hogy ssh-val belépünk a minisfhit VM-re (minisfhit ssh) és ott lépünk be a registry-be (docker login) és ott build-eljük és push-oljuk az image-et. A másik sokkal kényelmesebb lehetőség, hogy a minishift VM docker démon-ját átirányítjuk a lokális docker kliensünkre a '''minishift docker-env''' paranccsal. Ezt azért tudjuk megtenni, mert a minisfhit is '''docker-machine'''-t használ. Ugyan ezt a parancsot használjuk docker swarm esetén is, hogy a '''swarm master'''-en adjuk ki a swarm parancsokat. Ennek az a nagy előnye, hogy a docker build-hez szükséges fájlokat vehetjük a lokáli gépről, de a build-elt docker image már a minishfit VM docker lokális repository-ban fog landolni, ahonnan már push-olni tudjuk a minishfit repositroy-ba.
:[[File:ClipCapIt-190727-002450.PNG]]
Kísérlet képen írtunk egy olyan Java webalkalmazást, ami a GET paraméterben kapott milliszekundum után adja vissza a 200 : 'OK' választ. Az alkalmazás embedded jetty-vel készült, a Docker fájlja az alábbi:
<source lang="C++">
FROM openjdk:11-jdk
RUN mkdir /home/lib
ADD ./*.jar /home
ADD ./lib/* /home/lib/
EXPOSE 8080
CMD ["java", "-cp", "/home/lib/*:/home/testapp.jar", "com.adam.testapp.App"]
</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 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 image 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. Ez megegyezik azzal, ahogy a docker swarm esetében is csatlakozunk a swarm master node-on futó démonhoz:
<pre>
# minishift docker-env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.42.185:2376"
export DOCKER_CERT_PATH="/root/.minishift/certs"
# eval $(minishift docker-env)
</pre>
Innentől kezdve minden lokálisan kiadott docker parancs a minishfit vm-en fog futni.
Ezt le tudjuk ellenőrizni, ha listázzuk vagy a futó konténereket vagy az elérhető image-eket a docker démonon, ahova a docker kliens csatlakozik:
<pre>
# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
bitnami/nginx latest ab5cdb60157c 11 hours ago 78.3MB
172.30.1.1:5000/mynamespace/test-app 1.1.0 f984e2105039 23 hours ago 620MB
...
openshift/origin-control-plane v3.11.0 2905f7137f05 4 days ago 829MB
openshift/origin-hyperkube v3.11.0 7f2cb107435c 4 days ago 509MB
openshift/origin-hypershift v3.11.0 7507661b73ff 4 days ago 549MB
...
</pre>
Láthatjuk, hogy csupa openshift-es image van a repóban, tehát már nem az anyagép lokális repository-ját nézzük.
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 repository-ban lévő image-et. Ehhez szereznünk kell egy openShift login toke-ent és meg kell szerezzük a 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>
# oc login
Authentication required for https://192.168.42.185: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
</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>
# oc whoami -t
JbdYzUHpsyJCBt3JQ7XBahLq6UAp0hiYsOTYTiD1arE
</pre>
<br>
A minishift -nek a '''openshift registry''' parancsával kérhetjük le a docker registry címét.
<pre>
# minishift openshift registry
172.30.1.1:5000
</pre>
Ez a cím a minishift-et futtató VM-en értelmezett IP cím, ezért csak a minishift VM-en futó docker démon-al tudunk rácsatlakozni a repository-ra.
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 lefutni így el fogjuk érni a '''172.30.1.1:5000''' címen a registry-t (A docker kliens átirányítása nélkül nem érnénk el a lokális gépről ezt a címet). Ezzel a minisfhit VM-en futó docker démon csatlakozik a minisfhit registry-hez, tehát nem az anyagépen futó docker démon.
<pre>
# docker login -u developer -p $(oc whoami -t) $(minishift openshift registry)
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
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/#credentials-store
Login Succeeded
</pre>
Fontos, hogy csak token-el engedi a belépést az openshfit registry, jelszóval nem.
<br>
===docker build és push===
Az openshfit registry-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.
A '''docker build''' paranccsal építsük meg az image-t. Ezt az image-et is tegyük a '''mynamespace''' névtérebe.
<pre>
# docker build -t 172.30.1.1:5000/mynamespace/test-app:1.1.0 .
Sending build context to Docker daemon 14.99MB
Step 1/6 : FROM openjdk:11-jdk
---> f06fdc42d01a
...
Successfully built ecc484546662
Successfully tagged 172.30.1.1:5000/mynamespace/test-app:1.1.0
</pre>
Ellenőrizzük le, hogy bekerült e a test-app a minisfhit VM lokális docker repository-jába: (mivel az anyagépen futó docker kliens át van irányítva, ezért az anyagépen kiadott docker parancsokkal elvégezhető az ellenőrzés)
<pre>
# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
...
172.30.1.1:5000/mynamespace/test-app 1.1.0 f984e2105039 23 hours ago 620MB
</pre>
<br>
Nem maradt más dolgunk, mint hogy a '''docker push''' paranccsal felküldjük az image-t az opensfhit registry-be. 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>
A minishift registry-ben úgynevezett '''imageScream'''-ek vannak. A frissen push-olt '''test-api''' image-hez is létrejött egy imageScream. Az oc paranccsal listázhatjuk a imageScream-eket:
<pre>
# oc get is -n mynamespace
NAME DOCKER REPO TAGS UPDATED
test-app 172.30.1.1:5000/mynamespace/test-app 1.1.0 8 minutes ago
</pre>
<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]]