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>
==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: falseallowHostIPC: falseallowHostNetwork: falseallowHostPID: falseallowHostPorts: falseallowPrivilegeEscalation: trueallowPrivilegedContainer: falseallowedCapabilities: nullapiVersion: security.openshift.io/v1defaultAddCapabilities: nullfsGroup: type: RunAsAnygroups:- system:cluster-adminskind: SecurityContextConstraintsmetadata: annotations: kubernetes.io/description: anyuid provides all features of the restricted SCC but allows users to run with any UID and any GID. name: anyuidpriority: 10readOnlyRootFilesystem: falserequiredDropCapabilities:- MKNODrunAsUser: type: RunAsAnyseLinuxContext: type: MustRunAssupplementalGroups: type: RunAsAnyusers: - system:serviceaccount:mynamespace:defaultvolumes:- 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 HAProxy szolgáltat magáról metrikákat '''SecurityContextConstraints''' definícióban a routeruser 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 anyuidsecuritycontextconstraints.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 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: Templatemetadata:....</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 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 tartozó 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-jdkRUN mkdir /home/libADD ./*.jar /homeADD ./lib/* /home/lib/EXPOSE 8080CMD ["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-envexport 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 lsREPOSITORY TAG IMAGE ID CREATED SIZEbitnami/nginx latest ab5cdb60157c 11 hours ago 78.3MB172.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 829MBopenshift/origin-hyperkube v3.11.0 7f2cb107435c 4 days ago 509MBopenshift/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 keresztülfutó 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 loginAuthentication required for https://192.168.42.185:8443 (openshift)Username: developerPassword: 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 -tJbdYzUHpsyJCBt3JQ7XBahLq6UAp0hiYsOTYTiD1arE</pre> <br>A minishift -nek a '''openshift registry''' parancsával kérhetjük le a docker registry címét. <pre># minishift openshift registry172.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. Seehttps://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 alapértelmezett metrika URL openshfit registry-be szánt image-nek a neve az alábbiszintaxist 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.99MBStep 1/6 : FROM openjdk:11-jdk ---> f06fdc42d01a...Successfully built ecc484546662Successfully 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>
</pre>
<br>
<pre>
# kubectl get svc -n defaultNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGErouter ClusterIP docker push 172.30.1301.191 <none> 801:5000/TCP,443mynamespace/TCP,1936/TCP 4dtest-app:1.1.0
</pre>
A metrika user és jelszó pedig 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 service definíciójában van benneimageScream-eket:
<pre>
# oc get is -n mynamespaceNAME DOCKER REPO TAGS UPDATEDtest-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 mynamespaceNAME 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 svc router deployment test-app -n default mynamespace -o yaml<source lang="C++">apiVersion: v1extensions/v1beta1kind: ServiceDeployment
metadata:
labels:
</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]]
<pre>
# curl admin:4v9a7ucfMi@192oc create route -n mynamespace edge --service test-app-service --insecure-policy Allowroute.168route.42openshift.64:1936io/metrics# HELP apiserver_audit_event_total Counter of audit events generated and sent to the audit backend.# TYPE apiserver_audit_event_total counterapiserver_audit_event_total 0# HELP apiserver_client_certificate_expiration_seconds Distribution of the remaining lifetime on the certificate used to authenticate a request.# TYPE apiserver_client_certificate_expiration_seconds histogramapiserver_client_certificate_expiration_seconds_bucket{le="0"} 0apiserver_client_certificate_expiration_seconds_bucket{le="21600"} 0apiserver_client_certificate_expiration_seconds_bucket{le="43200"} 0apiserver_client_certificate_expiration_seconds_bucket{le="86400"} 0apiserver_client_certificate_expiration_seconds_bucket{le="172800"} 0apiserver_client_certificate_expiration_seconds_bucket{le="345600"} 0apiserver_client_certificate_expiration_seconds_bucket{le="604800"} 0test-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]]