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=
<br>
==RouteService 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> ==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.
<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>
# kubectl get svc -n defaultoc edit scc anyuidNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGErouter ClusterIP 172securitycontextconstraints.30security.130openshift.191 <none> 80/TCP,443/TCP,1936io/TCP 4danyuid edited
</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>
===Á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-ábaba, 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.# 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:
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>
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. Fontos hogy developer-el lépjünk be, mert a system-nek nincs joga push-olni image-et. }}
<pre>
# oc login
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
</pre>
<br>//Prints the host name and port number of the OpenShift Docker 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.
<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 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.
<pre>
# docker build -t 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>
# 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]]