|
34 | 34 | nodePort: 31093 # <1> |
35 | 35 | ---- |
36 | 36 |
|
37 | | -<1> Static value for the purposes of the demo. |
| 37 | +<1> Static value for the purposes of the demo |
38 | 38 |
|
39 | 39 | They are: |
40 | 40 |
|
@@ -302,7 +302,7 @@ This section of the JupyterHub configuration specifies that we are using Generic |
302 | 302 |
|
303 | 303 | <1> We need to either provide a list of users using `allowed_users`, or to explicitly allow _all_ users, as done here. |
304 | 304 | We will delegate this to Keycloak so that we do not have to maintain users in two places |
305 | | -<2> Each admin user will have access to an Admin tab on the JupyterHub UI where certain user-management actions can be carried out. |
| 305 | +<2> Each admin user will have access to an Admin tab on the JupyterHub UI where certain user-management actions can be carried out |
306 | 306 | <3> Define the Keycloak scope |
307 | 307 | <4> Specifies which authenticator class to use |
308 | 308 |
|
@@ -352,8 +352,7 @@ This can be seen below: |
352 | 352 |
|
353 | 353 | <1> Specify which certificate(s) should be used internally (in the code above this is using the default certificate, but is included for the sake of completion) |
354 | 354 | <2> Create the certificate with the same secret class (`tls`) as Keycloak |
355 | | -<3> Mount this certificate |
356 | | -If the default file is not overwritten, but is mounted to a new file in the same directory, then the certificates should be updated by calling e.g. `update-ca-certificates`. |
| 355 | +<3> Mount this certificate: if the default file is not overwritten, but is mounted to a new file in the same directory, then the certificates should be updated by calling e.g. `update-ca-certificates` |
357 | 356 | <4> Ensure python is using the same certificate |
358 | 357 |
|
359 | 358 | [#endpoints] |
@@ -382,7 +381,7 @@ As mentioned in the <<services, Services>> section above, we want to define the |
382 | 381 | [#driver] |
383 | 382 | === Driver Service (Spark) |
384 | 383 |
|
385 | | -NOTE: When using Spark from within a notebook, please the <<provisos, Provisos>> section below. |
| 384 | +NOTE: When using Spark from within a notebook, please take note of the <<provisos, Provisos>> section below. |
386 | 385 |
|
387 | 386 | In the same way, we can use another script to define a driver service for each user. |
388 | 387 | This is essential when using Spark from within a JupyterHub notebook so that executor Pods can be spawned from the user's kernel in a user-specific way. |
@@ -432,7 +431,7 @@ This script instructs JupyterHub to use `KubeSpawner` to create a service refere |
432 | 431 |
|
433 | 432 | === Profiles |
434 | 433 |
|
435 | | -The `singleuser.profileList` section of the Helm chart values allows us to define notebook profiles by setting the CPU, Memory and Image combinations that can be selected. For instance, the profiles below allows us to select 2/4/etc. CPUs, 4/8/etc. GB RAM and to select one of two images. |
| 434 | +The `singleuser.profileList` section of the Helm chart values allows us to define notebook profiles by setting the CPU, Memory and Image combinations that can be selected. For instance, the profiles below allows us to select 2/4/etc. CPUs, 4/8/etc. GB RAM and to choose between one of two images. |
436 | 435 |
|
437 | 436 | [source,yaml] |
438 | 437 | ---- |
@@ -541,9 +540,9 @@ To avoid this, care needs to be taken to use images for the notebook and the Spa |
541 | 540 | [#provisos] |
542 | 541 | === Provisos |
543 | 542 |
|
544 | | -WARNING: When running a distributed Spark cluster from within a JupyterHub notebook, the notebook acts as the driver and requests executors Pods from k8s. |
| 543 | +WARNING: When running a distributed Spark cluster from within a JupyterHub notebook, the notebook acts as the driver and requests executor Pods from k8s. |
545 | 544 | These Pods in turn can mount *all* volumes and Secrets in that namespace. |
546 | | -To prevent this from breaking user separation, it is planned to use an OPA gatekeeper to define OPA rules that restrict what the created executor Pods can mount. This is not yet implemented in the demo nor reflected in this tutorial. |
| 545 | +To prevent this from breaking user isolation, it is planned to use an OPA gatekeeper to define OPA rules that restrict what the created executor Pods can mount. This is not yet implemented in the demo nor reflected in this tutorial. |
547 | 546 |
|
548 | 547 | === Overview |
549 | 548 |
|
|
0 commit comments