usually do : + Kubernetes Development of related components + Kubernetes as a Service Development ▶ Kubernetes SIG-Docs Japanese localization reviewer ▶ Kubernetes Internal Organizer ▶ #kubenews ▶ @bells17_
(especially iSCSI or NFS ..) ▶ Trident version is expected to be v21.07.2 ▶ Trident is expected to be used with the following settings: + Use Trident from Kubernetes + Trident is basically installed using Trident Operator (described later) ▶ Since it is only an explanation of understanding as a result of following the implementation of Trident, there may be cases where it differs from the actual behavior
advantage of various NetApp storage products (e.g. ONTAP, E- Series, Cloud Volumes Service for AWS, etc...) ▶ With Trident, you will be able to operate NetApp storage products in a container environment such as Kubernetes ▶ The following two platforms are currently supported: + Kubernetes ← I will talk how Trident works on Kubernetes here + Docker ▶ Trident is an OSS (https://github.com/NetApp/trident) ▶ Trident is one of the applications included in Project "Astra" ▶ Astra consists of following applications in addition to Trident + Astra Control: Kubernetes cluster management and operations console + Astra Data Store: Kubernetes native shared file service
of a CSI Driver for cooperating with Kubernetes, a Rest API server for tridentctl, and various controllers for controlling the state of Trident ▶ tridentctl: The Command line tool for operating Trident from cli ▶ Trident Operator: Kubernetes Operator for managing Trident installations and upgrades on Kubernetes clusters + It was added from Trident v20.04.0 + You can install trident with the tridentctl install command in addition to the Trident Operator
for manage various NetApp storage on Kubernetes ▶ It also implements multiple Kubernetes Controllers for Trident management ▶ Therefore, before we get into the implementation of Trident, It is better to know about the outline such as + Kubernetes Operator(Kubernetes Controller) + CSI(driver)
orchestrators ▶ You can build a cluster composed of etcd / control plane / worker node, run various containers on node on Kubernetes, and enable to link the running container and network nicely ▶ By declaratively describing the container and other resources to be deployed in the manifest file, Kubernetes will perform adjustment processing nicely so that it will be in the declared state ▶ A container orchestrator that recreated from Borg, a container platform operated internally by Google, for OSS ▶ Kubernetes has also been donated to the Cloud Native Computing Foundation(CNCF) and is managed on a community basis as a CNCF Graduated project
Container Orchestrator (CO) such as Kubernetes, Mesos, Cloud Foundry, etc + So it's not a specification only for Kubernetes + For example, Hashicorp Nomad is using CSI under the hood ▶ Storage providers aim to be able to utilize Kubernetes and other COs by writing a driver that supports CSI once ▶ The CSI specification is defined in the the spec.md file in the container- storage- interface/spec repository on Github
be provided in container image format (Docker, OCI, etc.) ▶ Communication between CSI Driver and CO needs to ... + Use gRPC protocol + Via UNIX domain socket
control plane for its CSI Driver ▶ Implementation of the following gRPC services: + Controller Service + Identity Service ▶ It provides the ability to control the volume and the snapshot ▶ Specifically, it provides the following features: + Create / Delete volume + Attach / Detach volume to node + Create / Delete volume snapshot
CO-participating Worker Node ▶ Implementation of the following gRPC services: + Node Service + Identity Service ▶ It provides the feature to operate the volume on each target Worker Node ▶ It mainly provides the following features: + Format volume attached to node + Mount / Unmount Volume
storage providers to provide volume plug-ins to CO ▶ Specifically, the following are defined + Definition of operating environment and communication method of CSI Driver + Container image format + UNIX domain socket / gRCP protocol + Definition of RPC interface + Controller Plugin + Node Plugin
Volume plugin implemented inside Kubernetes code + ConfigMap / Secret / EmptyDir etc. fall into here ▶ FlexVolume + Plugin created before CSI appeared (Kubernetes v1.8) + It seems that it is not used much because it requires knowledge about the internal implementation of Kubernetes + Deprecated in Recent Kubernetes Updated versions ▶ CSI Driver + Alpha is available from Kubernetes v1.9 + Kubernetes provides a sidecar application that works with the CSI Driver, so you can provide volume plugins without the need for knowledge of the internal implementation of Kubernetes
Controller using TridentTransaction resource for managing volume creation etc ▶ PeriopdicallyReconcileNodeAccessOnBackends: A Controller that checks that the appropriate policy settings are set so that each node and each Trident Backend can connect ▶ k8shelper + Node Controller: A Controller that deletes the target Trident Node when deleting a node and deletes the target node information from the policy of each Trident Backend ▶ CRD Controllers + reconcileTMR: Set the SnapMirror according to the TridentMirrorRelationship resource and update the status of the TridentMirrorRelationship ▶ etc
0/5"1UIBU5SJEFOUDPOOFDUTUP 5SJEFOU#BDLFOE 0QFSBUFEUPNBOBHFTUPSBHFJOGPSNBUJPOTVDIBT0/5"1UPXIJDI5SJEFOUDPOOFDUT :PVDBODSFBUFXJUIl5SJEFOU#BDLFOE$POpHzPSlUSJEFODUMDSFBUFCBDLFOEz 5SJEFOU4UPSBHF$MBTT 3FTPVSDFTGPS5SJEFOUUPQSPDFTTXJUI,T4UPSBHF$MBTT "TGBSBTUIFJNQMFNFOUBUJPOJTDPODFSOFE JUQSPCBCMZEPFTOUIBWFUPCFQFSTJTUFOU 5SJEFOU/PEF 3FTPVSDFTGPSTUPSJOHOPEFJOGPSNBUJPOGPS5SJEFOU (FOFSBUFEGSPN$4*/PEFBOEEFMFUFEPOUIF$4*4FSWFSTJEFXIFOUIFOPEFJT EFMFUFE 0QFSBUFEUPTFUQPMJDJFTTPUIBUFBDITFSWFSDBODPOOFDUUPWBSJPVT#BDLFOET 5SJEFOU7PMVNF 3FTPVSDFTGPSNBOBHJOHWPMVNFTEJTQFOTFEWJB5SJEFOU "TGBSBTUIFJNQMFNFOUBUJPOJTDPODFSOFE JUQSPCBCMZEPFTOUIBWFUPCFQFSTJTUFOU 5SJEFOU7FSTJPO 3FTPVSDFTGPSTUPSJOHUIF5SJEFOUWFSTJPOSVOOJOHPOUIF$POUSPMMFSTJEF 0QFSBUFEUPDIFDLJGJUNBUDIFTUIF5SJEFOUWFSTJPOSVOOJOHPOUIF/PEFTJEF 5SJEFOU.JSSPS3FMBUJPOTIJQ 3FTPVSDFTGPSTFUUJOH4OBQ.JSSPSTFUUJOHTPOWPMVNFT 5SJEFOU5SBOTBDUJPO 3FTPVSDFTGPSNBOBHJOHUIFQSPDFTTJOHTUBUVTTVDIBTWPMVNFDSFBUJPO 1SPDFTTJOHJTSPMMFECBDLXIFOUIFFYFDVUJPOUJNFJTQSPMPOHFEFYDFQUGPSTPNF SFTPVSDFT There are other CRDs, but they are unlikely to be used
interesting to be able to use TridentBackend for multiple NetApp storage from one Trident ▶ On the other hand, I got the impression that it would be difficult to start using it because the setting method of TridentBackend and StorageClass is complicated ▶ There were some features and resource definitions (eg Snapshot resources, etc.) that were developed from a relatively old age or seem to be unused now. I got the impression that the implementation could be kept simple by redefining the features, implementations, and support scope of the application
PVC is resized + The CSI driver's sidecar "csi-resizer" should resize the PV(C), so it seems unnecessary ▶ PV Controller: It deletes the volume associated with the deleted PV + Since the deletion process itself is performed on the CSI driver side, it seems that it is for retrying the deletion if the deletion of the volume was not successful due to some influence ▶ StorageClass Controller: It generates TridentStorageClass according to the creation of k8s Storage Class + Also, if a k8s StorageClass prior to v1 is created, a v1 k8s StorageClass will be generated ▶ Node Controller: It deletes the target TridentNode when deleting a node, and delete the target node information from the policy of each TridentBackend ▶ reconcileNodes: It compares TridentNode and k8s Node and remove that TridentNode if k8s Node does not exist ▶ handleFailedPVUpgrades: If there is a transaction for which the PV upgrade process has not been completed, stop the PV upgrade, delete the PV that was being created, and create a PV with the old settings + PV upgrade seems to be a feature operatated only with tridentctl, but the usage is unknown + PV upgrade seems to create a new PV that imports the PV from which it was upgraded and replacing it
store + If the event of k8s Secret with the secret information of TridentBackendConfig occurs, it generates + TridentBackendConfig including the data of k8s secret and execute the event of reconcileBackendConfig + If the TridentBackend resource is deleted, it executes reconcileBackendConfig to regenerate the TridentBackend resource based on the associated TridentBackendConfig ▶ reconcileTMR: Set the SnapMirror according to the TridentMirrorRelationship resource and update the status of the TridentMirrorRelationship ▶ handleTridentSnapshotInfo: It gets the volumeSnapshot(Content) of k8s from the snapshotName stored in the TridentSnapshotInfo resource, and stores the SnapshotHandle(≒Snapshot ID) in the status of TridentSnapshotInfo + However, the TridentSnapshotInfo resource doesn't seem to be operated at all elsewhere, so it seems unlikely that this recocile loop will work in the first place
operating TridentTransaction resource for managing volume creation etc ▶ PeriopdicallyReconcileNodeAccessOnBackends: A Controller that checks that the appropriate policy settings are done so that each node and each TridentBackend can connect
process is enabled, it installs package etc + It writes information such as mountOptions, NFS Server IP, NFS Path as a file named + volumePublishInfo.json + It creates this file in the path for the target volume provided by a Kubernetes CSI Sidecar ▶ NodePublishVolume: + It gets information from volumePublishInfo.json + It creates a mount destination directory + It mounts an NFS volume with the “mount -t nfs” command
is enabled, it installs package etc. + It creates an iSCSI target with the iscsiadm command and log in + It scans the path to a particular LUN and waits for all SCSI disk-by-paths for that LUN to be created + It waits for the multipath device to be created + After that, if a file system other than Raw Block Volume is specified, it formats. + Available file systems: xfs / ext3 / ext4 ▶ NodePublishVolume: + It mount the device with the mount command
resources for which PV is assigned ▶ This Storage Pool is categorized as follows + Physical Storage Pool + Virtual Storage Pool ▶ Physical Storage Pool is an Aggregator for ONTAP + Aggregator = RAID bundled to improve storage performance and scalability ▶ Virtual Storage Pool + One Physical Storage Pool made into multiple pools + It set up multiple different Virtual Storage Pools such as IOPS and assign them according to the required requirements + It combines multiple Physical Storage Pools into one Pool + Physical Storage Pools with different physical arrangements and network topologies can be combined into one Virtual Storage Pool and scheduled to the appropriate Topology
set the SnapMirror for a volume ▶ However, it seems that this function is still under development and there is no document etc ▶ You can mirror data with other volumes like SnapMirror = rsync ▶ Basically, the log of the written contents is added by Incremental Forever ▶ It's also possible to mirror the entire Storage VM (which seems impossible with Trident) ▶ It is also possible to transfer to S3 (object storage that can use the protocol) called SnapMirror Cloud
bells17
ivargrimstad
layerx
tsucchinoko
pyama86
satoshi7190
goyoki
krpk1900
77web
little_rubyist
.png){kind=avatar}
yuriko1211
naokihaba
irinanazarova
trishagee
zakiyama
reverentgeek
bryan
pauljervisheath
danielanewman
addyosmani
keithpitt
shlominoach
quramy
bkeepers
